garygid
Well-known member
In my v23 sketch yesterday, I switched to unsigned long to hold
the micros() result and to calculate the seconds. I also compared
(byte) sec to OldSec and now it keeps running for hours.
Still, I do not know what happens at the roll-over, which is
about once an hour (plus about 5 minutes).
I plan to have a timer-counter that counts milliseconds, and
reset that count to zero when I get a start-a-second-interrupt from the RTC,
then I would have at least coordinated h:m:s:ms to use for time-stamps,
and for the once a minute Date-Time pseudo messages.
However, real interrupts are still a mystery to me.
The control process will operate at least 10 times a second, but
probably more like 100 or even 1000 per second to try to achieve
better output regulation. This process will read inputs, see if the
CAN-control data has been changed, and take action depending
upon the state of the power supply and charging process.
The CAN input (QC messages from the car) could be handled
by a fast interrupt, or by dedicating 3 CAN "mailboxes" to
holding the latest expected input. However, for logging all
messages, some perhaps unexpected, that might come in,
and time-stamping them for logging, the interrupt method
is probably better.
So, my next step is to get the CAN I/O working well, using
CANRX0 and CANTX0 (Due pins D68 and D69).
I have one proto board with a TI 235 transceiver chip, and jumpers
to configure it almost any way, from no termination (for sniffing)
to providing double termination and bias for the CAN bus.
I will build a second proto board, also with a CAN transceiver, wired
to emulate the car's QC port (as we observe it), where it appears
that the CAN bus lines have only a simple terminator, which is
normally just 120 ohms.
Then, one Due will simulate the QC device, and the other will simulate
some of the QC aspects of the car. To do it right, there should also be
some additional connections for handshaking, but I will add those later.
the micros() result and to calculate the seconds. I also compared
(byte) sec to OldSec and now it keeps running for hours.
Still, I do not know what happens at the roll-over, which is
about once an hour (plus about 5 minutes).
I plan to have a timer-counter that counts milliseconds, and
reset that count to zero when I get a start-a-second-interrupt from the RTC,
then I would have at least coordinated h:m:s:ms to use for time-stamps,
and for the once a minute Date-Time pseudo messages.
However, real interrupts are still a mystery to me.
The control process will operate at least 10 times a second, but
probably more like 100 or even 1000 per second to try to achieve
better output regulation. This process will read inputs, see if the
CAN-control data has been changed, and take action depending
upon the state of the power supply and charging process.
The CAN input (QC messages from the car) could be handled
by a fast interrupt, or by dedicating 3 CAN "mailboxes" to
holding the latest expected input. However, for logging all
messages, some perhaps unexpected, that might come in,
and time-stamping them for logging, the interrupt method
is probably better.
So, my next step is to get the CAN I/O working well, using
CANRX0 and CANTX0 (Due pins D68 and D69).
I have one proto board with a TI 235 transceiver chip, and jumpers
to configure it almost any way, from no termination (for sniffing)
to providing double termination and bias for the CAN bus.
I will build a second proto board, also with a CAN transceiver, wired
to emulate the car's QC port (as we observe it), where it appears
that the CAN bus lines have only a simple terminator, which is
normally just 120 ohms.
Then, one Due will simulate the QC device, and the other will simulate
some of the QC aspects of the car. To do it right, there should also be
some additional connections for handshaking, but I will add those later.