I do think sockets will be the way to go for pretty much all of the interfaces. CAN and single wire CAN are obvious candidates for going with a native socketcan interface. Some of the other protocols might be a bit of a stretch. But, there exists two possibilities.
1. We can create another socket type for them. Currently you can create TCP, UDP, etc or CAN sockets in LINUX. It'd be possible to create something akin to socketcan but instead it uses a different socket type, perhaps K-LINE could be a socket type for instance. This would be kind of a bum deal as other programs would need to be specifically written to take advantage of the new socket types. 2. Make everything a socketcan interface and fudge the details to match. I don't think all of the other protocols have the same ID and data configuration as CAN and not all of them are broadcast buses like CAN but those low level details can likely be abstracted away. Then every interface can exist with a socketcan compatible interface. Technically CAN frames have either 11 or 29 bit IDs but you'd need to store the ID in a 32 bit field. So, the upper 3 bits could even be abused to specify protocol. 0 = CAN, 1 = LIN, 2 = K-Line, etc. Then you'd have that info right in the ID but perhaps that isn't necessary. We'd already know that a given interface only supports a specific protocol. The end result would be that it's possible to capture and send LIN traffic or some other interface type from any normal socketcan compatible program. However, some socketcan programs might be hard coded to expect no more than 8 data bytes. Some of the other interfaces can send and receive larger payloads. But, CAN-FD already goes up to 64 bytes and that's possible in modern socketcan implementations so the danger should be limited. I think option 2 would work fine. If someone wants to do that then that's great. I can assist as needed. On Mon, Apr 23, 2018 at 9:56 AM, Jason Kridner <[email protected]> wrote: > > > On Apr 22, 2018, at 6:37 PM, Drew Fustini <[email protected]> wrote: > > Good to hear your interest. I recently saw the PocketBeagle adapter for > Macchina in the Car Hacking Village at CypherCon. I was talking to Will > and Earl at Macchina (cc'd) about future possibilities. > > My understanding is that one issue is that SocketCAN support had not been > sorted out yet. I think it would be awesome if this is something you're > interested in working on. > > > Is there any challenge to SocketCAN? Wouldn’t it “just work” like any > Linux system with CAN? > > > Thanks, > Drew > > On Sun, Apr 22, 2018, 1:33 PM <[email protected]> wrote: > >> I don't see any updates on this thread since December. Has anyone done >> any work with this since then? >> >> I am currently a computer science student soon to graduate, but I have >> many years of experience tinkering. I am familiar with dealing with >> external hardware from computers although computers such as the RPI, >> Arduino and the beagles are a somewhat new experience for me. >> >> Anyhow, my summer project is to build new firmware for the stock M2 unit >> and I am hoping to start working on some stuff for this as well. I really >> want to learn how to build Linux drivers and this may make a lot of sense >> for me to learn on. >> >> My Goal would be to add full Lawicel 2.0 support to the board and go from >> there. Lawicel is what defines SocketCAN and the intent is to expand it >> beyond JUST CANBUS to other protocols as well. Still maintains full >> compatibility with Standard SocketCAN but adds similar support for the >> other devices as well. Such as J1850VPW, LIN etc. >> >> As it sits right now is there a low power mode for this board? Eventually >> I hope to have some of these installed full time in my truck to do some >> interesting projects but I need to be able to make them sleep when the >> truck is not running but be able to wake if necissary. >> >> >> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit https://groups.google.com/d/ >> msgid/beagleboard/173b61d0-1312-4081-b262-c193aa52371e%40googlegroups.com >> <https://groups.google.com/d/msgid/beagleboard/173b61d0-1312-4081-b262-c193aa52371e%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/beagleboard/CAEf4M_CxwF9749W_PFNWmq4u%3DKKnc7y7YO3V-XrdH%2BrRhPHW_w% > 40mail.gmail.com > <https://groups.google.com/d/msgid/beagleboard/CAEf4M_CxwF9749W_PFNWmq4u%3DKKnc7y7YO3V-XrdH%2BrRhPHW_w%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CACvDBr9Zd%2B2LJAU5TM4qBw5Ue0jVzZjw_%3Ddd_Z%2BsxUstcTGKHA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
