2009/2/19 Ritchie <[email protected]>: > > I vote for 4 because IMHO you only use hd44780 in 4 bit and st7036 in > serial ore i2c so you would have only 3 libraries so far. Clear. I suggest we implement it in two files and provide a lib for each combination supported (tested?) that includes the two libs.
> Why use hd44880 in 8bit or st7036 in 4 bit ore more?, it only cost you > IO and you gain nothing. For 8-bit over 4-bit - it is faster. There are some situations where you want to spent as little time as possible on the lcd. > So why create/offer a lib which will not be used. But you do have a point - some combination swill be hardly used. But they won't take too much effort to add either... >> lcd'put creates a pseudo-var. So the user can do: >> lcd = "A" >> And this enables to use this lib with print.jal and format.jal > > can i read some information about this, looks nice. It is described in the jal manual. The short version: a 'put procedure creates a pseudo var, which you can assign to. When you assign a value to this pseudo-var, the procedure is called. a 'get function (!) create a pseudo var, which you can read from. When you read, the function is called to provide the requested value. And of course, you can provide both 'put and 'get for one var. One caution: don't use a var named like the pseudo-var. It will give you very strange errors. Other caution: when you get strange errors, make sure you don't have a var that has the same name as the pseudo var ;) Back in the old day's, I used to think that pseudo vars did not add any value but just confusion (just like calling procedures without parenthesis). But Stef showed very powerfull feature: use the pseudo var to create a char (output) stream and use this 'var' as a calling parameter, just like file pointers in many other languages. >> The decimal and hex functions are already in print.jal, but without >> the leading 0x. Maybe we should add a function to print this 0x (like >> print_crlf). > > why option? 123 could be decimal and in your case hex but 0x123 can > never be decimal > and is always hex. > i think if the value is not decimal it should have its appropriate > leading like 0x for hex and 0b for binair. I use hex and binary a lot for debugging and I don't want to waste time and display space on these prefixes. So optional (either as param, global flag or addition/different functions). >> > but for lcd_date, lcd_bvalue* and lcd_wvalue*, to put them in >> > print.jal without change i don't know, but to change them would be a >> > pity. >> >> Can you explain why we should not put them into print.jal ? And why >> would it be a pity to change them? > > lcd_date should not be a problem So please move/adapt it. > the others have options nice for lcd > but useless for serial interface. > but to remove the option make them less flexible for lcd. So this must be/stay in lcd_common. > i can send you a hd44780 library and test file with all options so you > can see what i mean (and maybe you don't like it or have better > ideas). Okay, send me the files and I'll have a look (probably this weekend). You might send the comment in dutch... Joep --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
