openinverter forum

Oh yeah does anyone have any pinouts for the gen 3 prius resolver connector plugs by any chance?

Jack Bauer wrote: ↑Thu Jan 14, 2021 5:44 pm I'm on Ubuntu 20.something:)

Hopefully try and get some prius gen3 action and E46 / Leaf inverter testing over the weekend.

Interesting! I'm on 20.04 as well, and yet `make get-deps` was all busted for me.

If you get those two going you'll be pretty good to go, rather quickly I might add.

-Matt

I think its busted because I didn't do the Johannes magic linking thingy with his repo.

I tried to build the stm32-vcu code earlier but ran into an issue, I believe it didn't build openlib. I'll be looking at it in the morning as I want to make the Prius changes.

Ok, I'll make a branch with the code re-org'd a bit and with git submodules called submodules_and_split. You should be able to work off that.

I'd also recommend Damien check it out fresh and try it:
git clone <your clone url> stm32-vcu-with-submodules
make get-deps # should do all the heavy lifting.

Note this is not done yet and won't be until about Midnight UTC.

-Matt

Just touching back on the hardware, JLC seems to be out of STM32F105RBT6s, they alternatively do show these available.

https://jlcpcb.com/parts/componentSearc ... 32F105RBT6

Thats funky, quick skim over data sheet makes it look like a Chinese copy of the STM32.
Also noticed the STM32F103 is now a basic part but it costs 5 times as much as the GigaDevices part.

Ive been reading issues of STM32 supply with a global backlog. Prior to today, I’ve never heard of Gigadevice, but they could be a potential alternative. I’m not sure I’d risk my inverter on one just yet.

jon volk wrote: ↑Thu Jan 14, 2021 8:57 pm Ive been reading issues of STM32 supply with a global backlog. Prior to today, I’ve never heard of Gigadevice, but they could be a potential alternative. I’m not sure I’d risk my inverter on one just yet.

I've been watching the cost of stm32F103s go up with each order
STM32 supply has gone haywire. PITA. Gigadevice is probably the best of the STM copycats. I'd rather pay the extra for a inverter controller

Atmel supply is fine

libopeninv has some local mods by Damien so not touching that folder yet.
However, make get-deps does now work.

I have also enhanced it such that make get-deps is no longer needed. It will automatically build things in the right order.

Working on splitting things now.

Please test this branch:

https://github.com/damienmaguire/Stm32- ... _and_split
Flash and test.

If that's happy, then please merge https://github.com/damienmaguire/Stm32-vcu/pull/5
Then merge: https://github.com/damienmaguire/Stm32-vcu/pull/6

(The branch submodules_and_split is the combination of those PRs - to make the changes easier to read, I split it into two so that stuff didn't get lost.)

I moved some stuff out of the global namespace, turned the E65 stuff into an actual class, and made use of enumerations we already had, rather than redefining BMW_E65.

All comments on the PRs are welcome.

-Matt

Thanks Matt. So on bench test all looks good except message 0x332 is being sent constantly very quickly! It should only send 3 times at startup.

Reposting this from Patreon just to keep people up to date on the plans :
So I'm now finalising the V1 release design based on the 100 pin variant of the STM32F105 and a larger ecu housing featuring a 60 pin connector. I'm also dual footprinting for an F405 for future extra horsepower like flexray and ethernet as seen in many modern vehicles.

Currently Lexus GS450H and Leaf Gen1/2 inverters are supported as well as vehicle side can integration for BMW (E39,E46,E65) There is also the start of a VAG vehicle side module . I expect the software to be continuously improved with more modules and features and less Damien generated bugs as more people get involved. Things like AC charger control, CCS , Chademo , etc are all possibilities.

How do you think about adding support for the brake vacuum pump? Like reading an analog vacuum sensor on a generic analog input and switching a beefy mosfet on some also generic digital output? And maybe the fuel gauge sender from stm32-car?

Sorry if you already thought of it and mentioned it a few pages back, I'm in lazy mode

Yep will do.

I have a suggestion for longer-term consideration with never revision of ECU, is if there would be the ability to add support for chargers, such as the outlander charger + DC:DC, which is fairly readily available. This would require one analogue input + pullup to detect the change handle is connected, everything else is done over CAN.

Can do. Working on the gen3 loom now.

+1 for Dilbert's suggestion.

Loving this. Hugely appreciative of your efforts.

I guess a number of amplified PWM outputs and voltage divided analog/digital inputs can be used to cover future requirements.

It is also good to have pseudo-analog outputs, PWM -> RC filter -> NPN transistor. For things like fuel gauges and such.

Jack Bauer wrote: ↑Fri Jan 15, 2021 9:34 am Thanks Matt. So on bench test all looks good except message 0x332 is being sent constantly very quickly! It should only send 3 times at startup.

Hopefully that's some stupid logic error.. should be an easy fix.

If that's it, we're on our way to slaying global variables that don't need to be.

Ah, yes:
https://github.com/damienmaguire/Stm32- ... ef7425R110

I forgot the if check there. Fixing.

Ok, a simple git pull on that submodules_and_split branch should fix you all up.

I updated PR #6 with the fix if that's all it takes.

-Matt

Nope. 0x332 is still spitting out at warp speed

Uhhhh

https://github.com/damienmaguire/Stm32- ... ccb9af8fbe

What am I doing wrong here then?

If not init, init, and set it to init...

Edit - Side note: I have an interview to give in 30 minutes so can't fix until after. But hopefully Johannes or someone else can figure out what I did dumb

One option for generic hardware might be to include a cheap microchip Digi-pot(s), these are SPI based and can contain one or more pots. You could use them to simulate thermistors or fuel senders. The instrument cluster would just see a simple resistor so should be happy.

Ok I don't understand some of the new symbols in use here but it looks like we are calling DashOn() every 100ms but we should only call it if T15==on so that is my fault from the original code.