Show Posts
Pages: 1 2 [3] 4 5 ... 23
31  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;
32  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.
33  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. ....
34  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.
35  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.
36  Products / Arduino Due / Re: PROGMEM on Due on: February 13, 2014, 03:59:04 pm
On the Due try pretending that the data is really in RAM when you read it.
37  Products / Arduino Due / Re: PROGMEM on Due on: February 13, 2014, 01:04:48 pm
It is true that there is no really good way to store changeable persistent data on the Due. However, if you were using PROGMEM then you probably were using it to store static information weren't you? In that case you can declare variables const to place them into flash memory. In fact, it appears that the 1.5.3 version of the Arduino IDE added compatibility so that you can use PROGMEM on the Due and it'll do the right thing. Have you tried it?
38  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: February 12, 2014, 03:45:12 pm
Sorry Mark, I should have answered those questions before.

1. CAN.get_rx_buff() grabs the first canbus frame in the receive buffer. The receive buffer is filled as frames come in to the RX mailboxes. There is currently no way to easily figure out which mailbox the frame came from.  The mailboxes are automatically cleared as soon as their frame is placed into the receive buffer. If a frame is being dropped then one of these things happened: all mailboxes that could accept the given frame were still full and the frame could not be received or the software did something dumb and lost the frame. The first possibility shouldn't actually drop the frame because canbus resends until somebody acks the frame. So, the only way it would be "dropped" at the Due is if the Due could not accept it but something else on the bus did set acknowledge on the frame. The second possibility could be a race condition in the interrupt code. It might be harder to find.
2. Not currently. The frames are automatically stuck into the receive buffer for you to check later on. There isn't a way to register a callback right now.

I have a kvaser leaf light so I might be able to do some testing to see if I can get the Due to drop frames. I know it does sometimes because I've tried to capture a firmware update between an ECU programmer and a motor controller and the Due could not keep up with the traffic. The Kvaser leaf does.
39  Products / Arduino Due / Re: DUE interrupt latency on: January 30, 2014, 09:05:45 am
The actual interrupt handler is defined in WInterrupts.c as:
void PIOA_Handler(void) {
uint32_t isr = PIOA->PIO_ISR;
uint32_t i;
for (i=0; i<32; i++, isr>>=1) {
if ((isr & 0x1) == 0)
if (callbacksPioA[i])

What you want to do is override this function. You can do that but you have to define it as weak. Add this line before that function:
void PIOA_Handler(void) __attribute__((weak));

Now, you are free to create a function that matches the prototype in your sketch and it will actually override the Arduino core version properly at link time. This requires changing the arduino core source just a bit so it doesn't quite fit the bill for what you originally wanted but it is close.
40  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: January 27, 2014, 07:56:36 pm
I have looked at both of the above mentioned canbus libraries (SK-PANG and nunoalves). In either case the actual PID/OBDII processing is pretty basic and straight forward. There is no reason that such routines could not easily be constructed for the Due canbus library as well. The actual sending and receiving of OBDII frames over canbus is pretty simple. You generally send to a broadcast address a simple frame with 8 data bytes and you get back a frame from the ECU that chose to respond. This frame also has 8 bytes. The format is explained at:

As for testing my library successfully: A previous version of it has been used in an open source vehicle control unit for around a year now. The most recent version has been tested by me with various other devices and seems to function. I actually haven't gotten a lot of feedback on the newest version so buyer beware - it works for me though.

That ECU project actually has OBDII/PID code in it already in the WIP branch. I haven't gotten a chance to test it out yet but the basic idea is there. I think that someone suggested that it'd be good to build higher protocol layers into their own libraries and not muddy up the canbus library with all sorts of protocols. That's a good idea. The PID library would be really simple but that's OK. I'll try to create such a thing in the next week or so.
41  Products / Arduino Due / Re: Arduino DUE with WiFi Shield - Sleep Mode possibilities on: January 27, 2014, 09:25:59 am
Yes, this is possible and no, you do not need to power them separately. The processor on the Due can be put into sleep mode via software commands and be woken up by interrupts. I am nearly sure that nothing in the Arduino library is exposed to support this sort of thing though - you'd have to access the hardware registers manually and then send the sleep command. This is one of those things that is possible to do but you have to read the cortex M3 documentation and find the stuff you're looking for. Once you do that you can search the CMSIS and libsam folders for headers that might make your life easier.  The processor has a power management system specifically for this purpose. Look for pmc.h and pmc.c in libsam.
42  Products / Arduino Due / Re: Inverted serial on Arduino Due on: January 19, 2014, 01:15:25 pm
You can make the serial port run in inverted mode. For a previous person I posted the following snippet as a way to do what they wanted:
#include "USARTClass.h"

Usart *_pUsart;

void setup() {
  // put your setup code here, to run once:

  _pUsart = USART0; //USART0 is Serial1, change this for other serial ports
                   US_MR_NBSTOP_1_BIT | US_MR_CHMODE_NORMAL;
void loop() {
  // put your main code here, to run repeatedly:

You can do the same thing. You need to set inverted mode in your mode call and you probably don't want many of the other options that that user needed. But, you could do this:


All of these mode setting definitions are found in arduino/sam/system/CMSIS/Device/ATMEL/sam3xa/include/component/component_usart.h

And, remember, all that code was setting the mode for Serial1. If you aren't using Serial1 then you will need to that _pUsart = line. Serial is NOT a USART but rather a UART and the mode definitions are probably different. You should still be able to do the same basic thing but you'll have to look up the mode bits.
43  Products / Arduino Due / Re: UART_Handler on: January 15, 2014, 10:34:53 am
The problem is that variant.cpp really does define an interrupt handler for the uart. In C/C++ you can't override bare functions, only methods of a class. That last statement is what most people will say and normally is a safe bet. It isn't strictly true. Think of this for a moment: the core will always call serialEvent() when the first serial port gets data. You may or may not actually define such a function. So, why doesn't it fault with a link error if you don't define the function? Because the core has an empty function called serialEvent. But, I said you can't override bare functions. Well, I lied. You can but only with a linker trick. serialEvent shows you this trick. You can define a function as weak and override it with a strong function. (All functions are strong by default - you have to set them as weak)

So, it might be possible to override the core interrupt handlers for serial if you define them as weak:
void UART_Handler(void) __attribute__((weak));
void UART_Handler(void)

I have no idea if you can define interrupt handlers as weak or not. But, you are free to try. If it works then you will have edited your copy of the Arduino core and no one else will be able to compile your sketch unless they too edit their core files. In this case perhaps it would be good to bring up this issue on the Arduino developers list and define all interrupt handlers as weak in case a sketch wants to override.

EDIT: I set the versions of the serial interrupt handlers in variant.cpp to weak and made my own. The resulting sketch compiled and the map file suggests that it properly is using the new version. I don't have enough hardware with me right now to actually test but I'm about 95% sure that this method will work perfectly fine. So, have fun.
44  Products / Arduino Due / Re: UART Interrupt with serialEvent() on: January 15, 2014, 09:28:16 am
My previous posting was sort of wrong. You see, the arduino core for Due does use interrupts for the serial comm. It has pretty much always been there. But, until around 1.5.2 or 1.5.4 they didn't internally to the core have the line:
if (Serial.available()) serialEvent();

So you'd have to do this yourself. That line causes your function called serialEvent to be called if there is available serial data. If you look at the defintion for the method available you'll see that it is checking the serial buffer for characters. Those characters are placed there by the serial interrupt handler. Whether or not the line above is there you can always poll yourself with:
if (Serial.available())

Now, this feels like polling and it is on your end but actually you are polling a buffer that is filled by an interrupt handler. No, you don't ever get a chance to directly implement your own serial interrupt handler. The arduino core has its own handler.

These lines are automatically run every time your loop function is run:
  if (Serial.available()) serialEvent();
  if (Serial1.available()) serialEvent1();
  if (Serial2.available()) serialEvent2();
  if (Serial3.available()) serialEvent3();

As you can see, this allows you to have functions that are automatically called for four serial ports if one of them gets incoming data. All the serial ports are really interrupt driven though. Your best bet is really to implement the appropriate serialEvent function and keep your loop function short.
45  Products / Arduino Due / Re: MMA7455 + Arduino Due on: January 12, 2014, 12:43:14 pm
I would think that it would work with minimal, if any, changes but the only way to find out is to try it. Luckily that accelerometer seems to work at 3.3V so that matches the Due.
Pages: 1 2 [3] 4 5 ... 23