On Tue, Apr 24, 2018 at 10:11 AM, Jason Kridner <[email protected]> wrote:
> > > On Monday, April 23, 2018 at 5:51:11 PM UTC-4, Collin K wrote: >> >> 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. >> > > For simplicity of reference, what are the interfaces outside of CAN and > single-wire CAN? > The M2 interface pretty much supports all of the ODBII protocols found in US vehicles. CAN, SWCAN, LIN (And related protocols), J1850 both VPW and PWM. Support for ALDL could also easily be added but would require some modifications. See the first message in this thread for more details. > >> >> 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. >> > > I looked up that K-LINE is ISO 9141-2. Don't see any Linux drivers for > that yet. I searched for sn65hvda195. What device are you using to create > the interface? > There are no current linux drivers for anything outside of CAN / SWCAN other than what Craig listed as a potential library for LIN. > > >> >> 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. >> > > Can we define a super-set along with fallbacks when the superset > (including, only the smallest subset) isn't implemented? > > >> >> I think option 2 would work fine. If someone wants to do that then that's >> great. I can assist as needed. >> > > Don't really know who'd take this on. > As a learning tool I plan to take this on. I will be working on getting the firmware working for the M2 with the Arduino CPU board and will try to get the same protocols working under the pocketBeagle CPU board. I may use the LIN library that Craig has already mentioned for both the LIN stuff and possibly for a framework to do the other protocols but I will address that when I have hardware to work with. As far as fallbacks and such.Since you have to physically enable the CANBUS ports now is this really going to be an issue? I don't believe this is done in any of the RPI add-ons that are out there. You just get an error or it freezes if you try to access a CAN port that isn't there. -- 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/CA%2B4KSnfixHcp8cnxGrpt4KDt-jVvj937i8shwWyAoOv6KC6mzw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
