Using an Arduino Due as a mini-QC controller

[klapauzius]

I ran the blink and many of the others already. So I will start playing with the CAN library.

 

[garygid]

I posted a copy of a CAN library and a Timer library, for convenience.

The 4 CAN examples compile, and the 3 Timer examples work.

However, it seems possible to lose timer "handler" executions
in some circumstances, when the executions are scheduled
while another handler is working, perhaps?

 

[klapauzius]

I posted a copy of a CAN library and a Timer library, for convenience.

The 4 CAN examples compile, and the 3 Timer examples work.

However, it seems possible to lose timer "handler" executions
in some circumstances, when the executions are scheduled
while another handler is working, perhaps?

Yes, I can compile the CAN examples. I dont have any CAN hardware (well.... I do have the LEAF...since I am a user of the extremely handy Bluetooth device and android app, I never got too much into the hardware CAN parts). Any recommendations...the CAN transceiver chip from microchip (MCP2562 ) seems to work with 3.3 V and 5 V, so it should work with the DUE.

Timer library works as well and examples compile and run. Seems to run stable over 303 periods (see picture. blue= timer 1, green = timer 2 red=timer 3)

So, what is next?

 

[garygid]

Mastering Interrupts, and PWM functions.

 

[klapauzius]

I have never used PWM in my applications, but from the basic examples, this seems not too complicated. I have worked with the old arduinos hardware interrupt pin (for a 1-channel wireless EEG, which was based on an external 24 bit ADC, which had its own oscillator).

Anyway, let me know what you want to do.
It is kind of reassuring that the CAN library compiled without major hiccups.

 

[garygid]

CAN Transceivers, 3.3v types:
from Mouser, the 595-SN65HVD234DR is the TI SN65HVD234D (R = on reel or tape).
http://www.mouser.com/ProductDetail/Texas-Instruments/SN65HVD234DR/?qs=sGAEpiMZZMsGqoCZrYwANjBlzIePRaFK1g9OIHjKooM%3d" onclick="window.open(this.href);return false;

The 230, 231, and 232 are one series, and the 233, 234, and 235 seem
to be a slightly more "rugged" series of transceiver chips.

I just ordered some SN65HVD234D and SN65HVD235D, but
another member is using the SN65HVD230D (less expensive,
but with fewer features).

The Android Due is currently "supporting" the SN65HVD234D, I believe.

 

[klapauzius]

CAN Transceivers, 3.3v types:
from Mouser, the 595-SN65HVD234DR is the TI SN65HVD234D (R = on reel or tape).
http://www.mouser.com/ProductDetail/Texas-Instruments/SN65HVD234DR/?qs=sGAEpiMZZMsGqoCZrYwANjBlzIePRaFK1g9OIHjKooM%3d" onclick="window.open(this.href);return false;

The 230, 231, and 232 are one series, and the 233, 234, and 235 seem
to be a slightly more "rugged" series of transceiver chips.

I just ordered some SN65HVD234D and SN65HVD235D, but
another member is using the SN65HVD230D (less expensive,
but with fewer features).

The Android Due is currently "supporting" the SN65HVD234D, I believe.

It looks like the MCP2562 does also work ? And it comes in a dip package.

Other than stock PWM frequencies seem to be slightly more complicated on the due, but seems like the forums cover a lot of this.
What PWM frequency is needed for this application?

 

[garygid]

PWM frequency on the order of 10k to 20k, with the 16-bit precision,
or as close as one can get with a 84 MHz / N clock,
and the pulse width controllable to one bit precision.

Since an ADC "fault" can put the PWM section into a "fail-safe" (perhaps
frozen) mode, this part of the function must be understood and controlled.

The Datasheet for the uP chip is only 1467 pages long.

--------
Other Issues:

1. My experiments with the Timer examples appeared to demonstrate
that expected timer-end "ticks" (end of the timer period should activate
the assigned handler routine) could get "lost" (handler not activated).

2. While using the ADC15 to read the uP's internal temperature, I got
different values, depending upon the delay time between reads, where
the delay really shouldn. the have mattered. This needs to be understood,
since reliable A-to-D is important.

3. The ADC system needs to be "primed" to produce good results,
apparently if not used within 10 seconds. This will affect the
startup of the program, and possibly cause other problems.
So, it needs to be understood.

4. The chip hardware "errata" (functions that do not work as expected)
need to be understood.

5. Running under the Android "core", which might not be perfectly understood
or debugged, can cause disruptions to the critical control-of-HV process.
So, someone needs to investigate how to program the Due hardware
such that we have control of every instruction executed.

6. Some have reported unexpected resets happening, something about
R23 and possible interaction between the two uPs on the board, and
"fixing" that apparently causes un-reliable power-On reset.
This needs to be investigated and a proper fix found.

7. For "proper" Logging, the RTC would be very nice to have.
Hower, Reset (the way the Due is wired) also resets the RTC.
Also, the 3v RTC battery backup input is wired to the 3.3v supply,
so a hardware (Due wiring mod) is required to properly use the RTC.

8. Since the uP apparently has no EEPROM, a method of saving
adjustable parameters needs to be developed.

9. For local (black box type) logging applications, one needs to be able
to write quickly, and reliably, to an SD, micro-SD, or Flash Drive.
Typical devices can accept data fairly quickly, but usually they "go on
vacation" occasionally during the write process, and suitable buffering
of the data-to-be-logged (in this case, CAN Messages, in binary CAN-Do
format) needs to be developed, capable of handling about 3000 messages
per second, of about 14 bytes each. 50kB, or 400kb, is not high, but
a 750 ms "vacation" can require a large buffer. Since the uP's RAM
is divided into two (32k + 64k) banks, how does one control the use of the RAM?

Yes, there are so many issues that it might seem premature to attempt
to use the Due. But, just tell a nerd that it cannot be done...

 

[garygid]

1. My experiments with the Timer examples appeared to demonstrate that
[some] expected timer-end "ticks" ([when the] end of the timer period should activate
the assigned handler routine) could get "lost" (handler not activated).

Reproduce the problem,
Discover the cause,
Design a good fix, if possible.

Does it only occur when
1. two timers have the same handler?
2. a timer ends and it's handler is already executing, or scheduled?

A bigger issue, how are interrupts, and priorities, and pending
interrupts handled? What structure is required for all interrupts
to be serviced quickly, and insure that none are lost?

Of course, making some (usually very short) code sections non-interruptible
is typically required, and keeping interrupt routines (handlers?) short can
also be critical. Traditionally, doing "printing" during an interrupt causes
problems, and interrupting one printing routine with another that prints
(or other common function) is a sure way to disaster.

So, if the Arduino "core" is not handling the handlers sufficiently well,
we cannot use the core "services" code.

 

[garygid]

10. What code is in the "bios" that is pre-loaded into the uP,
and what does it do for (and to) us?

Presumably, this code is what is executed whenever the uP is
Reset, right?

 

[klapauzius]

1. My experiments with the Timer examples appeared to demonstrate that
[some] expected timer-end "ticks" ([when the] end of the timer period should activate
the assigned handler routine) could get "lost" (handler not activated).

Reproduce the problem,
Discover the cause,
Design a good fix, if possible.

Can you post the code where you observed this?

I ran through the timer library examples and they seem to run fine (no missed callbacks) over a few hundred seconds.

How did you notice the missing callbacks?

Generally, for this charging application, will the arduino be always on, or start from boot, run a couple of minutes or hours and then be turned off again.
I.e. for how long do we want it to run stable?

 

[garygid]

Will post the Timer Sketch tomorrow afternoon
Cherrs, Gary

 

[klapauzius]

PWM frequency on the order of 10k to 20k, with the 16-bit precision,
or as close as one can get with a 84 MHz / N clock,
and the pulse width controllable to one bit precision.

Since an ADC "fault" can put the PWM section into a "fail-safe" (perhaps
frozen) mode, this part of the function must be understood and controlled.

The Datasheet for the uP chip is only 1467 pages long.

I will get to work on the PWM. At 20 kHz, the max resolution will be 4200, assuming that we can go in 1/(84 Mhz) steps.

ADC faults: do we know how to produce one?

I assume the arduino has really only one ADC, which is multiplexed across pins. If this ADC involves a capacitor somewhere (which I think it does), rapid switching between ADC pins could lead to wrong results. How this affects consecutive readings of the internal temp, I dont know.

Which brings up the next question: At which frequency do you want to sample? And do we need just one ADC or more?

 

[garygid]

Sorry, no timer sketches today, but tomorrow morning,
along with the Temp(erature) ADC sketch(es).

 

[klapauzius]

Ok. I got the PWM frequency change from initial software setting of 1 kHz to 10 kHz or 20 kHz working. I did not simply change PWM_FREQUENCY in the library (which would also work I assume), but made the change for a specific channel ( I hope...).

I think resolution can also be set as well, but have to run a few more tests to confirm that it works.

This thread on the arduino forums was quite helpful:

http://forum.arduino.cc/index.php?topic=131323.0" onclick="window.open(this.href);return false;

Presently, I have not fully understood the whole thing completely, so at the moment its a mere hack, but I do see 10kHz or 20 kHz on the scope, and I can vary between min and max and see the changes on the scope accordingly.

 

[garygid]

Good Work.

The 84 MHz divided by 10 kHz = 8400, and 20 kHz = 4200 clock counts.
We are currently using near 14 kHz, I believe, which would be 6000 clock counts.

Since 12 bits gives one 0 through 4095 we would want the 16 bit
PWM mode to use the 0 to 5999 period counter for 14 kHz
(or slightly less for slightly faster than 14 kHz).

Then, being able to set the PWM pulse width count directly from
from 0 (off) through about 5000 or so should do the trick.
With this we will get about 6 times the resolution that we had
on the AVR-CAN, with its 10-bit counter and 16 MHz clock.

 

[garygid]

With the problems that some have reported with the Due board,
we might need to use something else instead, perhaps the Mbed?

Its libraries are probably more mature, and the architecture
of the chip less convoluted.

 

[garygid]

Timers:
Apparent Results of my testing, using my AvailableTimerGg variation of
the standard AvailableTimer Sketch:

1. Apparently there are only 9 Timers "available", and defining
another apparently clobbers a "random?" previously defined Timer,
rather than just refusing to define the new Timer.
2. The delay after the definition of the Timer is not required, it
only seems to be used for actually spacing the Timer-Start times.
3. Handlers can be used by multiple timers, even ones with very
close start times.
4. The default "tick" interval, if not specified in .start()
appears to be 1 second, just like .sleep(1000000) microseconds.

More Later

 

[klapauzius]

Good Work.

The 84 MHz divided by 10 kHz = 8400, and 20 kHz = 4200 clock counts.
We are currently using near 14 kHz, I believe, which would be 6000 clock counts.

Since 12 bits gives one 0 through 4095 we would want the 16 bit
PWM mode to use the 0 to 5999 period counter for 14 kHz
(or slightly less for slightly faster than 14 kHz).

Then, being able to set the PWM pulse width count directly from
from 0 (off) through about 5000 or so should do the trick.
With this we will get about 6 times the resolution that we had
on the AVR-CAN, with its 10-bit counter and 16 MHz clock.

No problem. I think I can set the timer interval i.e. PWM_MAX_DUTY_CYCLE to any number. I only have an analog scope (20 MHz) so it will be hard to measure with this exactly if that gives us 6000 ticks resolution. Let me know if you want to pursue this further on the Due...

 

[klapauzius]

With the problems that some have reported with the Due board,
we might need to use something else instead, perhaps the Mbed?

Its libraries are probably more mature, and the architecture
of the chip less convoluted.

I have not seen anything bad happen in the examples for the DUE.
Tested the timer period and it was stable, no issues with the regular ADC at low sampling rates (i.e. @10 kHz) and haven't seen any problems with the serialUSB IO.

My experience with the old Arduinos is that they run stable for months.
Here we have an application that needs to run for a couple of hours maybe?
I understand that with the power involved, faults can have consequences, but my understanding is that the rest of the hardware, especially the LEAF itself is also fault-tolerant (how else would we plug it into the BLINK chargers and sleep at night....)?