Well, if you are, thankfully 100% of your input is helping me greatly, and is greatly appreciated. That post especially put a lot of things in perspective.Pete9008 wrote: ↑Wed Mar 29, 2023 2:30 pm I'm probably doing the same as you here - I know little about your algorithms so may well be overestimating their complexity, processing requirements, need for debug access and so over complicating the solution.
If that's case it does open up other possibilities. If you are happy to work on the firmware in C/C++ it's possible that a VCU could handle the whole job. The main limitation is that the the CPU only has one core running at 72MHz (assuming it's the STM32F1 family - afraid I'm not too familiar with the Zombie) and no hardware floating point support. If that's enough to do what you need, and if you use the IO inverter board to allow them all to exist on the same CAN bus then it would be an option. If you need a bit more performance then it would be possible to offload that to a Pi and leave the VCU to just handle contactors, monitoring, etc.
Regarding the Raspberry Pi vs the OKdo board it was really the IO that caught my eye, for example the Pi 4 has 1 UART available while the OKdo has 8, the Pi has 2 SPI ports, the OKdo has 4, Pi has no analogue inputs while the OKdo does and so on. The UART and SPI in particular could be used to add CAN ports (either via serial to CAN dongles or MCP2515 type chips). Having said that it is harder to use the IO on the OKdo as a custom motherboard is needed, on the Pi you can just add shields. The best thing to do is get hold of some hardware and have a play.
On the real time side the simplest way to test it is to just generate an IO line toggle from whatever language you want to use and check it on a scope. If the worst case pulse output timing is regular enough, and has low enough jitter, to satisfy your algorithms requirements then go with it.
On the two options for controlling the motors.
Using the Leaf protocol has the advantage that you are using the motors in the way Nissan intended and so benefiting from the 1000's of hours they will have spent tuning the inverter, algorithms and motor to each other. The downside is that if you find that Nissan approach causes problems (for example any throttle ramps are too slow to suit the needs of your algorithms) then there is very little you can do about it. You also need multiple CAN ports.
The OI option on the other hand gives you much more control of what the motor is doing. If you find something that causes you a problem you have the ability to dive into the parameters, or even the firmware as it's open source, and fix it. You can also have as many motors as you want (within reason!) sharing the same CAN bus. The main downside is that it's not as mature a platform. For example until fairly recently there were still problems running above base frequency (search unwanted regen or acceleration on the forum). Hopefully that's all now sorted but I doubt it is ever going to be as well tuned to the motor or quite as stable as the OEM solution.
The algorithms really are simple, or just to say they are not driving the speed / processing requirements any more than a throttle pedal input would if it was CAN. Would you say 10 ms (required for the pulse/counter signals to keep inverter happy) would require real time? I think that will be my most critical time constraint.
Also I'm really glad you said that about ramp rate limitations with the OEM inverter controls. That right there might be enough to push the whole thing solidly into the whole openinverter world. Although I would very much like to use the 160 kW units, I guess that’s not an option if I have to change control boards.
Thanks again Pete. Pretty sure you are 4,000 miles away or I'd love to buy you a beer.
