Using an Arduino Due as a mini-QC controller

[garygid]

The third step in using the CAN transceiver:

3. Attaching pin 5 and pin 8, if necessary.
For now, with my TI 235 transceiver chip, the pin 5 is "AB" and
can be left open for most normal operation. The pin 8 is "RS",
and is common on many transceiver chips, and needs to be
connected to ground, in my case through a 10k resistor would
be satisfactory.

4. Connection to the Due "primary" CAN port, which has dedicated pins:

CANTX on D69, which should be connected to the transceiver
pin 1 (called "D", used for transmitting message Data) and
CANRX on D68, which should be connected to the transceiver
pin 4 (called "R", used for Receiving the data on the CAN bus).

5. To connect one (properly terminated and biased) transceiver
to another, simply connect each CANH together, and each CAN
together. If more than two "nodes" are connected, they should
be short "taps" on a single twisted pair, and not a "star" type
configuration. The ends of the twisted pair (or sometimes not
twisted) should be properly terminsted. One place on the
CAN bus should be biased.

Hopefully this will be helpful to some, but old-hat to others.
Please, if there are errors, let me know so that I can fix them.

And, if there are better ideas, please feel free to suggest them.

Note: If you were making a Due CAN "node" to talk to the LEAF's
QC bus, you would include termination and bias.

However, I strongly recommend building two nodes, and testing
them considerably, before ever trying to talk to the QC bus,
which might require (probably requires) specific handshake signals
before it would even activate.

I intend to make a node to simulate a car's QC port, and a another
node to simulate a QC device, including the two CAN bus wires,
a ground, and the four Handshake lines (7 lines total).

When these work well, and I have the logging working, then I
could simulate a start-QC sequence, and log and graph the data.

Then, a parallel effort is to obtain a suitably controllable power supply,
probably lower power to start, and make sure that its voltage output
will respond satisfactorily in the simulated start-charging sequence.
Graphing the Output Voltage would verify the logging to CAN-Do.

more later...

Finally, I would care

 

[klapauzius]

I have been using two 120 Ohm reistors as termination on my closed CAN loop, but that makes sense since each transceiver is an end.

I assume that for the QC application, the CAN transceiver would also be an endpoint?

Curious to see what the 3. step is ....

 

[klapauzius]

Finally...got the tft and the shield...took a while from Hong Kong (in fact it took a whole week longer than estimated).
Now I have 2 SD slots (one on the shield and one on the TFT...)
And no free connectors for other stuff!

I guess I can always solder some headers on and use a ribbon cable to connect the shield.

So what is next?

 

[garygid]

What tft and what shield, please?

Normally there would be one or two proto shields
on top of the Due, the display shield on top of those,
and the display on top of that.

I am using the ColdTears Electronics CTE32HR or
CTE35 (or others) and the CTE display shield for Due.

 

[klapauzius]

What tft and what shield, please?

Normally there would be one or two proto shields
on top of the Due, the display shield on top of those,
and the display on top of that.

I am using the ColdTears Electronics CTE32HR or
CTE35 (or others) and the CTE display shield for Due.

I guess its the CTE32 480x320 and the CTE shield. I used your links to order these, so hopefully should be the same as yours.
Depending on what we want to do, I might need a protoshield or two.

Just ran the demo.
Nice...more than twice the resolution of my first computer (C64) and in color!

 

[garygid]

Great to actually see it work, right?

The higher resolution CTE 3.2" display is 480X320,
and is identified as CTE32HR in the UTFT initialization.

I have o! fixed the UTFT_CTE library, I think, to add the CTE35 and CTE40.

I am working through my copy of the CTE demo making small mods
so that one sketch will work with different display resolutions,
in particular the 480X320 and the 800x480 displays.

When I get that working, I will attempt the same with my
version of the Karlsen demo.

Then, back to adding checkboxes, radio buttons, and
progress indicators to the sketch, and adding screens for
testing logging, setting charging parameters, etc.

 

[klapauzius]

Yes, it is the CTE32HR.

 

[garygid]

Finally, I got my touch-screen sketch to work with any of the
CTE32HR, CTE35, CTE40, CTE50, and CTE70 displays, all with
the CTE display Shield for Due, of course.

So far, the sketch now includes the CTE demo, Karlsen's
UTFT demo, and the UTouch Paint demo, and a Number
Entry function, for inputting or changing parameter values.

The Start and Stop Logging function also works, generating
a pseudo-CAN message at each timer interrupt, sending
the log messages to CAN-Do at up to 2000 per second via
the Due's Native USB Port.

 

[klapauzius]

Great.

Yes, I got these running for a while.

At this point I am a bit stuck as I do not have any actual 'hardware'...
I can read and send can messages from the due to itself via the two can-transceivers I have built, I can play with the PWM. I will actually try to use it to play with a toy boost converter (bread-board scale) to see how this works. The timers seem to work well, so overall I think the DUE is quite ready to work as a QC controller. But I dont know what the actual situation on the ground is...so let me know what you need...

 

[garygid]

Assuming that the power supply is going to be isolated,
the Due Controller, and the car will be Grounded to the
protective ground on the AC input. Then, the control
connections between the car and the Due are easy to
implement.

Interaction between the Due and the power supply
will be opto-isolated.

I have yet to finish the CAN circuitry for two ends,
the car simulator (sends MsgIDs hex 100, 101, and 102)
and the mini-QC end, which sends 108, 109, and possibly
some pseudo-messages (like 10A) to log debugging info.

 

[garygid]

Are you doing the CAN receive with an interrupt?

Are you adding Date-Time paeudo-messages (MsgID FFF)
to the logging data from the RTC?

I would be pleased to see some working scripts, please.
PM to get my email address.

Cheers, Gary

 

[klapauzius]

Assuming that the power supply is going to be isolated,
the Due Controller, and the car will be Grounded to the
protective ground on the AC input. Then, the control
connections between the car and the Due are easy to
implement.

This requires a Chademo connector (or something like that with or without the power connectors)? What are you using to communicate with the LEAF at this point?

 

[klapauzius]

Are you doing the CAN receive with an interrupt?

Are you adding Date-Time paeudo-messages (MsgID FFF)
to the logging data from the RTC?

I would be pleased to see some working scripts, please.
PM to get my email address.

Cheers, Gary

Interrupt: yes. See my earlier posts for the code.

RTC: Without any battery powered or "always" on clock , this is somewhat moot, since the clock has to be set up at boot time and currently does not keep the time between turning on and off.

I am using millis and micros at the moment, also since I tested at 1000 messages per second, the RTC second resolution is not useful here.

 

[garygid]

Currently I read micros() to generate milliseconds and seconds
for the 2-byte Time-Stamp that goes on each message to be logged.

I have not delt with the wrap around of micros, or with
generating minutes, hours, or days for the once-a-minute
Date-Time pseudo message.

Providing standby power for the RTC is not a difficult mod
to the Due, however I have not yet read the datasheet
for the uP to see why the two resets are tied together, and
what part of the Due design requires them to be connected.

Even if the RTC is always reset, one can set it if true date-time
is desired for logging experiments.

When the RTC ticks over one minute, I would like to have
an interrupt from the RTC and quickly reset the micros
(or msecs) counter to zero to keep the milliseconds and seconds
in sync with the hours and minutes.

 

[klapauzius]

Now, with touchscreen display, it should be easy to enter the current time at start up for the RTC.
I think a very handy feature would be to have the DUE networked over a regular, wired, IP connection. I have this one
http://www.amazon.com/ENC28J60-Ethernet-Network-Module-STM32/dp/B008B4QIV2/ref=sr_1_16?rps=1&ie=UTF8&qid=1381766489&sr=8-16&keywords=arduino+ethernet" onclick="window.open(this.href);return false;

working in my power monitor in a regular arduino, but the ENC28J60 works at 3.3 V, so should be no problem with the DUE.
Its SPI, so if the Arduino libabrary can be ported to the DUE, this should provide easy and cheap additional connectivity.
If we have an ethernet connecion, we could just poll the NIST time (provided the shutdown ends and not the world... ) or some other time server at startup.

 

[klapauzius]

http://www.epictinker.com/category-s/1862.htm" onclick="window.open(this.href);return false;

Another ethernet solution, using the W5100, which should work with the arduino ethernet library.
This page mentioned that we might get a DUE clone with built in ethernet (as the DUEs processor has native support for it already...)

 

[garygid]

If you get one or both of these working, please post about
your experience, and any hassles that you have. Thanks.

 

[klapauzius]

If you get one or both of these working, please post about
your experience, and any hassles that you have. Thanks.

Ill try the W5100 based first as it should work with the ethernet library.
The ENC28j60 works in the old arduinos, fairly simple, just plug into SPI, install the library, set up a server, done.

 

[garygid]

I added a Checkbox, Radio Buttons, and a Progress Bar to my Sketch.

It appears that the Timer "interrupt" (doing logging) does not work
while a button is being touched. That will need to be "fixed".

Also, I need to add a menu refresh that does not
clear the screen before re-drawing the menu, to refresh
items like the progress bar without a big screen flicker.

If you wish to share Sketches, please PM your email address.

 

[garygid]

I added a detection for re-drawing the last-drawn menu,
and use that flag to not clear the screen when drawing
the main menu. That cuts the redraw flicker down substantially.

Then, I added setting a once-a second byte-flag in the Timer
when the seconds (0 to 59) derived from micros() changed.

Now, I use and reset that flag at the end of the "loop"
to trigger redrawing the current menu.

Works fine for about 30 minutes, and then it starts
redrawing the menu over and over, as fast as it can.

Aso, this rapid redrawing seems to interfere with the Timer,
which is also not good. Maybe communicating
with the display is masking interrupts in some way.

The micros value is a long (32 bits), I think, and getting ms by
dividing by 1000 uses about 10 bits, and dividing again by
1000 to get seconds uses another 10 bits, leaving about
12 bits of seconds, or about 4k, just over an hour (3600
seconds) before it wraps around. or about a half hour before
it hits the sign bit... I can try unsigned long.

However, handling the wrap around is probably best handled
by resetting the micros counter once a minute, when I should
log a Date-Time pseudo message anyway.