Comms to 14cux ecu

[FFMan]

Am thinking of doing a zx based project to talk to an aging 14cux auto ecu.

the hardware details are listed as:-

•invert its RxD line (with respect to normal RS232 signal polarity),
•be able to set a baud rate close to 7812.5 bps, and
•be able to receive a 12VDC signal without being damaged.

more details here http://alum.wpi.edu/~colinb/14cux_interface.html

I see s/w uarts can invert in software so I assume this is my simplest option, and at that baud rate its not going to tax the cpu too much is it ?

Other option is hardware uart with external transistor to invert.

Both options need to be wary of 12v signal, which I think the zx24 can accept, but then that is a h/w channel so no option to invert ?

Whats the best option here, given also I may need another com port or 2 to forward data and for programming. ?

[dkinzer]

-invert its RxD line (with respect to normal RS232 signal polarity),

This statement is ambiguous, at best. From what I can see the signal idles near ground and transitions to something close to 12V. This is close to a "normal RS-232 signal" which idles at a negative voltage (-3V to -15V) and transitions to a positive voltage (+3V to +15V).

I believe that you could use an RS-232 level shifter to convert this to a TTL/CMOS level signal with the correct polarity for the hardware UART. You could also use one of the alternate serial receive circuits shown in the Appendices of the ZBasic Language Reference manual to convert the signal to TTL/CMOS.

-be able to set a baud rate close to 7812.5 bps,

The software UART channels are limited to "standard" baud rates between 300 and 19200: 300, 600, 1200, 2400, 4800, 9600, 19200. For the hardware UART and operating at 14.7MHz, you can get 7810.2 baud using a UBRR value of 117. This is about 0.03% low - probably close enough.

Both options need to be wary of 12v signal, which I think the zx24 can accept, but then that is a h/w channel so no option to invert ?

All of the ZX devices are limited to signals that do not exceed the operating voltage and do not go below ground. If you have signals higher/lower than that you must add external circuitry to limit the excursion to the ground-Vcc range.

A simple transistor circuit can be employed to convert the logic sense and limit the voltage. The circuit would be nearly identical to that shown in the 14CUX document except that the collector resistor would be connected to the ZX's Vcc. The diode and series resistor connected to the collector probably wouldn't be needed.

[FFMan]

thanks don

I note that the usb cable I bought to hook the ecu to my pc looks like a standard rs232 to use affair with the ecu plug on the end. I don't see any custom components, and I expect their driver load sets the ftdi chipset to invert as documented.

I could use that lead and prototype the s/w in VB to prove it works, then transition it to zx.

so s/w uart a no go at that baud and if I want to retain a debug/load port and potentially a serial lcd and a Bluetooth pass through I am thinking a zx24x or my spare 128a1 on the carrier board you loaded for me.

I think I need to get a spare ecu to play with on the bench. i'll progress and see how it goes.

[mikep]

Have you seen this google project for the ECU? Probably provides a very good start for what you need. You could use the C code from the library in a ZBasic native mode application.

[FFMan]

thanks mike - I had found that and some excellent related info

http://www.conehead.org/Projects/LandRo ... %20MK3.pdf

I could use the library, but actually its all pretty simple and I have a feeling I take as long interfacing to someone elses library as I may coding it myself but we'll see.

I have been offered a retired ecu to get it running on the bench.

[FFMan]

> you can get 7810.2 baud using a UBRR value of 117.

can I just specify this on the opencom statement or does this require some manipulation of a register directly to achieve ?

thanks

[dkinzer]

can I just specify [the baud rate] on the opencom statement?

Yes. For unusual baud rates the compiler arranges things so that the UBRR value is calculated at run time. The code below shows that the computed UBRR value is 117.

Code: Select all

Dim iq(1 to 20) as Byte
Dim oq(1 to 20) as Byte

Sub Main()
   Call OpenQueue(iq)
   Call OpenQueue(oq)
   Call OpenCom(2, 7812, iq, oq)
   Debug.Print "UBRR1="; CStr(Register.UBRR1)
End Sub

[FFMan]

thanks for the help Don, baud rate setting worked first time. I used a nand gate to invert and tame the 12v comms to 5v.

So now I have the basics working, am thinking about the end result, and I feel my zx will provide an interface between the non-standard baud rate and a Bluetooth link to either an Android app, or a handheld display running another zx.

So I will need to write some code to provide a conduit between two serial ports, but it would be useful if the zx could sample the data also in case there are fault codes present. The code needs to pass data in both directions, in theory never simultaneously as its an enquiry then response type conversation.

The enquiry characters are 3 in number, the response 80 or so. the Bluetooth could run at 115200 but in reality it won't achieve that over the link so it could be slower. The enquiry rate should run twice a second I would think.

any advice on how to code the serial port conduit, is 2 tasks the right think here, 1 task for each direction ?

I have to use a h/w uart on the non-standard ecu side, would I be advised to use a h/w uart on the Bluetooth side or given that there is little other processing, would another s/w uart be ok ?

thanks