On 09/20/2013 05:37 AM, Werner Almesberger wrote:
EdorFaus wrote:
Is there any reason *not* to use UTF-8, and only UTF-8, on the device?
I don't see any. For prototyping, I'd just stick with ASCII and
worry about the multilingual details later.
Yeah, that works (UTF-8 is a superset of ASCII anyway).
For a prototype we probably don't have to worry too much about it, like
you say, but should probably still keep it in mind when moving past the
prototype stage, so we avoid making design choices that make
internationalization harder unnecessarily.
I assume the simplest to implement would be a basic bitmap font, but
then we'd probably have to convert some other font to that format,
Yeah. We can use a nice big fast PC for that :)
Well, sure. Just another entry in the Makefile... :)
but the MCU selection email suggests this is at most 256kB).
It's even less. 256 kB is what the series is designed for, but
the largest parts they've made so far have "only" 128 kB.
Yeah; I figured we might not go for the largest one (and you say the
largest ones mentioned aren't even in production), hence the "at most".
I basically meant it as an upper limit estimate, to compare with an
estimate of the font size, which I expected (and you confirmed below) is
likely far larger if we were to include everything.
Which means that we simply *can't* have a full and complete font in the
on-board firmware, so we have to either support only a subset of
characters, or keep (most of) the font elsewhere (which in practice
means on the SD card).
Having said that, I'd start with everything (just ASCII) in the
MCU. It'll need some "emergency" character set for maintanance
and diagnostics anyway.
This is basically what I meant as well - that we'd keep the basic core
set of characters (those needed to show the UI etc) in the on-board
firmware image, so that anelok can still function even with a completely
blank (or missing/faulty) SD card.
Then, in addition to that, since the SD card would easily hold a
complete font, the firmware could support loading the remaining
characters from there when they're needed, if such a font file is
present, so that users who need to see more characters can add one.
It's not needed for the prototype stage, though, and is (AFAIK) a pure
software issue, so implementing it should be left for a later stage.
Hm, just from a practical point of view, we'll probably need to make
l10n be compile-time (for the firmware) instead of user-selectable
on the device itself. Otherwise, we'd end up having to store all the
various languages and lists and stuff on the device, despite most of
them never being used, just taking up precious space.
Memory card space is very very cheap :) In fact, you have to pay
extra if you really want to get less ...
Well, yes - but I'm thinking about the on-board memory space here.
In short, I feel that the device should still be functional with a newly
bought, completely unused SD card.
If the firmware requires certain files to be present on the SD card,
then it also requires a trusted PC with which to add those files, and
means the user has to perform some extra steps to make their device
operational.
We could of course support keeping additional locales on the SD card,
that the user could then optionally select from.
Similarly, if we run into space problems, it should be possible to keep
certain extra features (past the basic set) on the SD card instead (kind
of like installing apps I guess), as long as the device still functions
(for its primary use of managing passwords) without them.
Not sure what features that would be, really, but I guess an example
could be something like password strength checking that uses a database
of words that shouldn't be used (because crackers use the same list),
and the database (or maybe some heuristics code or something) is too
large for the internal memory.
Like the extended font, though, these things are not necessary for the
prototype stage. (I'm mostly just mentioning things as they occur to me,
so that we don't miss them later when it's time to deal with them.)
-Frode
_______________________________________________
Qi Hardware Discussion List
Mail to list (members only): [email protected]
Subscribe or Unsubscribe:
http://lists.en.qi-hardware.com/mailman/listinfo/discussion
