Anything not specifically related to the Speeduino hardware. Eg sensors, bluetooth, displays etc
#41844
Hope everyone is keeping safe during these crazy times. A bit of a home social distance project: I finally had a chance to experiment with Serial 3.

I would say my findings still don't quite line up with the Wiki documentation (or at least my initial interpretation of it) and I'm still trying to get my head around the code and harmonize it with my findings. But anyway, maybe the following is interesting/helpful for people:

Test setup:
Labview + USB serial dongle emulating a GPIO module <> MX5 PNP Speeduino with generic MAX232 chip added to serial 3.


In tuner studio enable serial 3. Add at least one external input.

Build your GPIO device and communicate with the following protocol:
Protocol.png
Protocol.png (32.54 KiB) Viewed 6266 times

Example tuner studio setup with some combinations:
TS Config.png
TS Config.png (130.3 KiB) Viewed 6273 times
The serial handshaking zoomed out:
LA_Both.png
LA_Both.png (204.54 KiB) Viewed 6273 times
What speeduino requested:
LA_Speeduino_Request.png
LA_Speeduino_Request.png (219.74 KiB) Viewed 6273 times
What the GPIO module returned:
LA_GPIO_Response.png
LA_GPIO_Response.png (232.65 KiB) Viewed 6273 times
Last edited by ESDave on Sun Apr 05, 2020 1:58 am, edited 5 times in total.
#41845
... ran out of attachment uploads ...

The final result:
Result.png
Result.png (89.21 KiB) Viewed 6272 times
And labview code for reference:
Labview Code.png
Labview Code.png (41.47 KiB) Viewed 6272 times
(apologies to any professional labview programmers - its probably pretty hacky)


Abit of a whinge: If my interpretation is correct, for each external input i need to send 8 bytes. But only the first two can be used. So the protocol wastes 6 bytes x the number of additional inputs i add?
#41846
Any one or two of the 8 bytes can be used. But indeed 6 ot 7 bytes gets wasted. I think it's done to have direct compatibility with CAN bus. So that same code can be used in both CAN and serial connection. Only interface changes between those.

And yes there is no CAN-bus in speeduino. Yet ;)

Here is my Serial3 expansion project: https://github.com/pazi88/8Ch-EGT
#41848
So first I must say that using the scope to monitor the serial traffic is somewhat overkill :-) just use a simple terminal program to watch the bytes being sent.
I have examples of how to use secondary serial on my GitHub.
Also take a look at my gpio expansion project here
https://speeduino.com/wiki/index.php/DxControl-GPIO
As pasi said the reason for 8 bytes is to simplify support for can, later.
External Input via can is next to be done once I get this last OBD2 pr submitted if that is of interest?
#41853
Thanks for the links to the reference projects, I'm definitely still at the start of the learning curve. I looked through DxControl, but what i was trying to find to start a project was a simple documentation of the handshake between Speeduino and some other module via Serial 3.

What I found today (and it makes sense now looking at the Speeduino code) is that you can actually turn all this off:
Ext Off.png
Ext Off.png (69.89 KiB) Viewed 6230 times
And just slam it with data as fast as you want, and it still populates the list.

Is there a good metric to check to make sure the serial interrupts are not starting to consume resources to the point that it compromises engine control? I checked main loop time and it didn't go down much. Maybe there is some interrupt management going on in the software.
Data Rates.png
Data Rates.png (101.17 KiB) Viewed 6230 times
by dazq » Sun Apr 05, 2020 5:31 am
So first I must say that using the scope to monitor the serial traffic is somewhat overkill :-) just use a simple terminal program to watch the bytes being sent.
Haha actually I couldn't find a serial terminal that publishes the data as decimal, all the programs i had try to print everything as ASCII. But it's also fun to dig into the detail - like why there is 4ms delay between RX and TX - some propagation delay in the labview code maybe, and I had attempted to put a 1ms delay between the TX frames to give the Speeduino buffers a break - but it looks like the delay didn't work, but UART on Speeduino wasn't bothered anyway.
Last edited by ESDave on Sun Apr 05, 2020 2:47 am, edited 1 time in total.
#41854
With CAN - i think like a few people on here, i mucked around with it on the Megasquirt about 10 years ago using a AT90CAN128, i still have the crappy prototype board i made in the junk box:
20200405_123058.jpg
20200405_123058.jpg (179.28 KiB) Viewed 6230 times
https://www.youtube.com/watch?v=ddWHp4uoX50

https://www.youtube.com/watch?v=o4_ar1wnvJ8

What annoyed me about CAN on Megasquirt was that it was implemented as a "diagnostics" request/ respond mode rather than an "application" type broadcast... but looking at your signature looks like you have that covered! :)

For CAN support on Speeduino is the plan to support Teensy only? Or use an SPI bridge chip?
#41857
ESDave wrote: Sun Apr 05, 2020 2:25 am Thanks for the links to the reference projects, I'm definitely still at the start of the learning curve. I looked through DxControl, but what i was trying to find to start a project was a simple documentation of the handshake between Speeduino and some other module via Serial 3.

What I found today (and it makes sense now looking at the Speeduino code) is that you can actually turn all this off:

And just slam it with data as fast as you want, and it still populates the list.

Is there a good metric to check to make sure the serial interrupts are not starting to consume resources to the point that it compromises engine control? I checked main loop time and it didn't go down much. Maybe there is some interrupt management going on in the software.

Haha actually I couldn't find a serial terminal that publishes the data as decimal, all the programs i had try to print everything as ASCII. But it's also fun to dig into the detail - like why there is 4ms delay between RX and TX - some propagation delay in the labview code maybe, and I had attempted to put a 1ms delay between the TX frames to give the Speeduino buffers a break - but it looks like the delay didn't work, but UART on Speeduino wasn't bothered anyway.
Ironically, despite the Speeduino code forcing you to use 8 bytes for "Canbus compatibility", you don't actually have to use all 8 bytes in a real canbus message. The transmission protocol has length information in it (referred to as the DLC bits).

You may not have noticed but the serial port in the Speeduino code is polled, not interrupt driven. So it limits the amount of messages it will process (something like every 32 main loops IIRC). As a result, this drives the effective transmission limit on the port. There comes a point where sending too many requests results in some of them being dropped by the hardware (the short hardware serial buffer overflows). It will go a bit faster if the buffer is more than half full in order to try and catch up on a transient situation. You don't really want it doing that all the time because ultimately your requests will get dropped on the floor once the serial buffers are filled (64 bytes), but even then it still has negligible effect on the main loop speed.

The rule I use for serial3 is to just completely serialize it; i.e. don't make a request for anything until the last one has been completed. This keeps the internal queues basically empty and still gives you a decent response rate. It also makes the software easier to write and maintain.

Coolterm can do hex dumps of serial data IIRC. Available on various OS' including Linux and Windows.
#41862
Ric355 makes a good rule to follow , don't ask for more data until the last has completed.
Yes the serial is not interrupt driven and will check it after the 32 loops , but it will also check the buffer when it reaches are set amount too.
The serial buffer handling is exactly the same as the main serial to ts so it is quite capable.
The auxillary input and the data request via serial3 are separate creatures.
At the moment the can is only on teensy, but a serial to can interface does exist to give can yo the mega , although still under development.( Search on here for 2can ,toucan by jama.)
Regards simple examples, there are some on my GitHub in the gpio folder iirc
#41919
hey dazq,
Its my first try to use the gpio, since I am in need of controlling the AC and alternator charging modes. I've read the wiki and it is using serial 3. I am currently using serial 3 for bluetooth, can i use other serials? or do i have to move the bluetooth to other serials?
#41929
choyr wrote: Tue Apr 07, 2020 5:10 pm hey dazq,
Its my first try to use the gpio, since I am in need of controlling the AC and alternator charging modes. I've read the wiki and it is using serial 3. I am currently using serial 3 for bluetooth, can i use other serials? or do i have to move the bluetooth to other serials?
To connect gpio to speedy yes you must use serial3 . I assume you use the Bluetooth as a dash? You could use serial 0/ usb for this, but then ts won't be able to connect.
I hope this will change once passthrough is complete .
Otherwise you could use the canbus that gpio had available?

Hi, I am trying to assign Signed values to the x-a[…]

Vr Conditioner Noise when cranking

New version 202305 don't fix the issue. Now after[…]

blitzbox

I've finally figured out why MAP and Lambda weren'[…]

Hello, I bring news!! Let me tell you that after […]

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