Show Posts
Pages: 1 [2] 3 4 ... 23
16  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: May 11, 2014, 07:56:09 pm
As you found, the first order of business is to set the CANbus speed to the same speed that everything else on the bus was set to. If you don't do this you'll mess up all canbus comms and bad thing might happen. A common side effect is that your dashboard either quits working or goes nuts.

Now, the next issue is canbus mask and filter. You should use the most recent canbus library of mine and find the CAN_TrafficSnooper sketch. It sets the hardware to accept all frames and displays when it sees. This illustrates something about the mask and filter but I'll quickly go over it here.

Let's say a frame with id 0x211 comes in to the Due. The first thing that happens is that the Due hardware takes that ID and does a bitwise AND with the mask. So, let's say you have a receive mailbox with a mask of 0x7F0. 0x211 AND 0x7F0 is 0x210. The next thing is that it compares the new value with the value in the filter. If the filter value is 0x210 then they match and the frame is accepted. It's that simple. This same thing happens for all receive mailboxes. AND with mask, compare to filter. So, if you set your mask and filter to zero then it will always match because anything AND 0 is 0. You can use this capability to filter based on ranges. If you set a mask of 0x7F0 as in my example then it will accept any frame that matches the filter where the bottom nibble is ignored for matching purposes. This is quite common.

But, you're right, some documentation should probably be written.
17  Products / Arduino Due / Re: Automatic in-field Due reflash on: May 01, 2014, 10:34:01 am
By default an ARM cortex M3 chip can be reprogrammed by doing a hardware erase and rebooting. This will cause the built-in ROM based bootloader to start. You can then use SAMBA to reprogram the chip over USB serial (and maybe the first serial port as well). So, I suppose it'd be possible to do this in hardware and take advantage of the built-in bootloader. This still requires hardware modification to the boards. JTAG brings with it other nice things that are advantageous when debugging so if a hardware revision is necessary why not use JTAG? With JTAG it'd be possible to put one JTAG header on the board and debug any of the processors.

But, if hardware modification is not acceptable or possible then doing firmware flashing over SPI is perfectly possible and probably the way to go if all the processors are already on the same SPI bus.
18  Products / Arduino Due / Re: Automatic in-field Due reflash on: April 29, 2014, 08:36:37 am
I don't necessarily disagree Gogol. My suggestion was based on my presumption that they already have or plan to have a board where the various processors are connected via SPI. If they're already connected via SPI then why not continue to use that and do firmware updates over the connection as well? If they've already got boards made then using JTAG would require a hardware change and they might not want to do that. Otherwise, you're right, having JTAG would be very handy and bring with it some definite bonuses.

Yes, it is possible to cause the Arduino IDE to emit a permanent hex file that you can grab. Then this file could be streamed over the internet and replace the firmware. Of course, the problem with this approach is that you'd have to write software to do the internet upload and a bootloader that rewrites the firmware. Though, even with JTAG you'd still need some way to stream the firmware over the internet and chances are you'd have to write something for that as well. But, still, the JTAG approach would be a lot less software writing in all likelihood.

The basic outline for SPI based firmware updating would be something like this:
1. Your control hardware (Raspberry Pi?) sends a command over SPI to the running firmware on a Due/Cortex M3
2. The firmware sees that this command says to reboot into the bootloader so it shuts down everything and reboots
3. Upon reboot the bootloader takes control and tells the control side that it is ready
4. The control side begins to send firmware data which the bootloader uses to overwrite the existing firmware
5. The control tells the bootloader that it is done
6. The bootloader jumps to the start of the firmware program

The slight complication here is that you normally want the devices to start up without going into the firmware updating bootloader. On processors with EEPROM the ROM space tends to have a flag set for whether firmware should be updated or not. The Cortex M3 has no EEPROM so you can't signal via a ROM flag. You could store the flag in FLASH memory somewhere outside of the firmware or bootloader space or you could always start up in the firmware updater but timeout quickly if the control side doesn't signal that it is doing an update.

So, it's complicated but possible. I suppose the question is, can you modify the hardware or do you really need to do this via spi?
19  Products / Arduino Due / Re: Automatic in-field Due reflash on: April 28, 2014, 05:37:39 pm
The Cortex chip is capable of rewriting its own flash memory so I don't see any reason that someone could not construct an SPI based bootloader that can do what is needed. Now, I don't know of any off-the-shelf already done version of this but there should be plenty of examples of bootloaders that could be modified. This would then require zero hardware changes - just the addition of a bootloader located somewhere outside of where the programming must happen. This will probably badly break Arduino compatibility, at least for program uploading, but such is the price you pay.
20  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: April 16, 2014, 09:03:05 am
Somebody cann tell me if there is a Way to use the CAN on the DUE?
I must works well and it must work guaranteed. :-)

Would be great if someone with Arduino/CAN/DUE experience can talk to me in a pm. Thx a lot.

Yes, there is a way. You're in the right thread for that. It does work, the library has been used in several projects including an electric vehicle ECU that has sales in excess of 30 at this point (yes, that's still small but large enough that you can be sure we've tested it and there are many other people using it on a regular basis). Will I guarantee it? Of course not. It's software and its free. If it works for you, great! If it kills your cat, runs over your grandma, slaps your wife, and gives you diarrhea then I apologize.

FWIW, I recently posted a link to my version of the library. There is also another version which I believe is a bit more specialized to work in automotive uses. Pick your poison and we'll try to help.
21  Products / Arduino Due / Re: ADC and Timer relationship in DUE on: April 16, 2014, 08:56:05 am
Well, that's certainly a creative way to do it. That code does set the ADC to free running mode in what seems to be 1MHz sampling. Every micro second it calls the interrupt handler which updates a variable. A timer is also set up and when it "ticks" it calls an interrupt handler which in turn takes the current value of that variable set by the ADC interrupt and uses it. So, the ADC is not running with the timer but instead both are being used sort of in concern to still basically do the same thing. Why would someone do that? I have no idea. This sketch wastes all sorts of time by constantly updating the ADC readings when there is no need to. It would have been better to directly couple the ADC readings to a timer but maybe the person who wrote that sketch didn't know how or otherwise was more comfortable with their approach. Still, the approach in that sketch will work so you can use it if you want. It'll be fine so long as you don't start to need more performance. The Due is 84MHz so it has power to spare for sketches like this.
22  Products / Arduino Due / Re: ADC and Timer relationship in DUE on: April 15, 2014, 09:20:35 pm
You seem to be talking about timer triggered ADC. You can do this. It is discussed in the SAM manual in 43.6.5. You can connect basically any of the timers so long as they are in waveform mode. This could all be a bit tricky if you are new to the whole process but look at the DueTimer library ( for an example of how to set up timers. You will likely have to provide some different settings but the code will show you how you set things up. You have to do this same type of thing to configure the ADC as well. The Arduino core is not going to help you out with any of this.
23  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: April 07, 2014, 08:15:12 pm
My library ( has a traffic snooper example. The library you're using I believe was based off of my version of the DueCan library so you might be able to retrofit the example to your library. The library you found a while back in the official Arduino tree is an older copy of what my library is based off of. I don't remember if it was an earlier version of my library or what I based my code on. Either way it's fairly old. But, the CAN_TrafficSnooper example from my current library should point you in the right direction.
24  Products / Arduino Due / Re: Store and change data on a DUE which are not Reset after power cycle on: March 31, 2014, 11:47:13 am
You can store persistent data in Flash memory. It will persist between power cycles. However, and this is potentially a large issue, flash is completely 100% erased when new firmware is uploaded. All of your settings will disappear. So long as you keep the firmware stable you can continue to use flash memory as storage space. Another possibility, which I don't think anyone as tried, is to read the stored settings from flash before erasing. Then add those settings back into the file to flash, erase the flash, and upload the new firmware + settings. This should work fine but you'd have to create a custom upload script to do this. The easiest approach is really to use an I2C connected EEPROM chip for your storage. They're cheap, easy to wire, and small.
25  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: March 12, 2014, 09:38:49 pm
I need to get the most obvious two points out of the way first:

1. Are you using some sort of CANBus shield which has transceivers on it? You really do need transceivers. If you do have a board then it would help to know if it was something you made or something you bought (and if so, which board did you buy?)

2. Are the canbus wires terminated? A lot of shields are going to have at least selectable termination but you need there to be 60 ohms between CANH and CANL. This should take the form of a 120 ohm resistor at each end of the bus.

Even with the proper transceivers you will not get a signal through between two devices without some termination. A lot of times you can get away with just one 120 or 100 ohm resistor on one end if the link is short. But, 60 ohms is proper.
26  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: March 10, 2014, 10:12:24 am
setRXFilter has two forms:

int setRXFilter(id, mask, extended);


int setRXFilter(mailbox, id, mask, extended);

You seem to be using the second type that allows you to explicitly set which mailbox you are talking about.

In order to properly filter a frame you need to set reasonable values for both id and mask. The incoming frames are AND with the mask and then compared to the id. So, if you need to accept only frames with 0x7E8 then you can set the mask to 0x7FF which forces all frames to exactly match the id. Thus, your call would be:

CAN.setRXFilter(filter, 0x7E8, 0x7FF, false);
27  Products / Arduino Due / Re: Arduino due CAN capabilities on: March 07, 2014, 03:47:38 pm
Yeah, the thread is long. Buried in there are schematics to make boards, offers of boards already made, and the library. I can at least help with the library portion. I maintain it and it is found at: There are examples in there of how to use it. It's not perfect. I really should work on it some more but I keep getting busy. Still, it has been tested to work on a variety of projects. If you have questions feel free to ask me directly or post to that super long thread. I do check it frequently.
28  Products / Arduino Due / Re: Pass in Arguments to Arduino Due on: February 27, 2014, 09:18:27 am
Yes, the Due can do 64 bit doubles but why would you? The Cortex M3 chip still lacks an FPU just like the AVR chips in the other Arduino boards. It's still slower than a  three legged dog swimming through molasses when trying to do floating point work. The advantage is that the Due is something like 8 times faster in clock speed and has 96k of RAM. On the Due you can get away with some programming habits you picked up doing PC programming and still be OK. But, in my opinion, using floating point is not one of them.
29  Products / Arduino Due / Re: SerialEvent on Due's native USB port never gets fired on: February 27, 2014, 09:01:13 am
Here is a snippet from variant.cpp:

void serialEventRun(void)
  if (Serial.available()) serialEvent();
  if (Serial1.available()) serialEvent1();
  if (Serial2.available()) serialEvent2();
  if (Serial3.available()) serialEvent3();

You will notice that there are 4 serial event handler functions defined. You'll also notice that SerialUSB is not one of them. To the best of my knowledge there is no serialEvent type function for the SerialUSB (native port) on the Due. You need to do this yourself. This isn't as big of a problem as you might expect. That function I showed above? It is called every time your loop function is called. So, really, it is just a convenience. Put these lines in your loop function:

while (SerialUSB.available()) {
   //do stuff with data from the native port

This will do what you want. Or, put a line just like the ones from variant.cpp in your loop. If you want serialEvent to handle your native USB port traffic then put this line into your loop function:
if (SerialUSB.available()) serialEvent();

Problem solved! No, I have no idea why this doesn't seem to be in the Arduino core already.
30  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: February 19, 2014, 02:31:24 pm
I know this might be nitpicking and it's probably far too late to change now, but...

A common convention for names in all caps and with underscores (eg, "CAN_FRAME") is for constants from #define.

Yes, you're right. It's not a particularly great thing that the structure is named like a constant. I don't remember the how or why of how this happened. Maybe there was some insanely good reason but likely it is a mistake that never got corrected. I suppose in the interim I could create a typedef or #define to remap it to a more correct convention like CanFrame and then eventually make the actual switch.
Pages: 1 [2] 3 4 ... 23