openinverter forum

I have just created github template repository with an empty openinverter style project

https://github.com/jsphuebner/stm32-template

It lets you build an application using proven hardware abstraction and libopencm3. When using the provided facilities you automatically have OTA (update via web interface) and the known parameter and spot value display of the esp8266 web interface (either Dimas or mine). Also the CAN mapping is tied right in. As opposed to Arduino you are not limited in the number of CAN messages you can send.

EDIT: I should add: I even added some comments to tell you what to do

The project is intended for any variant of the STM32F1. The differences in page size must be accounted for. E.g. the STM32F103 has 1kb page size and the STM32F105 has 2kb page size. This must be changed in the boot loader and also in the application (hwdefs.h). Also the addresses where CAN map and parameters are stored must be moved 2kb apart in that case.

Let us know what you do with it

Great video for idiots such as myself. Thanks!

This looks excellent! Thank you.

I'm totally unfamiliar with STM32 hardware. Looking on eBay there seem to be loads of variants, many of which are suspiciously cheap...
What sort of board would would you recommend for hassle-free, wifi-enabled development - with easy access to CAN / IO pins?

In the Arduino world, the Teensy 3.6 has become my favourite, so something equivalent to that would be ideal.

I would say an STM32F4 as it is an M4 architecture like the NXP MK66 used in the T3.6.

I'd pick up a NUCLEO-F401RE or NUCLEO-F446RE - STM32F4, plus a built in st-link. $13-14. It's what I'm using for the Tesla Charge Port ECU controller with no major issues. If you want more I/O, pick up a 144 pin variant. (446ZE is $19) See: https://www.st.com/en/evaluation-tools/ ... oards.html

-Matt

libopencm3 doesn't seem fully fleshed out for the F4. There seem to be fundamental differences. So I'd say this project is F1 only.

johu wrote: ↑Wed Jan 06, 2021 8:30 pm libopencm3 doesn't seem fully fleshed out for the F4. There seem to be fundamental differences. So I'd say this project is F1 only.

From that perspective, probably true. When trying to port things around, I did notice some architecture differences, especially around backup power domain / RTC, etc.

Probably this board then: https://www.st.com/content/st_com/en/pr ... 103rb.html

It's so infuriating the price difference is so small, yet performance is much larger.

-Matt

Excellent, thank you! That saves me a lot of time puzzling out what to get...

Maybe another word of praise for this, as I have been working with it for more than a year and a half now:

The approach is great on a few different fronts:
- getting the web interface for free with it is neat
- plotting in the web interface is fantastic for debugging
- libopeninv and libopencm3 are pinned, so the method signatures of underlying libraries don't just change without notice
- all dependencies are pulled in, I was skeptical initally about my_fp and a custom printf implementation (presumably taken from elsewhere), but it is much simpler if you can just go down and check the implementation directly *

Caveat:
- libopencm3 is unfortunately a leaky abstraction, but if we are that close to the metal, maybe better to use it than nothing because that would end up being the development of another framework (1)

* Dependencies I can't stress enough, that is such a mess in the rails/python and especially JS ecosystems. Just today I am taking code from another project and merging it into my stm32-template based firmware to get my I2C status display working, and most of the work is eliminating needless dependencies. Getting node.js flashbacks.

Thanks, great to hear I think it deserves an update to using floats and some other recent libopeninv changes

I have updated the template to the latest libopeninv
Most of all this means that the CAN module uses a new memory layout for storing messages which is less wasteful and allows more than 8 items per CAN message.
By default, 70 CAN items are possible that can be freely assigned to up to 10 CAN messages.

Also the new structure allows specifying an 8-bit offset and the gain is now specified as a float value. So no awkward messing with fixed point notation and no weird RX mapping with a factor of 32. Just the factor you need, that's it.
Reading back the CAN mapped is limited by the printf() function that only allows 5-bit fixed point. So a gain below 1 will be shown inaccurately and below 0.03 it will show as 0.

If you merge an existing project to this CAN module you will find that you loose all mapped CAN messages. Either re-assign them or wait until a legacy reader for the old format is implemented.

Potentially a stupid beginner mistake, but bare with me...
I cloned the template project, followed the given instruction and finally tried to compile without making any changes yet, but I get the following error: What might be the issue?

argh, some versions of gcc need this function defined: https://stackoverflow.com/questions/920 ... re-virtual

Just put somewhere e.g. in main.cpp The function will never be called