Hi,
I converted the X font 5x8 for use in BB and added an goto_xy routine in case anyone wants to put something entertaining on the LCD (besides Hello World).
Compared to the old 8x8 font..
- doesn't miss the topmost line of pixels :-) - needs 475 bytes instead of 4k (only includes characters ASCII 32 .. 126) - allows for 19x8 characters on the screen
hello_world.bin prints out all glyphs for testing.
Applies to current "master" (as of 9.4.2010/15:30 MESZ).
Chris
Hi Christian,
first of all thanks for your patch.
I think it is great to have a better/smaller font. However, I cannot merge the patch as-is, as I have the following comments:
1) we need a way to select between individual fonts when writing to the display. I think in the long run it is inevitable that we'll use small and big letters on screen and have to select/ switch between them. Something like display_select_font(FONT_5x8) to be called before a display_puts() sounds like a reasonable API for this.
2) Removing all the special characters might not be the best idea to do. If at all, it should be a compile time option whether or not to drop the special characters. Also, the check for replacing a character with '?' needs to be a font-specific and not a global decision.
3) introducing the new font should be one patch, fixing the 'miss topmost line' another patch, and any experimental changes to hello_world/main.c should be yet another patch. This way we can keep the commitlog a bit more clean.
I hope you're willing to rework your code, thanks in advance!
Harald
Hi Harald,
thanks for your comments. I'll address them below.
On Sat, 10 Apr 2010 10:26:05 +0300, Harald Welte laforge@gnumonks.org wrote:
- we need a way to select between individual fonts when writing to the display. I think in the long run it is inevitable that we'll use small and big letters on screen and have to select/ switch between them. Something like display_select_font(FONT_5x8) to be called before a display_puts() sounds like a reasonable API for this.
I completely agree. The motivation for my (first) patch was mainly to have *something* on the screen (e.g. serial port Rx/Tx bytes, whatever) and that needs just a usable font and gotoxy. I never considered it a final UI library.
But if we want to do it proper, I have a few question to you and the list:
- If we stick to multiple-of-8-high fonts (at least on the C128) we can just blindly write at the proper location. The C155 (?) might have different restrictions. Is this ok or should we try to support arbitrary sized fonts?
- If we want to support arbitrary sized fonts, we either should buffer the display in RAM (might be wasteful on high res color displays?) or read/modify/write over i2c (might be slow, occupy the bus for too long). What's your opinion on that?
- Which font-encoding should we use? I know that GSM 03.38 specifies the encoding used for SMSs, but should we stick with that for on-screen output? It's not ASCII compatible regarding []{}...
Note: <steve|m> in IRC told me that prom is probably already working on that? Is he reading the list? prom, can you confirm?
- Removing all the special characters might not be the best idea to do. If at all, it should be a compile time option whether or not to drop the special characters. Also, the check for replacing a character with '?' needs to be a font-specific and not a global decision.
I agree, see also 3rd tick-mark above.
- introducing the new font should be one patch, fixing the 'miss topmost line' another patch, and any experimental changes to hello_world/main.c should be yet another patch. This way we can keep the commitlog a bit more clean.
OK, I agree with that. Btw: fixing the topmost line in the 8x8 font will have to be done by whoever contributed the 8x8 font in the first place :-)
Greetings from Bavaria,
Chris
Hi Christian,
On Sat, Apr 10, 2010 at 05:46:48PM +0300, Christian Vogel wrote:
But if we want to do it proper, I have a few question to you and the list:
- If we stick to multiple-of-8-high fonts (at least on the C128) we can just blindly write at the proper location. The C155 (?) might have different restrictions. Is this ok or should we try to support arbitrary sized fonts?
we need arbitrary sized fonts :(
- If we want to support arbitrary sized fonts, we either should buffer the display in RAM (might be wasteful on high res color displays?) or read/modify/write over i2c (might be slow, occupy the bus for too long). What's your opinion on that?
yes, we need a memory frame buffer that is periodically synchronized (if any changes have happened) to the real device by means of a low-priority task.
- Which font-encoding should we use? I know that GSM 03.38 specifies the encoding used for SMSs, but should we stick with that for on-screen output? It's not ASCII compatible regarding []{}...
I think we should use ASCII for screen output despite what the GSM standard alphabet does. libosmocore already has conversion functions I believe.
Note: <steve|m> in IRC told me that prom is probably already working on that? Is he reading the list? prom, can you confirm?
He's reading the list and the plan was to commit his unfinished code to a branch in the repository.
OK, I agree with that. Btw: fixing the topmost line in the 8x8 font will have to be done by whoever contributed the 8x8 font in the first place :-)
ah, ok, that would be me. I still have the perl script somewhwere that was used to generate the code.
Regards, Harald
Hi Folks.
I only wanted to let you know that i am still alive ;-) I am currently very busy with my industrial practical so i have not much time at all but...
Currently i am implementing an easy to use API to the basic simcard functions. After that i will build an API on top of this that handles the sim requests in an atomic way to make it easy to give other processes random access to the sim through a message queue.
regards. Philipp
Hi dexter,
Someone (IIRC, kevredon@mail.tsaitgaist.info ) suggested to implement the SIM access profile. Do you know that? Is it a generic protocol we could implement over the serial line (to access the real sim in the phone) and/or a function call interface (to access a sim through PCSC) ?
Regards Sebastien
On Tue, May 11, 2010 at 1:01 PM, dexter zero-kelvin@gmx.de wrote:
Hi Folks.
I only wanted to let you know that i am still alive ;-) I am currently very busy with my industrial practical so i have not much time at all but...
Currently i am implementing an easy to use API to the basic simcard functions. After that i will build an API on top of this that handles the sim requests in an atomic way to make it easy to give other processes random access to the sim through a message queue.
regards. Philipp
Hello Sébastien.
Someone (IIRC, <kevredon@mail.tsaitgaist.info mailto:kevredon@mail.tsaitgaist.info> ) suggested to implement the SIM access profile. Do you know that? Is it a generic protocol we could implement over the serial line (to access the real sim in the phone) and/or a function call interface (to access a sim through PCSC) ?
Why? I don't see any advantages in this and i do not have the know how to implement SIM access profile. I think it is enough if we have our own simple simcard API that works for us. We should not overengineer this.
Regards. Philipp
Hello,
I have to say that I agree with you. I was just reporting the idea I heard about :-)
Regards Sebastien
On Thu, May 13, 2010 at 5:10 PM, dexter zero-kelvin@gmx.de wrote:
Hello Sébastien.
Someone (IIRC, <kevredon@mail.tsaitgaist.info mailto: kevredon@mail.tsaitgaist.info> ) suggested to implement the SIM access profile. Do you know that? Is it a generic protocol we could implement over the serial line (to access the real sim in the phone) and/or a function call interface (to access a sim through PCSC) ?
Why? I don't see any advantages in this and i do not have the know how to implement SIM access profile. I think it is enough if we have our own simple simcard API that works for us. We should not overengineer this.
Regards. Philipp
dexter wrote:
suggested to implement the SIM access profile.
Why? I don't see any advantages in this
There's at least one significant advantage; it becomes trivial and convenient to use a real SIM in another phone on your desk.
and i do not have the know how to implement SIM access profile.
There was a link to the (pretty short) spec in the email thread.
I think it is enough if we have our own simple simcard API that works for us. We should not overengineer this.
At least I think the SIM access profile is a good idea. I haven't looked into detail, but maybe it's actually similar to the simple API?
//Peter
On Thu, 13 May 2010 18:36:31 +0200 Peter Stuge peter@stuge.se wrote:
dexter wrote:
suggested to implement the SIM access profile.
Why? I don't see any advantages in this
Did you have a look at the spec?
http://nibbler.de/attic/bluetooth/profile%20SAP%20v1.1.pdf
See page 23 and 32.
It basically implements a minimalistic remote card reader that forwards APDUs to and from the SIM. All the lower level protocols have already been implemented e.g. in the Linux kernel.
While it might indeed be not a thing to implement first, it still looks worth keeping it in mind and interfaces open for a later integration of SAP as a convenient way to access SIMs remotely.
cheers, nibbler
p.s. don't spread the link as i don't know exactly about the copyright implications of all the bluetooth documents in that folder. I happened to have an account for the SIG document repository thus found it handy to mirror the specification documents which to my knowledge are not publicly available.
Hi,
Well after seeing the spec, the protocol does not seem too over engineered. These are just messages in byte buffers that can be exchanged over any link, be it bluetooth, serial or struct{} in a function call.
So instead of reinventing a wheel that will look like this, why not implement a simplified version of this spec? we only have to implement the messages required for our needs.
Regards Sebastien
On Fri, May 14, 2010 at 5:19 AM, nibbler nibbler@ccc.de wrote:
On Thu, 13 May 2010 18:36:31 +0200 Peter Stuge peter@stuge.se wrote:
dexter wrote:
suggested to implement the SIM access profile.
Why? I don't see any advantages in this
Did you have a look at the spec?
http://nibbler.de/attic/bluetooth/profile%20SAP%20v1.1.pdf
See page 23 and 32.
It basically implements a minimalistic remote card reader that forwards APDUs to and from the SIM. All the lower level protocols have already been implemented e.g. in the Linux kernel.
While it might indeed be not a thing to implement first, it still looks worth keeping it in mind and interfaces open for a later integration of SAP as a convenient way to access SIMs remotely.
cheers, nibbler
p.s. don't spread the link as i don't know exactly about the copyright implications of all the bluetooth documents in that folder. I happened to have an account for the SIG document repository thus found it handy to mirror the specification documents which to my knowledge are not publicly available.
Hi All.
So instead of reinventing a wheel that will look like this, why not implement a simplified version of this spec? we only have to implement the messages required for our needs.
I think that does not help us much. We need a layer that abstracts the SIM functions to atomic high level functions so that different processes can access the sim randomly (This is not my idea that was haralds idea ;-)
As i can see the SAP is hooked to the low level APDU interface. Is there any way to arbitrate the requests? What is when someone from outside selects a file while the mobile already has selected a file and is about to do a read binary for example?
Anyway. I have not the time to read and understand the entire SAP spec. If you think that SAP works better for us you are free to continue the work instead of me. I will then concentrate on the SIM driver itsselef - there is much work left to do there and the low level stuff is more that what i am experienced with.
Currently we have an APDU interface to the sim. You can send APDUs to the sim and you get the answer and status word back. T=0 protocol is fully implemented.
regards. Philipp
baseband-devel@lists.osmocom.org
-
Christian Vogel -
dexter -
Harald Welte -
nibbler -
Peter Stuge -
Sébastien Lorquet