Serial Communication Take 2

Official FreeEMS vanilla firmware development, the heart and soul of the system!
Post Reply
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Serial Communication Take 2

Post by Fred »

Hi,

The old serial thread is here : http://www.diyefi.org/forum/viewtopic.php?f=8&t=89

That thread was fairly narrowly targeted in terms of a 1:1 connection that I had envisaged. We need to discuss what it will take to get comms that work on a network style environment. I'm pretty keen to have one set of code to handle serial and CAN comms right off the bat, but I'm not 100% sure what is required to do it.

I made some notes on the train on the way home that I'll paste below :

How multiple physical protocols will affect serial comms
  • Headers will change depending on the design.
  • Serial escape scheme will be the same
  • Serial start/stop will be the same
  • Checksum will be the same (no harm in superfluous checksum on CAN even if it does it in hardware too)
  • Interrupt handling will be the same or very similar
  • Logging and receive interlacing will be the same or very similar
At the end of the day I can implement a lot of the serial side of it without worrying about the header and packet data too much. This is good as it gives me something to do and keeps things moving forward.

Model of possible interactions required

Properties :
  • CAN messages can be addressed when sent on a physical level.
  • Serial messages are 1:1, but it IS possible to parallel devices on the line (though not recommended)
  • Does CAN have data integrity built in? IE, does it need a checksum as the serial comms does?
Required transfers :
  • ECU > ALL (data log packets, error packets)
  • ECU > specific (response to requests)
  • PC/HH > ALL
  • PC/HH > specific
Tools to achieve this :
  • Each node COULD have an address
  • Each message COULD have an ID/sequence number
Maximal configuration could be something like :
2 * ECU
X * AUXIO units
X * Datalogger
1 * Laptop
X * Display/Dash unit
1 * Handheld device

Where X is defined as 0 – Many.


8 bits is plenty for addresses.
8 will work for sequencing if done right.

A broadcast address is required, and preferably some distinction between from ECU and from PC/HH too such that messages with broadcast from ECU are ONLY received by PC/HH devices, and NOT other ECU devices.



Basically I'm looking for ideas on how the addressing and logic and semantics for one message on a bus with 10 devices listening can work.

Any/All ideas welcome.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
jbelanger
LQFP144 - On Top Of The Game
Posts: 387
Joined: Sat Feb 23, 2008 8:58 pm
Contact:

Re: Serial Communication Take 2

Post by jbelanger »

You will have (potentially significant) differences between the serial and CAN interrupt handling because, if I understand correctly the intent, you will need the ECU to behave as a gateway between the CAN bus and the serial link. This means (some of) the messages received on the CAN bus get transferred to the serial link and vice versa.

However, this doesn't preclude the messages having the same format but that might not be the most efficient since the data transfer rates are quite different. You already have a 1K buffer planned but if you have many devices communicating with the PC through one ECU that may be filled quite fast depending on what's being transferred.

Jean
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Serial Communication Take 2

Post by Fred »

Ahhh, see, I'd forgotten about doing that all together. I was thinking of tuning the thing through CAN directly. Pass through definitely needs to be considered as well.

The buffer is JUST big enough to take the largest single message required, IE a full block of flash. In order to keep it simple the idea is to receive a message, then turn off reception until the message has been handled. Each message should be processed in whole such that nothing gets stored that hasn't passed all it's health checks first.

I had no plans to buffer multiple messages in there.

KISS :-)

Trust you to throw the cat amongst the pigeons!

Cheers,

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
shameem
LQFP112 - Up with the play
Posts: 135
Joined: Thu May 01, 2008 6:30 pm
Location: Ann Arbor, MI
Contact:

Re: Serial Communication Take 2

Post by shameem »

Instead of grappling with RS232/CAN issues - why not keep everything CAN and use a rs232/usb adapter for pc comms - like this - http://www.canusb.com/

It might even be made compatible with the existing obd2 can scanners ....
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: Serial Communication Take 2

Post by jharvey »

It uses an FTDI chip, ug. I like the EZUSB from cypress also known as the FX2.

The FTDI is sole purpose, and not flexible. EZUSB is an 8051 with additions. It establishes the very min and basic comms with USB, then the PC uploads the firmware, telling the device what it's going to be.

Here's a link to about it.

http://www.hhhh.org/wiml/proj/keyspan.html

Yes it's just a 232 device, but if you want it to be CAN simply upload a different firmware.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Serial Communication Take 2

Post by Fred »

Tonights train ride was unproductive as I was standing up the whole way. I opened eclipse and tried to code with it on my knees crouching, but no luck. I refuse to sit on the floor of public transport so I just had to listen to pink floyd instead.

I've been thinking about this.

The way I've painted the picture is a seriously complex problem to solve. What is needed is a solid set of use cases, and some narrowing of scope.

It is also important that we get something happening sooner rather than later. I would like to standardise early, but reality might be that we could make changes later without too much pain for other devs. I doubt there will be a flood of people trying to interface with it so early on anyway.

So, I'll have a think about what we might want to do and perhaps add a poll to this thread with some options to gather a feel for what people want from the comms aspect.

At the moment my thoughts are :

Ignore CAN for now.

1:1 serial design with the following conditions :

Only ONE device to be sending requests/commands to the EMS box at any given time.
Any number of devices listening in to the serial lines and using the data as they can.

One of the actions could be "fwd over CAN to broadcast address" or something? The only restriction there would be the max message size would be smaller unless I increase the buffer to uneven sizes (the only thing stopping me doing that is the knowledge that it wouldn't be a multiple of 2, ie, no good reason...)

Most of what I'm doing will be required for serial comms regardless, just the header structure and possibly semantics of what to do given header values will vary.

Thoughts?

While I create the initial implementation and hash out the first working revision of the serial spec we can discuss the future of FreeEMS comms in this thread.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
davebmw
LQFP144 - On Top Of The Game
Posts: 331
Joined: Sun Jul 13, 2008 2:58 pm
Location: South Wales, UK

Re: Serial Communication Take 2

Post by davebmw »

As far as I'm concerned CAN is useless to me as i found out yesterday may car uses ISO 9141-2 comms to communicate with the body electronics not CAN which came in from 1996 and only on the OBD2 interface.
Serial comms for tuning interface, programming, datalogging and realtime display are of prime importance to get to where the competition is and more. I think that should be the focus for now.
Fancy stuff like talking to Audi's seat controllers and airbags systems can wait. ;)
Leave it to ze Germans to want to talk to our arse's eh?
I can't see any harm in leaving the CAN chip on the hardware as it really is minimal impact stuff.
93'BMW 325is M50B25TU, Rebuilt 06/06, JE10.5:1, polish&port. Scorpion BB, K&N CAI, TEJ21 WBO2, '07 M3 Evo 18" 225F, 255R, EBC Kevlar, Bilstien Sprint, Polyflex. Head rebuild Oct'08, OEM+FSE FPR, MS2v3.0_DJB Custom, Extra 2.0.1
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Serial Communication Take 2

Post by Fred »

I agree. The point of CAN from our eyes though is expandability. Much like MS2 will one day get GPIO, we could/should have that capability in some similar form too.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
davebmw
LQFP144 - On Top Of The Game
Posts: 331
Joined: Sun Jul 13, 2008 2:58 pm
Location: South Wales, UK

Re: Serial Communication Take 2

Post by davebmw »

By the time MS 2 gets GPIO I'll have P.E.N.S.I.O.N and G.O.U.T and driving a spazo buggy so extra I/O on my EMS will be the last thing i'm interested in.
Now CAN BUS control of my pacemaker that could be cool!! :lol2:
93'BMW 325is M50B25TU, Rebuilt 06/06, JE10.5:1, polish&port. Scorpion BB, K&N CAI, TEJ21 WBO2, '07 M3 Evo 18" 225F, 255R, EBC Kevlar, Bilstien Sprint, Polyflex. Head rebuild Oct'08, OEM+FSE FPR, MS2v3.0_DJB Custom, Extra 2.0.1
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: Serial Communication Take 2

Post by jharvey »

So when you say CAN you mean cup holder right?

I sure you've noticed I tend to think about shed color last, some time even two late. I'd say make a guess and see what happens. I can see some form of comm as useful to upload and down load maps. I also could see it handy for uploading and downloading firmware. Other than that using it for talking to your arse, or dash displays can be taken care of on future add-on cards yes?
Post Reply