Show Posts
Pages: 1 [2] 3 4 ... 22
16  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.
17  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.
18  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.
19  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.
20  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.
21  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);
22  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.
23  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.
24  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.
25  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.
26  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: February 19, 2014, 11:31:39 am
can I use CAN.mailbox_read() to get a frame from a specific mailbox? I can't work out the syntax CAN2.mailbox_read(0,frameRx0);

won't compile:

 " error: no matching function for call to 'CANRaw::mailbox_read(int, CAN_FRAME&)'
C:\Program Files (x86)\Arduino\hardware\arduino\sam\libraries\due_can/due_can.h:236: note: candidates are: uint32_t CANRaw::mailbox_read(uint8_t, volatile CAN_FRAME*) "

Yes, you can directly call mailbox_read in order to grab frames from any mailbox. However, the library automatically sets itself up for interrupt driven reception so you will have to disable that or you'll never have anything in mailboxes (the interrupt will snag it first). Clarification: Interrupts are not enabled for RX until you use SetRXFilter to create a filter. This sets up the interrupt for the mailbox that the filter is placed on. So, you can avoid this function and directly use mailbox_set_accept_mask and mailbox_set_id or you can call disable_interrupt(getMailboxIer(mailboxnum));

Then, the call to mailbox_read takes the mailbox number (0-7) and a pointer to the structure to fill. So, you'd probably want to make the call like this: CAN.mailbox_read(0, &myStruct);
Note that the function call expects the structure to already be in memory - it doesn't allocate one. So, your best bet is to allocate the structure like this: CAN_FRAME myStruct;
27  Products / Arduino Due / Re: Initializing the watch dog timer on Arduino Due on: February 17, 2014, 10:20:01 am
You don't. The arduino core developers set the watchdog timer off in the core before your sketch starts running. this is bad for you because you can only configure the wdt one time. thereafter any changes are ignored.
28  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: February 15, 2014, 07:26:26 pm
Yes, I am sure. Here is the reasonably quick version:

Canbus is transferred such that bits are transferred by either leaving the bus alone (recessive state) or pulling H and L lines apart (dominant state). This is actually one of the reasons for the terminating resistors - they pull H and L together when nothing is asserting the dominant state. So, recessive bits are transferred when no one is doing anything to the bus and dominant bits are transferred when at least one device is asserting dominance on the bus. Back to the point at hand - ack bit. Every frame has a single bit designated as the acknowledge bit - it is basically the last bit transferred. This bit is transferred as recessive by the transmitting device. If another device properly receives the frame (has properly gotten every bit before the ack bit) then it will assert dominance on the bus and the bit will switch to dominant. The transmitting device can detect this and will know that the frame was received. If nobody sets ACK then the transmitting node will normally try to resend. It has the option of never resending, trying to resend a couple of times, or resend forever.  You can see this behavior very easily. Put an oscilloscope on an isolated device (still use a terminating resistor) and try to send a frame. You'll see the oscilloscope light up constantly without ceasing as the device tries to resend the same frame over and over looking for acknowledgement.

Thus, usually frames won't drop on the network because the transmitting node should automatically resend. The catch is that you can turn this behavior off so there isn't a guarantee that the transmitting node is attempting resends even though it could.

Thanks Collin,

Are you sure about this statement (below). I've never heard of this and I don't know how it could work. I know that diagnostic CAN devices work very differently to normal CAN communication around a vehicle - is this what you mean?
A diagnostic device will send an incomplete (no data) frame that the target device (vehicle ECU, body control module etc) should complete and reply with. Under normal circumstances however, vehicle modules communicate by sending repeated frames at a (nearly) constant rate - for instance, engine speed from ECU to Instrument panel, Traction control torque requests from ABS module to ECU etc etc. The frames are 'broadcast' on the network and I don't think there is anything in the physical layer that could confirm frame receipt.

....The first possibility shouldn't actually drop the frame because canbus resends until somebody acks the frame. ....
29  Products / Arduino Due / Re: Is I2C working correctly on 1.5.5?? on: February 14, 2014, 01:47:21 pm
In this code, I get serial print all the time no matter if the chip is found or not.
It gets worse, if the chip is found, it correctly displays the results by reading the 2 incoming bytes, but if the chip is disconnected, it starts returning garbage. For example, it returns always 65321. If I connect and disconnect again, it returns a different number.
I scanned the bus and I can see the 2 bytes coming in when the device is plugged. See attachment.
But when the device is disconnected, I do see the correct response of the bus, which is exactly like the not found picture on the previous post.
So, the hardware is indeed responding correctly with a NACK, but the library is returning me garbage that I don't know where it came from. I think the problems really lies on the Wire.available() that is always returning true.

Oh, yes, I do think that my project exhibits this sort of behavior. If the EEPROM is on the board and responding properly then the program can get and set data. But, if the chip isn't there it still "works" in the sense that it returns data. However, as you found, it returns garbage that seems to be either random or some artifact of the hardware or software state.
30  Products / Arduino Due / Re: Is I2C working correctly on 1.5.5?? on: February 14, 2014, 12:38:16 pm
It works fine so far as I know. I'm involved with a fairly large project that uses the Arduino core with a custom Due-like board (GEVCU - an ECU for electric cars). This project includes I2C connected EEPROM and it works fine. I'm using a custom wire library but the only difference is that I enlarged the buffer to something like 270 bytes so that I could send 256 byte EEPROM pages along with a header all in one shot. So, I'd say that the wire library for Due works fine.
Pages: 1 [2] 3 4 ... 22