Greetings Seb, Thanks for your feedback. I appreciate it. This is great, and the only way I can think of to learn the nuts and bolts of JALLIB and the SVN.
I'll make some changes, test, and re-commit to svn. Let me try to explain a bit more about what I'm doing -- CAN is a little bit like the LCD I think. You have external CAN controllers -- the mcp2515 from Microchip, but many others like from Philips/NXP. Next, you have more modern chips like picmicros that have built-in CAN controllers, like the 18F458. And even more recent, 18F2585 with 'enhanced' CAN controllers built inside. Microchip refers to their internal CAN controllers as 'CAN' and 'ECAN'. In theory I suppose you could even have a software bit-bang CAN controller, but that is not interesting to me. Now then, back to LCD and your LCD support in JALLIB You have 4-bit LCD wiring, 8-bit, even 1-bit (serial), so, I see now that each library has file named lcd_something. OK so far. And inside every one of those LCD libraries you have common names -- lcd_init(), lcd_clear_screen(), etc. This makes applications easy to write, and to re-use, no matter which LCD is needed for a particular circuit board. Whether the LCD is 4-bit, 8-bit, or even 1-bit, the application just has to call lcd_clear_screen(). This is great! So, what I was hoping to do was, for example, can_send(), can_receive (). They should be like lcd_init() and lcd_clear_screen(), and be available, no matter if you are using an external mcp2515, and internal CAN, or an internal ECAN. Then the higher-level CANopen routine can just make calls to can_send () and can_receive(), and not really care which low-level library is providing those functions. Does this sound OK? And by the way, you may have missed internal/ periperal/can/can_legacy.jal and protocol/canopen.jal. By the way, 'can_legacy' is perhaps a poor name... But maybe good enough for now. The problem is: Microchip has different flavors of internal CAN controller. The early stuff was called 'CAN'. The 'ECAN' controllers have a 'legacy mode' which is what I am testing first. Some day I may try the really enhanced features but not right now. Thank you, William On Aug 27, 12:54 am, Sebastien Lelong <[email protected]> wrote: > Hi William, > > I've seen your last commit about CAN libs (BTW it won't wake up buildbot > because I've updated yesterday and wasn't listening). > I've seen this lib: include/external/can/mcp2515.jal > > This lib has to be prefixed by the type of part it is about. JSG says: > > """ > > - <device-family>_<device>.jal for external libraries. device-family > describes the device family (...), and is often the directory name where the > lib is. device precisely sets the part. > > Ex: lcd_hd44780_4.jal, rtc_ds1302.jal, co2_t6603.jal > > """ > > So I'd suggest to rename it (svn rename) to "can_mcp2515.jal". When it's > included in packages, where all libs are flatten (no more "can" directory), > users instantly see what this is about. > > Now about naming convention of the content. JSG is quite fuzzy about this. > This idea here is deal with the question: what if there's another CAN lib > handling another part ? Will there be any collisions ? Sometime this is by > design (serial libs), sometime it must be avoided. > > """ > > All external names (of global variables, constants, procedures and functions > available to application programs) must start with a prefix unique to the > library. Names of other global entities (not supposed being used by > application programs) should use this prefix and use an additional > underscore at the beginning. > > Variables, constants, procedures and functions must be named as: > > - <device>_<whatever> if you want to avoid namespace collision > - <device-family>_<whatever> if you want to have a common API > > """ > > Read section "Constants, variables, procedures, functions" for more and for > examples. > > So, does it make sense to have multiple CAN via multiple parts ? If so, you > should prefix with "mcp2515_". If the purpose is to be able to choose > another lib like this one, but for another part, without changing client > code, then API shouldn't be mcp2515 specific. Still you'll have to prefix > with "can_" (this is what's been done for proc & func, but must also be done > for const & var). > > Ex: > > const REC = 0x1D > > is little bit short, and may collide with a lib handling record (!), where > "REC" would an action code for instance. > > const CAN_REC = 0x1D > > makes it more specific. Kind of "namespaces by syntax"... > > Cheers, > Seb > -- > Sébastien Lelonghttp://www.sirloon.nethttp://sirbot.org --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
