Hi Matt, 2011/3/15 mattschinkel <[email protected]>
> Seb, Please have a look at my changes, let me know what you think. I > am fairly happy about API except that there are many things to rename. > Right > > Maybe we can start by changing everything from "lcd" to "glcd". I agree > I'll > read through everything carefully and give you a list of things I > think could be renamed. Maybe you can do the same? > OK, I'll do > > I did some changes to allow block writes, OK, I'm currently trying to understand :) I'd like the "usual" way to deal with font to be the default way. That is, using font table, with a lcd_write_char() display specific procedure. It's not hard to understand, and this is the most common way to do this (after several readings related to this topic). This usually is the most efficient way too. (are block writes some sort of lcd_write_char() refactoring ? I'm continuing to dive into this...) > the user has an option: > 1. Use write_char_pbp - used if GLCD_USE_BLOCK_WRITE = FALSE, or if > GLCD_USE_BLOCK_WRITE is not defined. This is the most basic (slow), > anyone can use it and will be able to print all font types. The only > requirement is a write_pixel procedure. Anyone that creates a new glcd > library will have fonts working in no time :) > But, according to me, this should *not* be the default. > 2. Use a custom write_char procedure (like you did in nokia lib) > This should be the default (notice it's also what most people did) > 3. Use write_char_block - used if GLCD_USE_BLOCK_WRITE = TRUE, A very > efficient way to write characters, but can only use the font type that > is most efficient for the glcd. This has these requirements: > > All of the below can be defined in glcd device library for option 3: > -- glcd_block_address(x1,y1,x2,y2) - set start x,y and end x,y > address > The "end" address seems to be specific to your GLCD. > -- glcd_block_write_color(color) - write a color to each pixel in > order > will this work for any GLCD too ? > -- const GLCD_BLOCK_WRITE_TYPE = FONT_TOP_LEFT_HORIZONTAL - most > efficient font type for glcd. > >From the lib point of view, this looks like a sanity check, right ? > > It should not be too difficult for you to try option 3 since you have > a cache. Option 3 also allows fast printing of images. See > glcd_draw_image(), you can add support for drawing 1 bit color images. > OK, I'll try BTW, I got warnings using your last glcd_common.jal compiling my nokia samples: glcd_common.jal:104: warning: assignment to smaller type; truncation possible glcd_common.jal:130: warning: assignment to smaller type; truncation possible Faulty line (the same for both cases): lcd_write_pixel(byte(x+j),word(y+k)) Indeed, my display has only 84 pixels width, no need for a "word". You've been using "byte*GLCD_(X|Y)_SIZE" to deal with this, let's continue: lcd_write_pixel(byte*GLCD_X_SIZE(x+j),byte*GLCD_Y_SIZE(y+k)) Yes, it compiles fine ! :) I'm not sure that: byte*num(variable) is a supported way of typecast a var, maybe Kyle can confirm. Doc says "WORD is simply shorthand for BYTE*2", maybe that's what's happening behind the scene... (casadeyork.com seems to down btw) Cheers, Seb -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
