openinverter forum

Ok, think I got our problem : as we are in opmode off we do :
if(targetVehicle == _vehmodes::BMW_E65) E65Vehicle.DashOff();
which sets the boolean to false.

Then we go back to our 100ms loop and do :
if(targetVehicle == _vehmodes::BMW_E65)
{

E65Vehicle.DashOn();
The boolean tests false so we resend and so on.

Ah, yes, that's it.
So it should be Dash on if T15 true only, and then that'll stop the ping pong, yes?

Yes exactly. dashOn only if t15 true then reset the boolena when t15 false and we should be set......or clear..........or.......aaahhhhhh:)) Sorry couldn't resist:)

Yes?

Bah, implicit conversion. Bad Damien.

git pull and test again

Ok looks good on the bench. Will test in the car tomorrow:)

Ok, rinsing and repeating with GS450 stuff next. That is definitely a large chunk, and that'll probably go a long way to making the main file a little more readable.

Submodules and split branch updated:

commit eda8d42e1935609810c894d468bcb788220fa700 (HEAD -> submodules_and_split, origin/submodules_and_split)
Author: Matthew Drobnak <matthew@drobnak.com>
Date: Fri Jan 15 22:36:27 2021 -0800

GS450H: Rename class to GS450HClass.
GS450H: Move 100ms task into class.
GS450H: Create setTimerState function to start / stop timers for Serial data.

commit 9a7ff4052c90718575e9357f04da2e677aeb1b88
Author: Matthew Drobnak <matthew@drobnak.com>
Date: Fri Jan 15 22:16:52 2021 -0800

Rename Module_Inverter to targetInverter.
Update targetInverter to use _invmodes Enum instead of #defines values.

commit 68ef653667c9baecc88ac9e3ba8b125fa40d6bf3
Author: Matthew Drobnak <matthew@drobnak.com>
Date: Fri Jan 15 21:56:34 2021 -0800

Add utils namespace.
Move change function into utils namespace.
Move PostErrorIfRunning function into utils namespace.
Move GetDigInputs function into utils namespace.
Move GetUserThrottleCommand function into utils namespace.
Move SelectDirection function into utils namespace.
Move ProcessUdc function into utils namespace.
Move ProcessThrottle function into utils namespace.
Remove some whitespace.
Rename speed to previousSpeed for use with Rev limiter.
Move udc variable init closer to usage.
Move includes into stm32_vcu.h. Needs additonal cleanup.

....uuhhhh...Yeah! .....that's exactly what I was thinking:) Did a git pull and runs on the bench rig so will test in the cars asap. I'm going to have to break away for a day or two to help out some folks with the SAM3 based gs450 controller. At least that's arduino code so more tolerant of my programming "style" Normal schedule will resume shortly.

Great I'll pull down the latest version and add some code for the Prius / Auris in

Thanks Dilbert. Will have the test bench running early next week:)

Ok, great. Once we are happy that it seems to work in cars, we should at least merge the submodule fix PR which will then make the rest of them make more sense, as they should shrink considerably.

Dilbert please base your branch off submodules_and_split branch as I think you'll find it a bit more organized.

That said, Damien has seen my code before it's cleaned up, it can be quite messy at times as well!

No worries on timing of testing Damien, understood about the other stuff needing some attention.

-Matt

Thanks Matt. Its all good learning in any event. I made a struct today:)

I went to push up a new branch with support for the auris, but got a permissions error.

Looking at the auris data, there's about 20 zeros, I'm wondering is this for 3 motor systems to control the mgr. The main data appears to be in similar locations.

I haven't identified the battery capacity values yet, but I'm wondering do these change over time as the battery charges or would they be fixed

Dilbert wrote: ↑Sun Jan 17, 2021 7:37 pm I went to push up a new branch with support for the auris, but got a permissions error.

Looking at the auris data, there's about 20 zeros, I'm wondering is this for 3 motor systems to control the mgr. The main data appears to be in similar locations.

I haven't identified the battery capacity values yet, but I'm wondering do these change over time as the battery charges or would they be fixed

The github way to do this is to fork the project (button toward the top right, click on the word, not the number), push to your local fork of the code, and then open a pull request into the main project. Or Damien can add you as a contributor.

If you need help with the git piece let me know.

-Matt

I created the fork and cloned it locally. I'm now getting build errors on libopencm3

In file included from ../cm3/vector.c:22:
../../include/libopencm3/cm3/vector.h:41:10: fatal error: libopencm3/cm3/nvic.h: No such file or directory
#include <libopencm3/cm3/nvic.h>

lacking python?

I just uploaded those 2 files. I have them on my local repo. Don't know why they werent on the github version. Sorry!

Dilbert wrote: ↑Mon Jan 18, 2021 8:37 am I created the fork and cloned it locally. I'm now getting build errors on libopencm3

In file included from ../cm3/vector.c:22:
../../include/libopencm3/cm3/vector.h:41:10: fatal error: libopencm3/cm3/nvic.h: No such file or directory
#include <libopencm3/cm3/nvic.h>

I'm working my way thru that error with the main inverter code now. It appears the libopencm3 makefile uses python scripts to create a bunch of "repetitive" header .h files. I'm trying to do everything on a Windows machine, not Linux, because I'm old and stubborn. We'll see.

Will be back working on this tomorrow with the prius gen 3 rig hopefully setup.

Yikes.

Dilbert wrote: ↑Mon Jan 18, 2021 8:37 am I created the fork and cloned it locally. I'm now getting build errors on libopencm3

In file included from ../cm3/vector.c:22:
../../include/libopencm3/cm3/vector.h:41:10: fatal error: libopencm3/cm3/nvic.h: No such file or directory
#include <libopencm3/cm3/nvic.h>

As pointed out:

johu wrote: ↑Mon Jan 18, 2021 12:48 pmlacking python?

You're probably missing python. What's your build environment?

Jack Bauer wrote: ↑Mon Jan 18, 2021 1:12 pm I just uploaded those 2 files. I have them on my local repo. Don't know why they werent on the github version. Sorry!

Errr...yeah, not your fault Damien. However that's probably not the right answer. What we probably should do is ask the maintainers of libopencm3 if they'll make an actual release tag with the headers generated for a ready-to-use version. Like the current state of the world here, I'm betting that library is still considered to be "not ready for prime time".

ChazFisher wrote: ↑Mon Jan 18, 2021 3:45 pm I'm working my way thru that error with the main inverter code now. It appears the libopencm3 makefile uses python scripts to create a bunch of "repetitive" header .h files. I'm trying to do everything on a Windows machine, not Linux, because I'm old and stubborn. We'll see.

It's repetitive because it's generating a map of the interrupts that are different for all the supported ST / ARM platforms.

There are windows specific build instructions on the github for libopencm3:

https://github.com/libopencm3/libopencm3

If that helps get you going with libopencm3, great!

Damien, were you able to test any of the cleanups? If we have more people joining, we should probably get that merged. Thanks!

-Matt

In my projects I'm using a libopencm3 fork anyway as they didn't want to merge all changes. I could include the generates headers if that really helps.

johu wrote: ↑Mon Jan 18, 2021 5:15 pm In my projects I'm using a libopencm3 fork anyway as they didn't want to merge all changes. I could include the generates headers if that really helps.

Oh, heh, we're pointing at your fork. Oops. Still too early here hehe.

Not sure if we should include them or not.

Only bench tests so far. Will test in the E65 tomorrow and report back. Bit more work to do on the E46 before can test there.