Implement more CAN protocols#33
Conversation
|
Doesn't build at the moment, because its dependent on more recent rusefi changes. |
| uint8_t NoLongerUsed0 : 6 = 0; | ||
| uint8_t CanMode : 2; |
There was a problem hiding this comment.
TunerStudio tune file stores the values referenced by name.
So if firmware and ini file are updated, fw will load default values, and TS will restore everything by name, allowing us to repurpose the first byte.
As a side note, to allow seamless upgrades, we could remap CanIndexOffset from old ini file to new RusEfiIdOffset0 address, allowing TS to restore old values to new location.
There was a problem hiding this comment.
I think less than 1% of users ever update FW. This 1% is qualified enough to do manual settings migration :)
| uint8_t pad[5]; | ||
| uint8_t ExtraCanIdOffset; | ||
| uint8_t Reserved[5]; | ||
| } egt[2]; |
There was a problem hiding this comment.
As far as my research goes, every commercial thermocouple-to-can device sends 4 values per can bus message, so it does not really make sense to have separate settings per channel.
There was a problem hiding this comment.
Yep.
But in RusEFI we have implemented AEM 30-0305 - like protocol. Which is single channel. And we supporting up to 6 CAN EGT on 0x000A0305 + N addresses.
There was a problem hiding this comment.
Understood.
Added 0305 back in, added support in TS ini to set separate offsets for this particular protocol
xtitoris
force-pushed
the
more-can-protocols-merge
branch
from
748c4b9 to
b6fea28
Compare
xtitoris
force-pushed
the
more-can-protocols-merge
branch
from
b6fea28 to
c9d135f
Compare
xtitoris
force-pushed
the
more-can-protocols-merge
branch
from
f5d5202 to
cea7a59
Compare
…et protocol back in
xtitoris
force-pushed
the
more-can-protocols-merge
branch
from
c6ef6fe to
4676508
Compare
2 participants
Implemented more CAN protocols both for AFR and EGT to make the module useable with other kinds of ECUs.
Would appreciate any thoughts on this. Tried to make it as backwards-compatible as possible.
There's an issue with AEM EGT protocol - the selected ID and message is tied to AEM EGT Gauge 1800F (30-0305) with address of 0x000A0305, which is single channel, and does not support additional messages.
In fact, 0x000A0306 is an AEM Boost Gauge 50psia (30-0306)
Better thing to implement would be 30-2224 8 channel k-type module
https://documents.aemelectronics.com/techlibrary_30-2224-_8-channel-k-type-can-module-instructions.pdf
But currently this breaks backward compatibility.
Tried to make TS UI as user-friendly as possible, while respecting the data memory layouts.
Branch with latest rusefi changes:
https://github.com/xtitoris/wideband/tree/more-can-protocols