Twizy-Cfg: SEVCON-Shell für Arduino

Hi Dexter,
first, thank you very much for your wonderful Twizy-cfg.
I'm trying to make it working with ESP32 and a MCP2515 module (it looks identical to "NiRen" module, same layout, same component, with 8mhz oscillator).
At the moment I receive this error:

If I google-trasnlated the previous pages in the right way, I understood that "NiRen" module won't work without replacing the oscillator with a 16mhz one.
Is it so?
Does this explain the error I receive, or have I to investigate elsewhere?

You're introducing multiple error sources at once, you should sort them out one by one.

The error output doesn't look typical, as it loses the index/subindex of the command. It probably isn't a CAN issue, but rather related to the ESP32 platform.

The software was written for and has only been tested so far on the standard Arduino platforms available at that time, which were 8/16 bit processors. ESP32 is 32 bit, so some data types used need to take that into account. For example, compilers will not pack data structures on ESP32 on byte level by default, but translate any variable to at least 32 bits in memory, as that's the "native" value size on ESP32. CAN data comes in bytes, so to be mapped onto a data structure, that struct needs to be byte packed (tagged with "__attribute__ ((__packed__))"). That probably applies to the sdo_buffer (twizy_sdo) structure.

You'll also need to change the typedefs in "utils.h" to make sure they have the correct size. That applies at least to the UINT and WORD types, which need to be 16 bit, but are 32 bit on ESP32 with the current typedefs (as "int" is 32 bit on ESP32).

In code:

1. Change the UINT & WORD type definitions in "utils.h" from int to short:

2. Add the packed tag to the sdo_buffer definition in "CANopen.h":

Then try again & report.

You probably also need to add the packed tag to the unions & structs in "Tuning.h":

Thanks a lot.
I haven't thought before about structure padding.
I'll follow your suggestions and report back asap.

Delvecchio schrieb: I'll follow your suggestions and report back asap.

Hi Dexter,
I confirm that porting to ESP32 is successfuly completed!
You were absolutly right: the error was due to structure/union padding.
I changed the lines of code you suggested me, and then Twizy-cfg started working on ESP32, without changing the oscillator (I kept 8mhz one).
I had to change the following line in mcp_can_dfs.hotherwise IDE refused to compile source, returning an error.
Also added a patched EEprom library (a porting of ESP8286 EEprom library by Paolo Becchi) which is actualy under test, because I preferred to avoid to use the deprecated one which relay on NVS.

To be more user-friedly, I integrated a serial monitor via web-server. This incresed a lot the size of the sketch, but there is space enough in EPS32.

Thank you so much for Twizy-cfg and for the suggestions you gave me.

Thanks for your feedback, glad I could help. I've updated the repository to include these changes. Looking forward to see your fork going public / receive your PR.

Btw, I had no issues building with the latest mcp_can and iso-tp, no need to #define INT32U. Mabye your mcp_can is outdated?

dexter schrieb: Looking forward to see your fork going public / receive your PR.

I'm not used to github, but I'll try it asap.

Hallo Neuling braucht Hilfe,
Hardware mit Arduino + MCP252515 (16 MHz) erfolgreich zusammengebaut und alles ordentlich installiert. Lesen und schreiben auf den Sevcon funktioniert ohne Probleme.
Ich habe nun 2. Gerät mit einem Arduino Nano V3 + MCP252515 (16 MHz) zusammengebaut , ebenfalls alles wieder ordentlich installiert. Im Seriellen Monitor läuft nach dem Start
die "Hilfe" Version ab, eingaben am Rechner zB rs 1008 0 werden ordentlich mit "Sevcon Offline" Quittiert. Sieht also eigentlich alles gut aus.
Am Fahrzeug allerdings erhalte ich immer " ERROR 0043 SDO 0x1018.02: 0x05040000: SEVCON OFFLINE" Ich habe es mit verschieden Nano`s versucht , immer das selbe.
Strom an Fahrzeug ist eingeschaltet, das Display zeigt an, dass das Fahrzeug bereit ist.
Mit dem ersten Gerät funktioniert es fehlerlos.
Ich hoffe mein Problem einigermaßen gut dargestellt zu haben.
Vielen Dank

Delvecchio schrieb:

dexter schrieb: Looking forward to see your fork going public / receive your PR.

I'm not used to github, but I'll try it asap.

I published my fork . Please be patient with me because it's the first fork for me and I'm not practicing with github.
If there is something to rework, I'll do.

A friend of mine entered all the commands at a time and got this error

Now STOP light is always on the dashboard.
Any idea about to reset it?

Wurde das eingegeben, als sich der Twizy im GO-Modus befand?

Bei allen Profilen, die ich bisher angewendet habe, war der 2. Parameter beim SPEED Kommando größer als der erste.
SPEED 92 100 müsste es meiner Meinung nach korrekt heißen.

Der 2. Parameter gibt an bei welcher Geschwindigkeit die STOP-Leuchte angeht.
Ob das fehlerhafte SPEED Kommando dazu führt, dass die STOP Leuchte dauerhaft aktiv ist, müsste getestet werden.

Dieses Tuningprofil fahre ich:
U1hbt4d+ZRYdAAAAAAAAAAAzR1tvZUo6MCY4UW9lRTAkHxoAAAAAAAAAAAFqAbty

Entweder mal dieses Profil testen, das SPEED Kommando korrigieren, oder auf Werkseinstellung zurücksetzen.

Übrigens, der Base64-Code für die Werkseinstellungen lautet schlicht:
AQ

Viel Erfolg!

Delvecchio schrieb: A friend of mine entered all the commands at a time and got this error

Now STOP light is always on the dashboard.
Any idea about to reset it?

könnte es etwas mit dem preop modus zusammenhängen?
er muss wieder auf den op modus zurückgestellt werden, dann geht stop aus.

@Goldbacher:
Thanks. I'll collect the information from my friend and report back.

@Snorre:
Thanks.
Is this the right command to enter (via webserial monitor) the suggested profile:
set 1 U1hbt4d+ZRYdAAAAAAAAAAAzR1tvZUo6MCY4UW9lRTAkHxoAAAAAAAAAAAFqAbty

And to reset to factory profile, this one?
set 1 AQ

I'm not sure about the first argument (profile number) in both.

@circuit paradase
Thanks. I'll report back if stop goes off after sending "o" command.

Also ich bin der "Idiot" der das verbockt hat

"Zündung" war an, nicht auf "Go"! Muss sie auf "Go" stehen?

Soll ich den Befehl AQ senden um auf Werkseinstellungen zurückzusetzen,
oder soll ich einfach mit den korrigierten Werten weitermachen?

Und noch eine Frage. Muss nach dem senden der Befehle noch ein "Log Out" durchgeführt werden?

Ich danke Euch für die Hilfe.