[dazq]

Which version should be used? I try to compile v02.3 and get some errors.

'SPI_CS1_PIN' was not declared in this scope
'Serial1' was not declared in this scope

May be my arduino version is to old 1.6.13?

Also Speeduino-Simple-SD-Logger-master at git hub only readme file?

I thought the SD card files were there? I will look into that, thanks for mentioning it

With the can interface what MCU are you compiling for ? It should compile for nega2560 and teensy 3.2??
Just quickly looked at the files , it really does need an update !!
I need to get a GearControl release out then I will look at getting an update for this uploaded. In the mean while keep me informed of your progress

[Rocket]

I tried to compile for nano Because in comments I found // These are the pins used for the UNO
If i try to compile for me2560 I get 'rxmsg' was not declared in this scope.

[dazq]

Yes the code definitely won't run on an uno or nano! I will need to have a look at what's on git as I say it does need updating , things have progressed a bit now?
What have you planned to use this with may I ask?

[Rocket]

No rush on that I just waiting some parts for dyno build so I decided to look at control side for dyno. I'm thinking to use speeduino for measuring and data loging and I think can interface will be good solution to link speeduino with brake load controller because wires will be at least few meters and environment for signals will be noisy. May be minigpio will be even better for that? Could be used as stand alone dyno controller and data logger. If I put additional code almost same as pid idle or boost control for brake it should work pretty good.

[dazq]

For logging and control possibly yes gpio would be better bases.
The next release has pwm outputs (open loop only) and Vss sensor inputs, and a few other bits ...... Closed loop would be great addition

[Rocket]

Let's continuing about that in dyno topic.

[dazq]

A lot has happened to the speeduino project in the 5 years since I started the can interface originally.
Here is my GitHub work from where it got to at the time
https://github.com/Autohome2/dxControl-CanBridge

In recent months there has been more and more interest in a serial3 to canbus interface and the possibilities it offers.
So I am thinking of starting rework on the project with some better hardware and take further advantage of the new speeduino firmware .

For the MCU I am thinking to use a teensy 4.0 , this offers two to three can ports and the usb to setup/configure via TS. Other MCU may be an option but must have at least two can interface natively.

Also I would like to revisit the concept of connecting TS via the canbus itself . This would involve a dongle of some kind on the pc running TS,but a protocol of some kind needs to be formulated to packetise the data onto the canbus. This is something for later anyway once the basics of the interface is up to where the onboard can of the teensy3.5 and stm32 based speeduino are at.

Any thoughts and support always welcome.

[JHolland]

Isn't the newer TS/MS protocol designed for CANBus? I haven't looked into this yet but I thought I saw that the Speeduino code had been updated so that it was using that protocol but over the serial port.
CANBus to USB interfaces can be bought quite cheaply from Aliexpress but I don't really see the point of going serial->CAN-> serial->VCP, unless you just want to be able to say that you have CAN.

[dazq]

Isn't the newer TS/MS protocol designed for CANBus? I haven't looked into this yet but I thought I saw that the Speeduino code had been updated so that it was using that protocol but over the serial port.
CANBus to USB interfaces can be bought quite cheaply from Aliexpress but I don't really see the point of going serial->CAN-> serial->VCP, unless you just want to be able to say that you have CAN.

Re the protocol, no we don't use the ms protocol but we are now using some of the other TS commands it has available.
Yes usb to can interfaces can be found cheaply, but would need a software driver on the device running TS ( pc ,Mac , whatever) to packetise the data from the stream TS generates and reads in into what the canbus structure can support. Even with iso tp some data streams from TS far exceed the can packet length available.
As to why , well being able to connect TS via can into the vehicle especially if the ECU/s you want to access are already on a can bus in that vehicle saves the need for a accessable usb port on those ECUs to enable configuration. OEM ECU are invariably accessable (with the right software tools) over the canbus , often via the obd port, so this is similar.
If your speeduino MCU has native can then fine but this interface is meant to give those wanting to use a mega ( and many still do) at least some of the canbus ability those more powerful MCU offer .

[JHolland]

Re the protocol, no we don't use the ms protocol but we are now using some of the other TS commands it has available.

What protocol are you using?