Show Posts
Pages: [1] 2 3 ... 22
1  Products / Arduino Due / Re: i made a prototipe, now i want to make mi own circuit board, what should i do? on: August 07, 2014, 07:40:35 am
My name is Erick, im from Chile.
i'm new in Arduino, and for my tesis i have to make a prototipe using the Arduino DUE.
let's say i have make what i want, and now i design mi own PCB using the AT91SAM3X8E. my question is
how can i programm the AT91SAM3X8E (if i buy from RS- components o something like that) to make it run?
in pic i can buy a programmer, or even i can build one myself, so in the PCB i place 5 pins and i programm it, is something similar on this?


You're in luck! The SAM3X8E chip has a built-in bootloader that allows you to flash it! There aren't any specific outside parts that you need for this. The Arduino Due has it's schematic posted at their website. Download EagleCAD and take a peek. The most important aspects would probably be the reset and erase buttons and the USB hook up. After that you can connect via USB and use the Arduino IDE to flash. Just pretend your new board is an Arduino Due. I'm involved with a project that has done this very thing. We designed a new board and program it by just telling the IDE that it's still a Due.

To reiterate: The chip has all the programming firmware it needs already on board and all you have to do is be able to connect to it via serial or USB and you can program it.
2  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: August 06, 2014, 01:36:37 pm

The first two use the SN65HVD23X transceiver (where X is 0,3,4, etc). That transceiver will work fine. I really wouldn't recommend using the MCP2551 as it assumes a 5V tolerant MCU which the Due is not. If you are building a one-off prototype then the second link with a breakout board would probably be ideal. But, if you're going to use another board like an ethernet shield, then you might be able to add the bare SN65HVD chip on a prototyping section. All the ethernet shields I found don't have such an area though.
3  Products / Arduino Due / Re: Due for very low power applications? on: July 23, 2014, 11:48:21 am
As others have said, the Due is not meant to be used for very low power applications.

I've done some really low power devices before and it can be tough. Any tiny little detail can throw you off. Two big things that will kill your idle current are voltage regulators and pull up resistors. The due has both types of problem. I'm sure that they didn't pick the lowest quiescence current regulator possible. Voltage regulators can even leak current if you bypass them and feed the board directly from a different power supply. Additionally, I believe that the Due has pull ups on the first I2C hardware pins.  Another issue is that it probably leaves all sorts of peripheral hardware in an active state. Even if it doesn't, processors tend to leave their I/O pins in the state they were left in. Pins pulled high will continue to be pulled high, etc. This means you have to fix this before sleeping. It's all a large amount of work to make sure it works properly. The Cortex M3 isn't the most power efficient processor out there but one bonus is that running faster means you can do more work more quickly and go to sleep faster. Still, for super low power applications an 8 bit processor is probably the way to go.
4  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: July 21, 2014, 01:20:11 pm
To help narrow it down you should try two things:

1. Compile and run one of the example sketches that sends data. The pingpong sketch should be fine for this. It should immediately saturate the bus with attempts to deliver frames.
2. You don't happen to have another Due do you? (I'm doctor Suess now)
5  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: July 18, 2014, 07:47:41 am
Oops, I did miss that bug in your code. The data line should be:[0] = 0xFF;

The data member of the structure is a union full of different types of access patterns so you can access it by byte, by 16 bit int, by 32 bit int, or by 64 bits all at once.
6  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: July 17, 2014, 10:31:42 am
Sorry, I wanted to help but but I've been unable to log into this forum for the past few days. It seems to be fixed now.

Anyway, your code looked right except that you were missing a semi-colon and a hexadecimal prefix. The below two lines are what would have to change: = 0x7E0;
myFrame.length = 1;

Those are the correct lines.
7  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: July 11, 2014, 10:21:13 pm
Hello guys,
i have a so many mcp2551 transceiver chip. and i dont want to wait for work (china ship time 15 days  smiley-roll )
so they are 5v level, due is 3.3v level
after the level harmonize (5v>3.3v)
can i use them together with this can api?
Thank you so much

Sure, I don't see why not. We had standardized on a different chip just because it is 3.3v, reasonably respected, and easy to obtain. But, within reason you can use any canbus transceiver chip you want. The transceiver is almost completely transparent as far as the library goes. The only reason we even have code for the transceiver at all is because the SN65HVD chip we're using has an enable pin so you can turn the transceiver on and off. If you don't care about this you can just hard wire it to on or use a chip that doesn't have an enable pin.

As you mentioned, using a 5V chip will necessitate a level shift. You will, at the least, need to turn the 5V CAN_RX output from the MCP2551 into 3.3V for the Due. I'll bet the 3.3V CAN_TX signal from the Due will trigger the MCP just fine but you'll have to try it.
8  Products / Arduino Due / Re: IS Microsoft Visual studio 2008 compatible with arduino due on: July 05, 2014, 05:27:24 pm
It sure should be but if you hope to compile Due sketches in Visual Studio you need VisualMicro (use the power of google). I'm really not sure about VS2008 but VS2010 works fine.
9  Products / Arduino Due / Re: what's the suggested maximum potentiometer resistance to use with due? on: July 03, 2014, 09:12:27 am
Unfortunately there probably isn't an easy answer here. Do you have the Cortex M3 documentation for the processor? In section 46.7 you'll find a discussion of ADC performance. Table 46-35 seems to suggest that 10K ohms is at the high end of what is possible if the ADC clock is running full blast with 12 bit resolution. I've had jitter troubles with this processor in another design I'm working on so I feel your pain. You can make it work better by slowing down the ADC readings but that can be complicated. You could also take several samples and average them. Search the forums for DMA driven ADC if you want to roll your own ADC code to fix this up.
10  Products / Arduino Due / Re: EEPROM (beginners question) on: June 30, 2014, 09:27:00 am
Bad news... The ArduinoDue has no EEPROM. Thus, you can't store values permanently. It is possible to write persistent values to FLASH memory just like your program but such values will be erased the next time you flash a program to the Due. Most of us just add an I2C connected EEPROM to our designs somewhere.
11  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: June 20, 2014, 02:41:46 pm
Try to make sure that you really are compiling for the Arduino Due, using the 1.5.4 IDE or newer, and that you don't have any older copies of the library around. I've had people accidentally have two copies with an older one in the first place Arduino looks.
12  Products / Arduino Due / Re: Building a CAN API for Arduino DUE on: May 18, 2014, 02:50:31 pm
It actually isn't that good of an idea to try to use the MCP2551. That chip requires 5V while the Due is 3.3V. This difference will make using the chip difficult. You really do want the proper transceiver or another 3.3V compatible transceiver. There are lots of choices out there. The transceiver you use isn't really that important but you do need to match it to the proper voltage level.
13  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.
14  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.
15  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?
Pages: [1] 2 3 ... 22