Show Posts
Pages: 1 2 [3] 4 5 ... 22
31  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.
32  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?
33  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.
34  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.
35  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.
36  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.
37  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.
38  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.
39  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.
40  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.
41  Products / Arduino Due / Re: UART byte format on: January 11, 2014, 08:32:19 pm
Bear with me here a moment. I'm going to give you a compilable program at the end but I'd like to explain how I got there so if anyone needs to do this again it doesn't take as much digging.

Serial1 is USART0 on the Cortex M3 chip. The easiest thing to do is use the Usart class defined in CMSIS. This is what the Arduino code does and what the _pUsart variable is. So, the easiest thing to do would probably be to make your own variable like that which is pointed to the proper place. Then you can use that variable just like the USARTClass does to change how the serial port works. So, you'd need to figure out where the variable is set and do the same thing yourself. Here is the definition for Serial1:
USARTClass Serial1(USART0, USART0_IRQn, ID_USART0, &rx_buffer2);
This line is found in variant.cpp which resides in the directory arduino/hardware/arduino/sam/variants/arduino_due_x

The first first parameter (USART0) is the reference we're looking for. So USART0 is defined somewhere to be a pointer to the proper memory location and Usart is the name of the class we need to use for this pointer. Something like this:

Usart * _pUsart = USART0;

Then you can directly work on that object just like USARTClass does. So, here is program that compiles. I have not tested it on a Due but it should work:

#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:
42  Products / Arduino Due / Re: UART byte format on: January 10, 2014, 10:02:15 pm
Hi all
I need on DUE 8N2 or 8E1 format? Any solution?

Both of those modes are natively supported by the USART hardware on the Cortex M3 chip. So, yes, there is a solution - you just tell the appropriate USART hardware which mode you'd like. (Sounds so easy when I say it like that!) You can find info about this in the Cortex M3 manual (atsam3x_dc.pdf) around page 837-838. Though, my guess that if you're asking a question like this you probably have no idea what the information in the document is really telling you to do - it can be a fairly daunting thing to get into. You find find where the serial mode is configured here: arduino/hardware/arduino/sam/cores/arduino/USARTClass.cpp/.h In USARTClass.cpp you will see how the mode is set. Now, does this do you a bit of good? No. _pUsart is protected so you can't access it from outside of the class. And, the class does not expose any way to set the # of bits, parity, and stop bits for the port. So, fun stuff. What are you to do then? Well, if you know you'll only ever need 8E1 mode then you can edit USARTClass.cpp to set that mode. Then every sketch you compile will automatically set the USART ports to 8E1. Or, you can manually set up pointers to the proper configuration space and then directly write the new mode from your sketch. This isn't terribly easy to explain how to do, especially since there are many USART ports. Or, you could edit the class to expose a way to set the parity and stop bits and then try to get the Arduino maintainers to pull your change into the mainline. That's the best way in my opinion. Or, you can get someone else to do it.

I guess the short answer is that you're kind of stuck if you hope to maintain general Arduino compatibility unless you directly write to the config registers yourself. Otherwise the Arduino core must be edited.
43  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: January 10, 2014, 09:13:41 am
I posted another example (a traffic snooper). But, does anyone have any other requests or suggestions? Maybe an example of how to do PID requests and parse responses for OBDII? I'd like at least some of the examples to be useful right off the bat for various things instead of being pointless demonstrations of features.
44  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: January 10, 2014, 09:11:42 am
Hi all,

I recently started following this thread and I was trying to see if I could get it to work on my own. I cant, however , seem to get the examples to compile and I keep getting the following errors.

CAN_EchoTest.ino:7:21: error: variant.h: No such file or directory
In file included from C:\Users\jhsieh\Documents\Arduino\libraries\due_can/due_can.h:72,
                 from CAN_EchoTest.ino:8:
C:\Users\jhsieh\Documents\Arduino\libraries\due_can/sn65hvd234.h:34: error: 'uint32_t' does not name a type
C:\Users\jhsieh\Documents\Arduino\libraries\due_can/sn65hvd234.h:37: error: 'uint32_t' does not name a type
C:\Users\jhsieh\Documents\Arduino\libraries\due_can/sn65hvd234.h:39: error: 'uint32_t' does not name a type

I'm sure I have done something obviously wrong. Can anyone point it out?

Hmm... variant.h does exist. My guess is maybe you aren't using the proper Arduino IDE (you need 1.5.2 or newer) or that you forgot to set the board to Arduino Due (programming or native port).  Otherwise, you do have the library installed to the proper place so it should work.
45  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: January 10, 2014, 09:08:27 am
Well I finally got my shield to work reliably, bad soldering was the problem.
Now I am faced with a 29 bit extended frame problem.

The due_can.cpp file has the following:
        ul_id = m_pCan->CAN_MB[uc_index].CAN_MID;
   if ((ul_id & CAN_MID_MIDE) == CAN_MID_MIDE) { //extended id
      rxframe->id = ul_id & 0x3ffffu;
      //rxframe->id = (ul_id);     // I wanted to look at the id - it always returns a 3 in the leftmost position
      rxframe->ide = 1;
   else { //standard ID
        rxframe->id = (ul_id  >> CAN_MID_MIDvA_Pos) & 0x7ffu;
      rxframe->ide = 0;

Your problem with the extended ID was not your fault at all. You can see in the snippet you posted this line:

rxframe->id = ul_id & 0x3ffffu;

I'm not sure what sort of brain malfunction beset me or whoever wrote that but the proper mask for extended frames is 0x1FFFFFFF not 0x3FFFF. I just fixed that in the git repo. Extended IDs are stored in the bottom 29 bits of the register so all you have to do is mask off the extended bit which is what that line was supposed to do. Try your sketch again and I think you'll see it work better now. Sorry about that.
Pages: 1 2 [3] 4 5 ... 22