Show Posts
Pages: 1 [2] 3 4 ... 22
16  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.
17  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?
18  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.
19  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.
20  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.
21  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 (https://github.com/ivanseidel/DueTimer) 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.
22  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: April 07, 2014, 08:15:12 pm
My library (https://github.com/collin80/due_can) 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.
23  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.
24  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.
25  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);

and

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);
26  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: https://github.com/collin80/due_can 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.
27  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.
28  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:

Code:
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:

Code:
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:
Code:
if (SerialUSB.available()) serialEvent();

Problem solved! No, I have no idea why this doesn't seem to be in the Arduino core already.
29  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.
30  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;
Pages: 1 [2] 3 4 ... 22