EEVblog Electronics Community Forum
Products => Computers => Programming => Topic started by: reyntjensm on September 01, 2020, 12:14:26 am
-
Hello everyone,
I'm looking for some feedback regarding my project/ideas. I'm working on a project, it's a controller used in special vehicles( tow truck, fire truck etc). I already have most of the hardware but I'm struggling with the programming. I'm used to basic C coding but this project is much larger than everything i ever did. The biggest part of this project is CANbus, i have a lot of I/O modules that communicate with my project over CANbus. Since the controller has many other functions( blinking lights, check position, check temperature, pressure etc) i had the idea to use a (free)RTOS. I guess this would make the coding easier since i can work in small modules and test them individually. I guess this would also make it easier to implement extra functions in a later stage, i would just have to write another task and implement this in the RTOS. Since i have no experience with CANbus or freeRTOS, i was wondering if it would be a good idea to learn and use both of them or just try to write everything in one conventional c program? Since i have no experience with a RTOS i don't know if it would make life easier? Is it easy to use CANbus in a RTOS environment? I hope somebody who has more experience with this topic could give me some more information about the do's and dont's. Thank you all!!
-
It is entirely up to you. Both approaches have upsides and downsides.
I personally would not touch an RTOS if I have a choice. For me it is not worth the hassle and added complexity.
-
Half a year ago i got some inquiries about Canbus enabled products and started a development thread. It takes time to arrive at something interesting. There are lots of options, concerning the bus itself and the functional units attached. It's something nice, somewhat similar to USB if you include supply to the bus. There are isolating bus interface chips, so it can be used in noisy environments or for precision measurements. The protocols are complex when it comes to error recovery. E.G. for a start i got a Lawicel interface that is absolutely useful, but difficult for error revocery. The developer wrote me that it had been a hobby project. Probably the same applies to all those free CAN libraries. There appear to be many ways to use the hardware layer, and probably one needs to support more than one setup.
Concerning RTOS: The cost is little and you can use what you need or what you understand. There are so many online examples. As you wrote, it may help to structure your project, as you will be coding to well defined APIs. And MIPS are cheap nowadays, so a minor overhead doesn't hurt.
Regards, Dieter
-
@dietert1 thank you for your feedback. I had the same idea about the RTOS, there are many different examples listed online.
What controller did you use in your project? Where/how did you start using CANbus(resources)? I have an STM32 controller with a MCP2515. But i have no idea how to start with such project, i have a lot of experience with i2C and SPI but i never used CANbus before. I know how it works but i never used it in code. Since CANbus is such a complex topic, i'm thinking about outsourcing my code to somebody with more experience. But those are hard to find in my surroundings. Does anyone have any suggestions on this? Thank you all!
-
CAN bus is actually really simple to use! Messages go in frames and the hardware deals with the complicated byte level stuff.
All you have to do it regularly transmit messages and do something when they stop arriving.
Depending on the system you're in there may be an protocol involved like J1939 or something, this could be overwhelming but oems rarely implement all features.
The "most difficult" part of this system is the dynamic addressing, if implemented, or the various other higher level protocol memory access or freeze frames.
A preempting RTOS can definitely make the "sequential" bits of programming easier here on the higher level protocols and I would recommend it.
By that I mean the protocols that use CAN bus to get functionality. eg: reading malfunciton codes.
CAN bus is fairly low risk with concurrency issues due to the mailbox system for each CAN identifier, this is easy to mutex.
Plus, some protocols allow you be have virtual nodes. Eg: your devices combines the "window motor controller" and "mirror adjust controller" in on device, you actually advertise as two devices.
An RTOS can be very helpful in scenarios like this, if properly implemented.
-
On the host side i have been using the Lawicel Can232 and an IXXAT can@net and i made a bus with some DSub-9 connectors and terminators. Meanwhile i made a second version including supply. The supply is meant for the bus sides of isolated Canbus interfaces or for sensor nodes without further wiring.
First i used small MCP2515-based Canbus to SPI interface boards to make CANbus nodes from some MSP430 modules that we had. Then i wanted something better and got a ATSAMC21 evaluation board working. I also used an old P82C150 as a test node/bus error generator.
Currently i am trying to get things up and running on an STM32L432 (Nucleo-32 board with TJA1052i isolated Canbus interface). ST provides drivers for their Can hardware. It's all fairly simple until you start using the higher levels like CanOpen or J1939. I am not so much worried about a dynamic address scheme or about bus and node states, but about error recovery. Don't know yet how deep i have to get into that.
Regards, Dieter
-
CAN bus does error recovery completely in hardware. Unless j1939 requires some higher level error recovery, but I don't think it does.
You will like the units from Kvaser and the tool Busmaster (https://rbei-etas.github.io/busmaster/).
ST's bxCAN is a bit underwhelming, you probably need to extend it by software quite a bit to make it usable.
-
ST's bxCAN is a bit underwhelming, you probably need to extend it by software quite a bit to make it usable.
Yes, it's "feature set" in comparison with other is quite low. But I like it for its simplicity to use, at least for my own homemade protocol. You don't have to read many pages of manual to set up filters and mailboxes, just send and receive the packets and do the processing in software as you need it. Of course, this approach has is drawbacks, too.
-
In the end you want error detection and recovery at the application level. If the hardware puts a node into error passive state, you want to know that and try and get it going again. The P82C150 i mentioned causes bus errors in case of calibration timeout and it requires a certain procedure to get it going again with the correct bus mode. Many engineers think "A digital system with occasional errors should not be used.", as a rational to drop this part.
Regards, Dieter
-
Regarding RTOS:
Once you got the first steps done right, it makes your life easier in many cases. No issues using CAN and RTOS together.
-
A preempting RTOS can definitely make the "sequential" bits of programming easier here on the higher level protocols and I would recommend it.
By that I mean the protocols that use CAN bus to get functionality. eg: reading malfunciton codes.
Yep. My FSMs for handling UDS and OBD became fairly complex. I am always tempted to go to the dark side
** Kvaser + Busmaster is my combo of choice for node analysis and simulation. Especially simulation. It took me a while to get started (and things can still ble clunky) but it's a very powerful combo