• 状态 Resolved
  • 已锁定 已锁定
  • 回复 12 回复
  • 订户 0 订户
  • 视图 389 视图
  • 用户 0 会员在此处
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] CCS/TM4C1290NCPDT：大字体大于100 pt！！

admin
Guru**** 2482105 points


请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/706616/ccs-tm4c1290ncpdt-bigger-font-more-than-100-pt

器件型号：TM4C1290NCPDT

工具/软件：Code Composer Studio

嘿，我想让更大的字体超过100磅！！

我该怎么做呢？

  • 0
    TI__Guru**** 2482105 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    [引用 user="smit majithia"]我想使用大于100 pt 的大字体！

    请注意-"嘿"远远不是一种尊重的称呼-它证明太强-几乎是一种命令。    因此、这不是鼓励他人帮助您的理想方式！   (在我们的案例中-您/我"再次设置"。)

    解决您的问题-让您检查 MS Windows (一般)如何创建和管理其“可缩放字体”。   检查熟练他人的"技能"方法-通常可以节省您的时间和精力(在本例中为几天)。   不过、有一个注意事项- (许多/大多数 WIN 字体受版权保护-您必须小心操作。)   确实存在"免费字体"-通常这些字体不是看起来那么引人注目-但值得您搜索。

    如果您找到可接受的字体-请检查以确保它可以缩放至30 "点" (可能会转换为30 "像素")-如果您的目标是一些"平板显示器"。   (BTW -您的巨型字体的显示工具-是无声的！)

    假设您可以找到足够的字体-并且它本身可能扩展到30个点(或超过30个点)、则您应该能够"放大字体"为原来的四分之一。   基本字体的每个像素将被处理、以产生总计16像素(4x4像素簇)。    通过这种方式、30像素字体将扩展到(30x4 = 120像素高度)。   有一个缺点-您的每一个新字体的个别字符  在过去都会有一个"短"(即"锯齿边缘")-对于小得多的字体-公司/我会聘请当地的"天赋高中"-手动"清理"我们的30-40 (最大)高度字体。   

    一种更好的方法是使用功能强大的计算机(理想情况下是 PC)来"移动和删除"新字体的任何/全部粗糙边缘。   然后是那些"PC 处理的字符"-这将构成您的 Giant Font。   (我相信 ARM M4无法完成此类任务-会显著降低屏幕写入速度。   220MHz Cortex M7 (可能)目前可以工作、但这种成就尚不清楚。)

    该供应商图形库的"恐怖"之一是"将所有字体数据置于 MCU 的内部存储器空间中！"    没有(真实)图形设计器会这样做-因为这会导致：

    • 每个/每个程序加载都需要更多的时间
    • "吃内存"-完全基于此类字体的大小和数量
    • 进一步-图形图像-也会(仅限)存储在 MCU 的存储器中-导致(偶数)额外的延迟和资源损失

    过去(真实)的图形设计人员将确保此类字体和图形图像数据存储在快速访问中、而外部存储器中、从而避免 上述2个"致命缺陷"。  (我认为是杀手)。   相反、"外部存储器会增加成本"-外部存储器可能会"仅在开发期间使用-在(很容易)数百个程序负载期间使用"、从而(当然)节省了时间(但更可能的日子)！    以及如何节省成本！   (由于程序加载速度大幅加快！)    一旦代码被认为是"已批准/可接受"代码-那么它可以完全与 MCU 的存储器一起放置-节省外部存储器的成本-但 仍能实现-一种效率更高的开发工具！

    我们在这里的海报在他的要求上非常模糊、以至于(其他)高级方法(可能)无法得到适当考虑。    

    删除该"嘿"-同时提供有意义的细节(我会将这一决心留给您)可能会使(其他)资源丰富的方法得到考虑和(或许)展现...

  • 0
    TI__Guru**** 2482105 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好、smit、

    请参阅 Amit 的这篇文章、其中说明了需要执行的操作： e2e.ti.com/.../1483728
  • 0
    TI__Guru**** 2482105 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    人们希望过去(声称需要)将会. 索莫…… 在某种程度上 "适合 MCU"的闪存存储。   (在为用户代码留出足够空间的同时、也不会看起来太尴尬(由于字体边缘锯齿状)！  

    我刚刚读过 Amit 的过去的帖子-它没有记录(可能)巨大的尺寸-这种巨人字体-最常-需求/摘录！   在开发此类程序时、许多程序下载都 是"与课程相当"。   每一个都将花费更长的时间-由于巨大的图形字体-重复发送-一次又一次！   这不是很好！

    也可以注意到-"此处很多"-报告正在进行的"JTAG 问题。"   由于每个下载都以极高的速度增长、我们是否( 严重)邀请可怕的"JTAG 锁定？   正如这里看到的-很多次-恢复是不确定的！   那么呢？

    这种极端的存储需求会使 MCU 的内部存储器和下载机制承受多次的负担、但事实并非如此-" 长期有效-字体和图像外部存储！"的"正常/习惯"含义是指"长期有效-字体和图像外部存储！"    不是内部的！   (正如前面的帖子非常详细...)

  • 0
    TI__Guru**** 2482105 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    [引用 user="CB1_MOBIT"]我刚刚阅读 Amit 的过去文章-它 没有记录(可能)巨大的尺寸-这种巨人字体-最常-需求/摘录！[/引述]

    在太阳刚刚开始超越辉煌的太平洋的时候，一个类似的“不” 已经超越了我(非常)失败的信念(上面引用了！)     我们被教导要"找出我们的弱点"(这样他们就能被击败)、而不是"隐藏弱点"。   我错了！

    Amit 引用的 ftrasterize 程序-提供"特殊压缩！"     每一个(超过十个)"星号化"字体文件-我的 n ü crüe 和我今天检查过的-都非常紧凑！   因此-"程序加载"将"年龄男子"灵魂"的"声"必须找到(另一个)目标...

    随着"一个小岛"的完成-  发现了"有"(部分)"小岛"的弱点-以及我所在的团队今天在海边的努力-已经(希望)发现了一些富有成效的发现：

    • 除了创建严重的"未知"字体数据文件之外、还会以闪电般的速度运行 (这也是意料之外的-以及(我可以说)"喜欢！")   (该词与其(已离开)图标不同、尚未被禁止。   (可能)
    • 我们扫描了多个'48磅字体文件'-我们发现(无)超过7KB！   这是出色的。   (我期待超过250KB……)
    • 出于完整性考虑-我们也检查了(相对)较小的字体文件。   正如预期的那样-这些器件从压缩算法中获得的好处要少得多。   (即6x8字体占用960个字节-这(几乎)没有压缩-正如我们所预测的...)

    看起来像小星一样好-发现了一些缺点。   其中包括：

    • GRLib 用户指南承诺对 (许多) ftrasterize 的"创作"进行"图片回顾"。    我们曾经听到过的关于此类压缩程序的一个响亮的“敲门”-它们生成的字体(原谅)是“丑”。   因此、我们参加了《图形用户指南》的第16节-并了解 到空白 空间的"页面后"-不是 ftrasterize 输出的一个演示-已公开！   地雷被标记、"文献编号：SPMU300E、 SW-TM4C-GRL-UG-2.1.4.178 - 2013年4月- 2017年2月修订。  (这被认为是"可恢复"的电流-是不是吗？   为什么所有的光栅都是空白的？   我们提供了多个"页面捕获"、以说明空白空间的存在。
    • 原始海报"特别请求"字体超过100分。   今天我们学会了这个小行星，它的顶头是100分！   (不会运行-超过100点限制！)
    • 我们还了解到、即使在 ftrasterizer 运行时、某些"宽"字符也可能无法正确呈现。  (它们显示为"请求超过256字节"-没有进一步的解释！)
    • 而"星型化器命令"(柚 es)允许(视在) 100点焦炭高度-实际上-大约为该值的三分之二-是可以实现的最佳值！  (100分之1的很好的1/3 -专用于"小写"字符""destender"和"行间"间距。   虽然(不)在中上升到违约、但"广告中的真相"(建议的内容)未交付！
    • 有人提到了一个"包装器"-它(可能)启用字体存储(正如前面有人建议的那样)-片外。  (MCU)  但图形用户指南指出、此类信息并未提供、而且要求似乎也是合理的。
    • 我们提取的数据-并在此处与小组分享-显示(大部分)字体压缩、以生成 '6：7'的"字符宽高比"。   现在在 Display Biz 中工作了-众所周知、'5：7'是最令人愉快的-而'ftrasterizer'的输出似乎产生了一个远更多的'blocky'(近方)字符。   我们都希望看到该输出-空白页(单独)-填满了我们的"可选的屏蔽"。

    以下是这些结果的支持文档...

    我们对"红色十月"( ftrasterizer 的输出)的搜索结果显示(一致)：

    和

    这些空白图像继续-在每一张上-"字体说明"页面...     我是否说过...  我(真的)喜欢"字体压缩"？    我们如何(真正)查看压缩字体的外观？

  • 0
    TI__Guru**** 2482105 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    那么，我的3.5英寸屏幕上是否有任何方法可以显示>100 pt 字体？
  • 0
    TI__Guru**** 2482105 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    以下是我们(过去)为国防客户端开发的两种(非常)大字体：  (甚至在'LMI '(Stellaris 创始人)诞生之前！)

    这个特定的屏幕在沙漠中使用"实况"-在"行动"期间。   由于强烈的热和强烈的冲击/振动、LCD 顶部的"密封件"被穿孔、但显示屏和我们公司的电子设备仍在继续。   我相信这款图形控制器是我们在 LMI 的 ARM Cortex M3之前首先使用 ARM -这是 AT91SAM7S。   (他们是否可以平静下来-但对于600人-我们保留库存...)

    这个76像素高： 屏幕为 QVGA - 320x240像素 - 4.7英寸对角线

    这个是112像素高 (两个屏幕都是 QVGA - 320x240像素- 4.7英寸对角线

    请注意、较大的(4.7英寸对角线)屏幕会产生(自然)较大的字符-与点或像素数无关。   112像素字体被"剪切"(您可以看到其顶部)"0"是真正的-"自动缩放字体"-"2"是位映射。   请注意基本字体- 112像素"0"下方约有30像素行。

    好的、有几种"解决方案"、 欢迎您...

  • 0
    TI__Guru**** 2482105 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    是"较大(4.7英寸对角线)屏幕会产生(自然)较大的字符-与点或像素数无关。"

    现在，我想说的是，高密度显示屏，如320x480，具有更高的 DPI，那么这将使我们必须使字体更大，以实现如此高密度的屏幕！

    我对吗？
  • 0
    TI__Guru**** 2482105 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    随着字体像素库存的增加-屏幕保持合理(大小)一致-然后是-较高的 DPI 确实会导致"比通常更大" 的字体要求。  (生成目标的"可视字体规格"。)

    您(可能)能够"帮助自己"。    'Ftrasterizer.c' 出现-在其所有'nake'源代码荣耀中-等待您的'killed'检查。   

    正如我的报告清楚地表明的那样、代码"削减@ 100分"、但这既没有解释也没有详细说明。   也许-您可以扩展该上限-使您能够生成更直观的字体。

    也就是说、我的报告(也)检测到、随着字体"放大"、它 "会突破256字节限制" (谁知道？  这也是我的报告中的内容)。   

    通过查看源文件、您可以确定-"如何或(偶数)如果"-(两者都)  克服"100点限制"和"256字节限制"(可能)...

  • 0
    TI__Guru**** 2482105 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    然后我应该把我的图书馆变成我自己的图书馆，而不是使用 Ftrasterizer.c，或者我应该学习 Ftrasterizer.c 的工作原理，使它发生100分以上，这是 Ftrasterizer.c 的一个遗憾问题，或者我们可以说的是限制！ 是否可以升级到 Ftrasterizer .c 的制作者、以便此问题不会对您的客户造成！
  • 0
    TI__Guru**** 2482105 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    [引用 user="smit majithia"]是否可以将其升级到 Ftrasterizer.c 的制作者[/引用]

    这是该供应商的责任-(我与该供应商有(唯一)盈利的"用户说明者"关系。)   [不知道您是否有这种意识]

    您必须考虑-在我在这里的所有时间(现在> 10年)[在'被赶走'之前-用沉重的"无样 e2e crüe。]   我没有遇到过这样的“巨人”(不仅仅是更大的)字体请求。

    随着您的成长/成熟、您将了解到"大销售额"和那些"重要元素"(当然)会产生此类")获得 了供应商的极大关注。   (正如他们应该-这里-和(其他)半供应商！)

    在那种"内在"的情况下-"您"如何评价 这样一 种、FTRasterizer "升级"的可能性？

    而且-您的问题-"主要是由"-是否由您选择的"像素太丰富"显示来解决？    (一些“感谢”的“轻”注释——不知为何错过了... 但仍在等待-- --这是有道理的。)

  • 0
    TI__Guru**** 2482105 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    Smit、您好！

    遗憾的是、我们目前不会对 ftrasterizer 进行更改以支持更大的字体。
  • 0
    TI__Guru**** 2482105 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    我是否可以注意到-我的“非常特别的解码器环”... 解决供应商的问题，“(目前不)”... "永不！"    ("类似的回报-享受-更好的机会...")