2009/2/21 Wayne Topa <[email protected]>: > > My opinion is not going to make me any friends Maybe. But my guess is you won't loose any either on this list by giving your opinion.
> To me this feels wrong. If he had 'published' his code I > would not feel that way but he hasn't so I looks to me like Theft of > Intellectual Property. Taking advantage of his published work to clone > his protected work. I see your point and have been thinking about jal & lcd displays. I found two libs for graph displays, got Richard's hd44780 lib which additional features and also had an other look at the K107 options. My conclusion is that mimic the K107 maybi is not the best way to go (even appart from the IP issue you describe). There is a lot of nice code around and our main task would be to merge them without duplicating code (and remove quirks if any). For this, it is important to create the right API for the first implementation and use this API for all successive implementations, like Richard did by implementing the HD44780 interface for his dogm lib. Our current hd44780 interface is clear but limited - the controller has much more features that are not supported directly via the API (although Richard's hd44780 lib does). I think it is a good idea to add the 'standard' hd44780 features to the current lcd API. If you, Wayne, use the same API for the K107 lib and extend it for K107 features that are not supported, we create a feature-rich API that is usable in lots of situations. The next step would be to implement 'K107' features in the HD44780 interface, so this features can be used on a directly connected LCD too. Appart from this, I see some opportunities on the hardware interface level. I used to think we have 2 ways to interface (4 or 8 bit), but we have four. If we have enough pins available, we can use 4 or 8 consecutive lines, giving faster and more compact code. But we could also interface when with any 4 or 8 datalines. And with a bit of luck, we can use serial and i2c support for dogm displays without duplicating the code above. We previous discussed splitting the code into an conrol and interface part and generate a lib for each combination. After some research I suggest for now we take the interface (say lcd_hd44780_4) as the main file. This file should provide: - lcd_init - lcd_write_command - lcd_write_data and then include a common file (hd_44780_common) which provides (the rest of) the interface. What do you think about this? And in addition to this: - How do we handle the difference between consecutive versus scattered lines. We could detect if the user defines a (half) port or separate datalines and select the appropriate code accordingly (transparent) or create two different libs (that is, 4 in stead of 2). - What about documentation? The user includes a lib with a very limited api, but this lib includes an other lib that has the features the user uses. How do we put this in the comment? - In time we could create an apps that gets the data from the pic via 1 or 2 lines and interfaces this to the lcd. Not a K107 clone. But maybe compatible with dogm display, so we can convert a classic lcd into a dogm-compatible display. I'll start on the refactoring, but it is a large puzzle to get all the combinations and documentation right and tested. So I hope i'm not alone on this one! 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 -~----------~----~----~----~------~----~------~--~---
