Hi Seb, Thanks for the insights. But about CAN -- yes, and no. CAN itself is a low-level protocol, and you're right, some PIC18 chips have internal/ built-in controllers. So, if you take a look, you'll see there is a new 'can_legacy.jal' library in the peripherals/can directory. But also mcp2515.jal library in the 'external' directory. Both of them handle the same low-level CAN bus messages.
But CANopen, is a higher level protocol -- sort of like TCP or UDP is higher than Ethernet itself... My intention is that the canopen.jal will operate with either the internal or external low-level can library. So, that is why I was thinking of putting into the 'protocol' directory. But you choose, or move it if I put it in the wrong place. Thanks, William On Aug 25, 10:07 am, Sebastien Lelong <[email protected]> wrote: > Hi William, > > > I do have a couple of 'Blink-the-CAN' ( couldn't resist the pun, > > sorry ) test programs that I was wanting to check in, I was thinking > > of putting them under 'test', but I see now that you'd prefer them in > > the 'sample' directory. But I also see the 'project' directory. > > Hmmm. > > Files in "test" aren't compilable on their own, they need to be processed in > order to generate a sample (basically, combination between device-specific > configuration -- stored in a board file --, and the actual test code). As a > start, I would directly put your samples into "sample". It there's a lot of > duplicated code (ie. same sample again and again, where the only different > is the PIC), then we'll migrate this under "test". > > "project" contains specific code, which can be sample, but also application > code (samples are aimed to be simple, and are just here to show how to use > one specific lib. application code can be complex and use many different > kind of peripherals & parts, thus many different libs). > > > > > Another question-- I want to start a 'higher-level' CAN protocol > > library. I see the 'protocol' directory. Presumably that would be > > the place for a 'canopen.jal' library? > > Interestingly this "protocol" directory is empty. There are many protocols > already handled in jallib, like UART, I2C. But these are built-in in some > PICs. So they remain in "peripheral" directory, because a dedicated PIC > peripheral is able to handle this. What if the PIC can't do UART ? Well > you'd use "serial_software", instead of "serial_hardware". One would argue > that "serial_software" shouldn't go to "peripheral", but actually in this > "protocol" directory, but since there's sometime a peripheral, it shows the > user this is the software version of a hardware/built-in lib. > > Now the question is: can CAN (can't resist the pun...) be handled by a > built-in peripheral ? I think so, but I'm not sure. So I'd say your CAN lib, > even it's a software implementation, should go to a "peripheral/can" > library. > > "But what should go to "protocol" ?" I can hear... I was thinking about > one-wire dallas protocol lib for instance. Or this specific protocol > handling IR remote control. Or... > > Keep in mind things aren't written in the marble, and SVN structure has been > modified many, many times... > > 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 -~----------~----~----~----~------~----~------~--~---
