Speeduino is now on Github Sponsors (Rather than Patreon): https://github.com/sponsors/noisymime
Any general discussion around the firmware, what is does, how it does it etc.
Zeiberstein wrote:
Tue Apr 27, 2021 12:26 pm
I got a bit further. I think my problem has to do with PROGMEM variables.

First read this https://www.arduino.cc/reference/en/lan ... s/progmem/ On this page it is shown how to retrieve values from PROGMEM:

As said before, the array fsIntIndex contains all the indexes in currentStatus that should be considered as a double byte value. Indexes not present in this array are considered single byte values. For comparison in a rule for a programmable output, the corresponding value in fsIntIndex has to be known in order to determine whether a status parameter is Single cq. Double byte.
In the Speeduino code for the programmable outputs, the PROGMEM array fsIntIndex is treated as an ordinary array. I doubt whether that is correct.
To check this, I altered the procedure command() in module comms to output the values in fsIntIndex when ‘X’ is typed in the serial monitor. I retrieve the values in fsIntIndex in two different ways:

This is what I got the first time after pressing ‘X’ in the serial monitor:


The first line differs from how fsIntIndex is defined in module globals and the second is exactly right:
const byte PROGMEM fsIntIndex[31] = {4, 14, 25, 27, 32, 41, 43, 45, 47, 49, 51, 53, 55, 57, 59, 61, 63, 65, 67, 69, 71, 75, 77, 79, 81, 85, 87, 89, 96, 101};

As I changed the a compiler directive from –O3 to –Os, I got:

I tried two GCC compilers: 4.92 (Arduino IDE 1.6.13) and 7.3.0 (latest Platformio, Arduino IDE 1.8.13). I tried –O3 and –Os as compiler directives.
Depending on the compiler version, the compiler options and any further alteration that were made in the source code, the reported values for ‘fsIntIndex’ differ per build but are never correct.
The values for ‘pgm_read_byte(&(fsIntIndex))’ are always correct.

In one of my experiments, I got this result for ‘fsIntIndex’:
160 14 168 14 176 14 184 14 192 14 200 14 208 14 216 14 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
And this is very interesting! Although the values are incorrect, coincidentally the value 14 occurs in it. And 14 is the index for RPM comparisons in the Programmable output rule…..!! So: if I test the programmable output for RPM in this build, it works flawlessly….

Is there anyone out there willing to test if this issue is broader than only my installation?
If so, please compile/build with the attached comms module and give a ‘X’ as command on the serial port.
The programmable outputs seemed to work for me, but on closer inspection it wasn't true. But with that fix those work as they should when driving the car.
pazi88 wrote:
Fri Apr 30, 2021 7:00 pm
The programmable outputs seemed to work for me, but on closer inspection it wasn't true. But with that fix those work as they should when driving the car.
Thank you! :)

About the issue in this thread I wasn't sure enough to file a bug report on github. But I read in the disscussions on Slack between the core developers, that they've seen this thread and will address it . :)
M73 V12 Project (BMW 750IL)

Why not 2 Speeduino's sharing trigger sensor? […]

Teensy based mainboard

I would suggest reducing your sensor count, circ[…]

there is some really interesting projects going on[…]

Hi Guy's, I have designed a Teensy 3.5 Board whic[…]

Still can't find what you're looking for?