Using an Arduino Due as a mini-QC controller

[garygid]

I think Microsoft said that Win8 would no longer
support Visual Basic programs.

Perhaps that is what you are running into?

CAN-Do appears to work on XP, Vista, and Win7,
but I do not have a Win8 system to try it on.

Welcome to planned obsolescence.

Please let me/us know if you find a way to make it work.
Is there any kind of "compatibility" mode on Win8?

 

[klapauzius]

Tried Windows 7 compatibility mode...It still complains about COMDLG32.OCX missing, despite the fact that I copied it to system32....
I have a win7 computer somewhere, so will try it there.

RTC:which library are you using? I am using this one: https://github.com/MarkusLange/Arduino-Due-RTC-Library" onclick="window.open(this.href);return false;

update: CAN-DO works on the Win7 machine.

 

[garygid]

Sometimes files go into system instead of system32,
or try putting it into the same folder as the application.

Maybe the OCX file needs to be registered?

I have not used the RTC yet, have you tried it with the Due?
However, thanks for the link.
Cheers, Gary

 

[klapauzius]

Sometimes files go into system instead of system32,
or try putting it into the same folder as the application.

Maybe the OCX file needs to be registered?

I have not used the RTC yet, have you tried it with the Due?
However, thanks for the link.
Cheers, Gary

Yes , the library works.

 

[klapauzius]

OK, buffering and writing to SerialUSB of the CAN messages works at a 100 ms pace...I even got CAN-DO to run on the Win8 machine. With the OCX files in the same folder as the executable, this works.
Can CAN-DO read a data stream from the serial port? I am currently writing the buffer out to the port whenever it is full. I shrunk it to 16 messages, so right now it writes every 1.6 s out to the port.

 

[garygid]

What files did you need to include in the application folder
on Win8, and where did you get them?
I want to post the Win8 information on my CAN-Do page
(use the link in my signature).

I sent with SerialUSB.write(...) 2000 messages per second
to CAN-Do, and the input page does input from a Virtual
Comm Port. I used a 100-message buffer, and send
each message in 14-byte "all-can" format.

SB MM NM D1 D2 D3 D4 D5 D6 D7 D8 SS mm TP

as I recall.
I will try to post my LogRate sketch, and a few others tomorrow.
(also use the link in my signature to find them)

 

[klapauzius]

I have these files in one folder:

CAN-Do-v219.exe
COMDLG32.OCX
MSCOMM32.OCX
VarParmList.csv

There is also a CAN-DO.ini file, but that is generated.

The OCX files are from the Distribute_003.zip from your web page.


Yes, faster communications work as well, the USB port removes a lot of limits that the serial communication had.
I got CAN-DO to read my generated messages, although I am not sure It got all the messages. I generated a 1000 messages each seconds, put into a 512 sized message buffer, which gets written to serialUSB once it is full. CAN-DO ran for several seconds and indicated it read 3741 messages without error, but I think a lot of the messages got lost, because it ran a lot longer than 3.741 s.

Anyway, it seems you have the message sending implemented as well, so no worries there.

I guess if want to get serious about code development at some point a version control system would be helpful.

I still cant make sense of what CAN-DO read from my generated messages...here is the code that formats the CAN message into the 14 byte format:

void add_message2buffer(RX_CAN_FRAME incoming,byte CAN_BUS)
{  
  // create a 14 byte temporary buffer from the CAN message
  byte buff[MSG_LENGTH];
  buff[1]=highByte(word(incoming.id)) | 16*byte(incoming.dlc); // upper byte of msg ID and number of bytes
  buff[2]=lowByte(word(incoming.id)); // lower byte of msg ID
  for(int i=0;i<8;i++) // use memcpy in
  {
    if(i<incoming.dlc)
      buff[i+3]=incoming.data[i];
    else
      buff[i+3]=0xFF; // fill with FF
  }
  word ti=word(rtc_clock.get_minutes())*256+word(rtc_clock.get_seconds()); //put time in 16 bit word

  buff[11]=lowByte(ti);//store seconds
  buff[12]=highByte(ti);//store minutes
  buff[13]=CAN_BUS; // Bus ID
  
  buff[0]=buff[1]; // check byte...use parity
  for(int i=2;i<MSG_LENGTH;i++)
    buff[0]=buff[0] ^ buff[i]; // parity checksum

  memcpy((byte*)msg_buffer[buffer_index],buff,MSG_LENGTH);
  buffer_index++;
  
}

The time stamp currently is generated from minutes and second, as the RTC does not seem to support milliseconds...we could use millis instead, but that is 4 bytes....

 

[garygid]

The sync byte is not a checksum byte.
And a few other minor data format or content issues.
But, getting close.

See the first post of this thread:
http://www.mynissanleaf.com/viewtopic.php?f=44&t=6088" onclick="window.open(this.href);return false;

Cheers, Gary

 

[klapauzius]

I see.... I had a few things backwards...just noted that the way the time stamp is written in my function is kind of redundant.
I ll try to implement per description in your other post and see what I get.
Any particular reason not to use parity for checksum?

ps:

Seems to work now....The time format is still different, will change that, but CAN-DO reads my DUES messages now.
Here is a text output from CAN-DO:

T,SS.MMM,N,MID,D1,D2,D3,D4,D5,D6,D7,D8
E,03.512,8,007,00,32,FF,FF,FF,FF,FF,FF
E,03.512,8,007,01,32,FF,FF,FF,FF,FF,FF
E,03.512,8,007,02,32,FF,FF,FF,FF,FF,FF
E,03.512,8,007,03,32,FF,FF,FF,FF,FF,FF

I basically just send the message index out in the D1 and D2, the rest is 0xFF. I set the CAN-BUS ID to 1, which should be EV.
Time bytes are one byte for mins and another for seconds...But this is all scrambled since CAN-DO expects a different time format.
At 1000 msgs/s these numbers are not meaningful anyway.. You mentioned using the RTC, but presumably not for message time info?

 

[garygid]

Good Progress.

I just posted my Due Sketch CanDo_Log_Test_Gg08x
that logs pseudo-messages to CAN-Do at about 1000 per second.
I have also used it at 2000 messages per second to CAN-Do.
I put in a ten second delay after power on before the Due
starts sending, so that I can have time to get CAN-Do's
input page running properly.

It also uses the Streaming library that I posted, to help format
some of the debugging output to the Serial Monitor.

I just discovered that the Due will run off the 5V from either
the Programming USB or the Native USB.

 

[klapauzius]

I just discovered that the Due will run off the 5V from either
the Programming USB or the Native USB.

Yes, it does. The biggest issue with running it off USB is that the analog data logging seems to be affected quite a bit by the noisy USB power.

edit:

Changed the time stamp to your convention. The due now logs and generates CAN messages in CAN-DO format. This is all with the hardware, so the whole logging stuff seems to work in principle.

So we have

CAN message reading
CAN message logging
fast AD reading
PWM

in place.

 

[garygid]

We would like to synchronize a milli-second timer with the seconds
"tick" of the RTC, and synchronize a seconds count with the RTC.

So, the first second-tick would reset the MS timer to zero, and set
the seconds count to match the seconds of the RTC. To do this accurately,
we probably need an interrupt from the RTC when the RTC second
ticks over (changes).

After resetting the ms timer, and initializing the Seconds Count to match
the RTC, we could use a minute-tick interrupt from the RTC to
re-synchronize the MSTimer, and trigger insertion of a Date-Time pseudo
message into the logging stream.

The Date-Time pseudo-message is added either immediately, or just after the
next CAN message is received, but before that message is put into the circular
buffer. In the latter case, the Time-Stamp of the Date-Time message would
match the Time Stamp of the "following" message.

I will try to add Setting the Date-Time of the RTC to the graphic control
panel.

There are two Resets to the Due, and one includes resetting the RTC.

Perhaps we can disconnect two of the tiny legs of the uP chip, use the
other Reset, and supply battery backup to the RTC?

Or, is the current Reset necessary for programming?

If so, the problem of using the RTC as a true RTC becomes
more difficult.

 

[garygid]

I am working with the CTE32HR 3.2 inches color touch screen,
and have not been able to get the 5" version to calibrate using
the UTouch library.

Does somebody else have any of the ColdTears Electronics displays
to test?

I know that JasonA has a 5" on order.

 

[klapauzius]

We would like to synchronize a milli-second timer with the seconds
"tick" of the RTC, and synchronize a seconds count with the RTC.

So, the first second-tick would reset the MS timer to zero, and set
the seconds count to match the seconds of the RTC. To do this accurately,
we probably need an interrupt from the RTC when the RTC second
ticks over (changes).

After resetting the ms timer, and initializing the Seconds Count to match
the RTC, we could use a minute-tick interrupt from the RTC to
re-synchronize the MSTimer, and trigger insertion of a Date-Time pseudo
message into the logging stream.

The Date-Time pseudo-message is added either immediately, or just after the
next CAN message is received, but before that message is put into the circular
buffer. In the latter case, the Time-Stamp of the Date-Time message would
match the Time Stamp of the "following" message.

I will try to add Setting the Date-Time of the RTC to the graphic control
panel.

There are two Resets to the Due, and one includes resetting the RTC.

Perhaps we can disconnect two of the tiny legs of the uP chip, use the
other Reset, and supply battery backup to the RTC?

Or, is the current Reset necessary for programming?

If so, the problem of using the RTC as a true RTC becomes
more difficult.

You could always add an external RTC...but having real time and date is more like an aesthetic thing here, right?

We can set the clock at the beginning of a logging session and then just have another timer insert the time/date every minute.

e.g.

 Timer4.attachInterrupt(insert_date_time_every_minute); 
 Timer4.start(60000000); //run every minute

The one-minute interrupt could also be used to set a new offset for millis(). All of these would be out of sync with real time, but getting them to sync would just require computing the fractional milliseconds in addition to the current RTC time.

My 3.2" display should be here any day now...

 

[garygid]

As soon as your display arrives (CTE32HR or CTE32?), let me know
and I will send some scripts to you.

I have these "interface" graphics:

button with caption, various colors
number entry with no caption

I am planning to add these:

checkbox with caption
radio button with caption
progress bar, horizontal
progress bar, vertical
integer value display with caption
integer value number-entry with caption
button with two line caption
title line

eventually add these:

checkbox icon with caption
graph-box

Any other suggestions for must-have graphic objects?

 

[garygid]

Other graphics objects, for parameter modification:

value bar, horizontal, with left and right arrows for changing the value
value bar, vertical, with up and down arrows for changing the value

 

[garygid]

Using the $15 Due/MEGA proto shield from NKC Electronics in Florida:
http://www.nkcelectronics.com/MEGAshield-KIT-for-Arduino-MEGA-2560-R3-and-Arduino-DUE_p_309.html" onclick="window.open(this.href);return false;

I am adding a CAN transceiver (TI SN65HVD235D, others are using the SN65HVD230D or SN65HVD234D)
surface mount to the 8-leg surface-mount pad provided on this proto board.

Wiring:
Connect the Ground pin to the nearby ground bus.
Connect the chip's + power to the power bus nearby.
Power that bus with 3.3v from the Due with a soldered wire jumper
(where one could install a jumper on the proto board)
Connect the Tx and Rx (digital I/O) pins to the Due's two CAN0 pins
(labeled analog in 14 and 15 on the proto board).
Install a 4-pin right-angle male connector nearby
(in the nearby 4 holes right at the side edge of the proto board)
Connect the CAN+ and CAN- pins each to a nearby hole
(leaving the hole open for a component, and to the nearby right-angle connector pin)

Depending upon the part number chosen, and the functionality
desired, connect the two remaining pins (#5 and 8) of the transceiver chip
as needed to achieve the desired operational effects.

For my 235 chip:
Pin 5 is...
Pin 8 is...

A 120 ohm "termination" resistor (or two 60-ohm in series) will be needed
across the CAN+ and CAN- if this "node" is an END-point of the CAN bus.
The termination resistor is not used if just connecting to an already-existing
CAN bus, like the three CAN buses on the LEAF's OBD connector.

Also, if some other node on the CAN bus does not provide the "bias" for
the CAN+ and CAN- lines, you must do that here (APPARENTLY needed
when you are "pretending" to be a QC-type device).

Then, using the due_can library, CAN (not CAN2) should control this port.

 

[garygid]

A variation of the above CAN transceiver connection would
be to wire it to the Due's CAN1 TX and RX pins, planning to
control the transceiver with "CAN2" in the due_can library.

I am building one board first, with no termination or bias,
to listen to the messages on the LEAF's OBD connector.
This board will also be able to act as the Simulator for
the LEAF's QC port.

My second (similar) proto board will have termination and
bias setting, for attaching to the LEAF's QC CAN bus, and
to use as the Rapid-Charge simulator, and eventuality,
the RC controller. This card could also attach to the first
proto board, to form a short CAN bus for on-the-bench testing.

The second card could act as an EV or CAR CAN bus simulator,
and, with the addition of a 12v power supply and a female
OBD connector, actually produce the CAN messages that
a GID-Meter (or other similar device) would be looking for.

Then, to demo the GID-Meter, I will just need some power,
and the Due programmed to emulate the CAR and EV
messages that carry GIDS, Pack Volts and Amps, SOC,
and Tire Pressures.

Can I get that working by Saturday morning...
I am not sure.

 

[klapauzius]

Some tests on PWM:
The maximum duty cycle @ 14 kHz can be set to 6000, however in this line:

  PWMC_ConfigureClocks(myPWM_FREQUENCY * myPWM_MAX_DUTY_CYCLE-1, 0, VARIANT_MCK);

The product cant exceed 84,000,000 it seems, so have to set it to myPWM_FREQUENCY * myPWM_MAX_DUTY_CYCLE-1.

 

[garygid]

Using the CAN port and an attached CAN transceiver:

1. For all uses of the transceiver, it is necessary to handle the
termination of the CAN bus. Sometimes, like when tapping onto
an existing bus, the termination (120 ohms between CANH and
CANL) should be removed. When acting as one END of a CAN
bus (there are always exactly 2 ends) the termination should
be attached. When simulating an existing CAN bus, which has
a termination at both ends, it may be necessary to double-terminate,
to make the simulated bus have the same 60-ohm resistance.

So, using two 120 ohm resistors, and two jumpers, I "attach" the
resistor and jumper (in series) across the CANH and CANL outputs
of the transceiver chip. This gives me the flexibility to have no
termination, End-of-bus termination, or rarely, the double-termination.

2. At ONE point on the CAN bus, there should be a bias voltage provided,
with the intent of setting the resting voltage of the CANH and CANL
lines when they are not being driven to the "dominant" (active) state
(a zero data bit) by any attached driver. In other words, no attached
node is actively transmitting a message. A node may be listening, or
might not be listening. If listening, it might listen for all messages,
like we do when we are logging, or just listen for a specific message
(MsgID) or, more often, to limited groups of MsgIDs.

So, cases where the bias circuitry is required are rare, but talking to
the LEAF's QC CAN bus appears to be one of them. It was reported that
the LEAF appeared to not send messages until a bias was supplied.
Of course, that might be a faulty observation, or incorrect conclusion.

There are several ways to provide the bias, but one method is
fairly simple, and would appear to offer slightly more noise
immunity. Using two more resistors, and two more jumpers
to disable the bias (because in most cases, attaching to any
functioning CAN bus does not require bias, and usually should
not have any additional bias), I am trying a 5k resistor in series
with a jumper. Connect the CANH, through the resistor and jumper,
to ground, and connect the CANL, through the other resistor
and jumper, to the 3.3v supply voltage.

more later...