Hi > So then you get lcd.jal with the options serial, i2c, 4bit or 8bit for > communication > and the options dot and char for graphic and character lcd (if > needed). That's the other way around then Rob suggested. So we have 4 options: 1- choose the interface-layer (const LCD_CONTROL=4) and then include the control layer (include hd44780) 2- choose the control layer and then include the interface layer. 3- include both 4- include the combi (inlude hd44780_serial)
Please vote! > The functions _lcd_write_data which combines al 4 comunications (case > selected), _lcd_cmd and lcd_init also combined for all communications > and graphic or character (if needed) also in this lib i think, you > agree?. In some of the options above, case selection can be used. For example to choose which implementation of _lcd_write_data is actived or included. > Than in lcd_control.jal the functions lcd'put (why not just lcd), 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 > lcd_clearscreen, lcd_clearline, lcd_setcusor, lcd_cursorleft, > lcd_cursorright, lcd_displayleft, lcd_displayright, lcd_home, > lcd_progress. I think this are most of the control layer functions - functions that all (most) LCD's have, but differ in the way they are implemented from controller to controller. You have to check the datasheet to see if this list is complete ;) > you can put lcd_bvalue_hex, lcd_wvalue_hex and lcd_bvalue_bin in > format.jal if they are not already in. 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). > 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? - If it is worth keeping and can be used on, say, serial ports too, then we should move it to print.jal - If it is worth keeping it and it is lcd-specific, we should put it in lcd_common. - If it is not worth keeping, we should not put it in a lib ;) > please correct me if i am wrong, You're not! We need to discuss these issue's to get it right. > If this is the way you all want to go with the lcd i can see if a can > make a start > > > i also removed the test files for st7036 and rtc_ds1302 so that > buildbot will be happy again. > please let me know your ideas (also Rob, Seb and others). > > > Richard > > > >> If the interface is well-designed, I could use the same setup for the >> glcd lib and thus support the grapical dogm displays... >> >> Joep >> >> 2009/2/17 Ritchie <[email protected]>: >> >> >> >> >> >> > On 16 feb, 18:54, Joep Suijs <[email protected]> wrote: >> >> 2009/2/16 Ritchie <[email protected]>: >> >> >> > About lcd_st7036.jal (or maybe rename to lcd_dogm) >> >> >> Would it be a good idea to change it to dogm? >> >> > The graphic display can also be added in the library although it uses >> > an other controller. >> > Both are serial and look a like, then dogm would be obvious to name >> > the library. >> >> >> Isn't this lib compatible with other displays with the same controller? >> > as far as i can see means same controller, same protocoll and thus >> > compatible >> >> >> And I suspect it is not (yet) suitable with all dogm displays (i saw >> >> there are graphical ones also). >> >> > i think the fuction _lcd_write_command() can be used for sending the >> > actual information but making al kinds of nice fuctions like line(), >> > circle(), squar(), etc.would be a lot more difficult. >> >> >> > I changed the lib >> >> > to make it the same as hd44880_4.jal >> >> >> I think this is a good thing - a library that provides similar >> >> functionality should have the same interface. >> >> > OK but this could mean we have to add the same procedures we are going >> > to add to lcd_st7036, related to non graphic (if combined), to Rob,s >> > hd44880_4.jal and hd44880_8.jal. >> >> >> > and therefore removed al the extra functions and put those temporarily >> >> > in addition.jal >> >> >> > I agree with you Joep, it is also my idea to add al the nice, useful >> >> > functions from addition.jal into print.jal, ore format.jal like the >> >> > time and date procedure and all the function only related to lcd like >> >> > the clear_line and shift left or right or progress bar put them in all >> >> > the lcd libraries (if Rob agrees). >> >> >> Maybe we should have an lcd_common library that has functions that run >> >> on all (most) lcd's. >> >> > This is off course possible but than you have to add 2 libs in your >> > main file instead of just one. >> > It also does not make it easier to use and it does not save memory of >> > the controller and hardly any of the harddisk so why make a special >> > function lib?. >> >> > I only split lcd_st7036.jal because I thought you all want this, but I >> > don't see the benefit of it. >> >> >> If you look at the functions that are in addition, could you split >> >> them in three groups: >> >> - ones that are specific for this display (like lcd_home, >> >> lcd_shift_right - i suspect they are different on other displays, >> >> not?) >> >> > no, same on hd44880 >> >> >> - the ones that are generic stream candidates (i think lcd_date, >> >> lcd_string; the lcd_b* and lcd_w* do provide a bit extra over the >> >> print/format candidates - would that be worth to add them as separate >> >> functions?) >> >> > lcd_string is same as in print.jal, I added because off only needing >> > one lib for lcd. >> > lcd_date is very flexible it would be nice to keep him this way no >> > matter where he ends. >> > lcd_b* and lcd_w* are non leading zero optional left alligned, signed >> > or unsigned, with or without decimal point line and row. >> > if we remove line and row, it would be a nice procedure to add to >> > print (although left alignment is not useful for serial transmission) >> >> >> - The ones that work on any display (lcd_progress?) >> > t least on st7036 adn hd44880 >> >> >> > All the fuction you see in addition.jal are working also on hd44880 >> >> > lcd,s so not only dogm related. >> >> >> Do you mean that the same fuction works on the 44880 or that the 44880 >> >> > I mean i wrote to libraries with the same procedure calls, one for >> > st7036 and one for hd44880, so yes the same function works on hd44880 >> > with the sam fuction call. >> >> >> support the same feature, so there should be a function too? >> >> >> > If you want the dogm to be added to jallib, I think all functions and >> >> > procedure calls on both types should be the same. >> >> >> Definitely. >> >> > as i said before, this means we have to modify hd44880. >> >> >> > Also why not add the lcd_init() call in the library in stead of in the >> >> > main file? >> >> >> This is a matter of taste and iirc we debated about this. The way it >> >> is now, including a lib on itself does not generate any code. >> >> > OK clear, i will remove him from the lib and added in the comments >> >> >> > If you have the March edition of the Elektor magazine you can see the >> >> > lcd on page 37 and also on this side: >> >> >http://www.lcd-module.com/products/dog.html >> >> >> I just build a board with a graphical display (128*64) to create a >> >> lib. I wish I had not so I needed to buy such a neat display... >> >> > Not only need but very cheap >> >> > Please let me know which procedures in lcd_addition.jal you all want >> > in which library so I or somebody else can add them. >> >> > greetz >> >> > Richard- Tekst uit oorspronkelijk bericht niet weergeven - >> >> - Tekst uit oorspronkelijk bericht weergeven - > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
