I'm about to migrate a project to standalone, but wish to be able to communicate with my new, own design, by USB to update code. I'm planning to use an Atmega1280 in a DIP package so I don't have the option of putting it on a 'normal' Arduino board.
I don't want to use a pre made board for comms, so any advice would be great. For example, could I program a 328 to do the USB to serial comms?
You need a chip that has USB connectivity - such as FTDI FT232RL, CP2102, ATMega8U2, ATMega16U2, ATMega32U4 (Leonardo).
Those are all small surface mount parts that can be difficult to solder.
This is the least expensive FT232 module that I have found.
CP2102 modules on e-bay also cheap.
You can also program via USB Programmer to an ICSP header, vs USB Serial to Rx/Tx pins.
I wasn't aware 1280's came in a DIP. They are not shown on Atmel's 640/1280/2560 data sheet.
Perhaps you were thinking 1284? Here's my Duemilanove style '1284 board, with a spot for MIKROE 483, or pins to connect FTDI Basic or similar.
EDITED POST
So, I've reworded this reply to get to the point quicker. After taking a look around at boot loading 2560s etc, it seems it is all well beyond my knowledge. What I intend to do is use a 1284 DIP as you have done.
However, I'm not trying to build a dev board here - but rather use the 1284 in a project, while retaining connectivity with the Arduino IDE by USB. So, thanks for the reply - it seems the easiest way around this would be to use a small Atmega to do the conversion between USB & serial, 16U2 or earlier. Is the code to do this conversion publicly available?
Alternatively, are you implying I can simply get rid of onboard USB to Serial conversion and use a cable like this, that connects to ICSP pins to program the chip from the Arduino IDE?
I'll list my questions;
The 1284 isn't listed as a board in the IDE, does this mean I cannot put the Arduino boot loader on the 1284 and program using the IDE? Same goes for the 16U2 - how would I program the required code into it to do the conversion? If however an FTDI chip would be easier, please advise
How do I go about boot loading the 1284?
I've read lots that most standalone boards like this need the reset button pressed during upload, how do I design in auto reset like normal boards, so I just have to press the upload button?
Many thanks in advance!!!
pre-question 1 - part like 16U2 that needs other parts & a ICSP header & programming is one way to go - or you can simplify design & assembly some and use a module like the one you showed, or use one like I showed. Here's an example of mine on a board that could easily have used a '1284 vs a '328.
I believe the 16U2 code is available, likely on github somewhere. The FTDI/CP2102 parts do not need programming.
pre-question 2 - If the final project does not need USB connectivity, but only programmability, then an offboard module is certainly an acceptable way to go.
Most of my projects are embedded into something and do not need USB interfacing, because there is no PC to connect to. You can connect an AVR ISP such as
http://www.mdfly.com/index.php?main_page=product_info&cPath=5&products_id=415 (and there are many others) and program via an ICSP header on your board, or use a USB/Serial adapter and program via Rx/Tx interface - you can see I have headers for both on this little '1284 card intended to be embedded into a project. The ICSP is needed for sure to install a bootloader so the USB/Serial interface can be used. But see question 2 below.
question 1 - the core files and pin definition files for the '1284 can added using maniacbug's files here
A couple of pin definitions are provided - the Bobuino attempts to follow the Uno pin usage, with Serial (0) on D0/D1, SPI on D10-11-12-13, and I2C on D18/D19 still. The others sort of start at one corner and work around the chip.
16U2 - add the other hardware to support it, and ICSP header, and program.
FTDI -same thing, add some addition hardware to support it, no programming needed.
question 2 - an AVR ISP is needed to bootload the part. I've done enough that I found it really convenient to have an Atmel AVR ISP Mkii ($34 at mouser.com) for bootloading, or sketch downloading without a bootloader. Nick Gammon has also developed a means to use an Arduino as an ISP programmer for the larger chips - many (all?) of the smaller ones do not support the whole programming space of the larger chips, while the MKii does.
See "program bootloader" and "upload/download .hex files" here:
Gammon Forum : Electronics : Microprocessors
There have also been some very recent discussion threads suggesting the '1284 might be supported already and just the pin definitions file might be needed.
See #509 and onwards here
ATmega1284P: End to End using 1.0 IDE - #510 by leo72 - Microcontrollers - Arduino Forum
question 3 - if you install a cap between the serial downloader's DTR pin and the 1284's Reset pin then the download software can create the needed reset.
The reset pin will also have a 10K pullup to +5, and a diode in parallel (cathode to reset, anode to +5). The CP2102 module can be modified with one trace cut and one jumper addition to bring the DTR signal out - make sure to use one that has DTR available at a breakout hole on the side. The FTDI parts have DTR available without a mod.
jtw11:
Alternatively, are you implying I can simply get rid of onboard USB to Serial conversion and use a cable like this, that connects to ICSP pins to program the chip from the Arduino IDE?
Yes, if your project does not need USB connectivity, you can upload your sketch using ICSP. You don't need a bootloader. This is what I always do when I migrate projects to dedicated hardware. Put a 6-pin ICSP header on your board. You need either an ISP (e.g. the AVRISP MkII), or you can configure an Arduino to be an ISP by uploading the ArduinoISP sketch to it.
dc42 - since you seem to be online - offtopic: can you point me to something where main(){} is discussed, how its hidden? Trying to find it, not having luck with forum searches, and I know its been discussed here.
Thanks
Hi Crossroads,
I've not see main() discussed in the forum, however the source code is in C:\arduino-1.0.1\hardware\arduino\cores\arduino\main.cpp under Windows. The Arduino IDE causes it to be linked (along with the rest of the core library) when the sketch is compiled.
I've found that if I modify the core source files, they automatically get recompiled.
Cool, thanks for the location. This stuff really gets buried!
So, it seems my understanding is growing a little.
It would also seem I've been a little confused by my own wording of "I need to retain USB communication" - what I really need to retain, is a method of reprogramming the 1284, and it just so happens that the cable used to do so may connect to a USB port on my laptop. Correct?
Which should also mean, if I understand correctly, that I do not need any onboard FTDI chips or other AVR chips to do a USB to Serial conversion, but rather I just need an ICSP header that goes to the correct pins on the 1284, and I just connect to this using an external converter cable like the one I already posted, this one?
...and the above is known as in circuit serial programming, or ICSP? Correct?
So what then is the ISP module? ISP used to burn the bootloader, ICSP used to flash sketches to the 1284?
I hope the above is correct! Many thanks again for all help so far.
EDIT: The mighty pages say only IDE 1 is supported, this may be a stupid question - but does this mean 1.0.1 IDE works, as it is newer than 1?
jtw11:
So, it seems my understanding is growing a little.It would also seem I've been a little confused by my own wording of "I need to retain USB communication" - what I really need to retain, is a method of reprogramming the 1284, and it just so happens that the cable used to do so may connect to a USB port on my laptop. Correct?
Which should also mean, if I understand correctly, that I do not need any onboard FTDI chips or other AVR chips to do a USB to Serial conversion, but rather I just need an ICSP header that goes to the correct pins on the 1284, and I just connect to this using an external converter cable like the one I already posted, this one?
...and the above is known as in circuit serial programming, or ICSP? Correct?
So what then is the ISP module? ISP used to burn the bootloader, ICSP used to flash sketches to the 1284?
I hope the above is correct! Many thanks again for all help so far.
No not correct. The module you linked to is a external USB to serial converter module, so it acts just like the on board serial converter on a Uno. A USB serial converter chip allows one to upload sketches from the arduino IDE if the AVR chip has a bootloader program already installed into the chip. You might call this serial programming.
ICSP is another different method to program a AVR chip on a arduino board. This requires a hardware programmer (that can also be a second arduino board running a ICSP sketch). The IDE can use some specific ICSP programmers (selected choice from the IDE tools menu) to burn sketches and also burn bootloaders onto AVR chips supported by the IDE.
So serial programming via a bootloader installed on the target chip, and programming via a ICSP to a target chip are two different methods, requiring different hardware components.
Lefty
So looking in the IDE, under programming is the AVR ISP mkII, as Crossroads recommended. So, using one of these and the IDE - you simple open up your sketch in the IDE, connect to the ICSP header using the ISP and flash away?
...and flashing sketches in this way means no bootloader correct, thus freeing up more space for the sketch? As there is no bootloader, do any changes need to be made to the sketch, or does the compiler still add in all the bits you miss out in the IDE.
Now correct? 
If the chip had a bootloader installed at some point, then all fuses will have been programmed for correct operation.
File: Upload Using Programmer does not change those.
This is evidenced by loading a sketch into a brand new chip using File: Upload Using Programmer, at which point the sketch doesn't run well at all.
Burning a bootloader, and then loading a sketch via File: Upload Using Programmer, everything runs normally.
This wipes out the bootloader code, and the sketch starts immediately after a reset.
The same .hex file for the sketch is uploaded either way.
I assume by not being corrected on my last post I was correct in terms of connecting things up? Please confirm, just so I'm going through this step by step in my mind and not building on incorrect knowledge,
Im afraid I'm not with you on your last post... Fuses and .hex files are not things I've ever changed or worked with, I can't say I know what they are.
Yes, the normal sketch is loaded, no change is needed. Bootloader is not loaded, you gain a little Flash memory.
MKii connects the ICSP header. Board must be powered - MKiid does not provide power.
Okay, good - look's like I understand up to where we are. My board will be externally powered anyhow, so it's not a problem - thanks for the heads up!
Now, just taken a look on the RS site to go and collect some 1284s, however - there is a 1284P-PU model, and a 1284-PU model. In your picture it seems you're using a 1284P-PU, is there however a difference that will matter in this application?
Also, back on the subject of fuses and .hex files - i've done a little reading, it seems that fuses are just bits of data stored on the chip, used to define certain configurations, internal vs external oscillator, clock scalars etc. Fuses seems to be a time from the black and white days when one time programmable chips were used, and these were indeed little strips inside the chip that must be burned out by applying current to them etc. Correct?
As for .hex files, is this the binary code file that the compiler writes and flashes to the chip? So what you're saying is, whether there is a bootloader or not, the .hex file remains the same - the bootloader is there simply to support USB.
jtw11:
- Now, just taken a look on the RS site to go and collect some 1284s, however - there is a 1284P-PU model, and a 1284-PU model. In your picture it seems you're using a 1284P-PU, is there however a difference that will matter in this application?
The P version has lower power consumption. The P and non-P versions also generally have different device IDs, which matters when programming them (you need to configure an entry in boards.txt with the matching device ID).
jtw11:
2) Also, back on the subject of fuses and .hex files - i've done a little reading, it seems that fuses are just bits of data stored on the chip, used to define certain configurations, internal vs external oscillator, clock scalars etc. Fuses seems to be a time from the black and white days when one time programmable chips were used, and these were indeed little strips inside the chip that must be burned out by applying current to them etc. Correct?
Mostly, however the "fuses" in the atmega chips are not really fuses, they are extra bits of nonvolatile memory and can mostly be reversed.
jtw11:
As for .hex files, is this the binary code file that the compiler writes and flashes to the chip?
Yes.
jtw11:
3) Reverting back to your post that I did not, but I believe now do understand - to set these fuses correctly, I must put the bootloader on the chip? Then when I flash a sketch using the programmer, the bootloader itself is overwritten - but the fuse settings remain the same, as a sketch has no influence upon the fuse settings?
That's one way of doing it. The other way is to run avrdude directly to program the fuses. See Prototyping small embedded projects with Arduino | David Crocker's Solutions blog for more.
1284P vs 1284 - pico power vs not. Different signature bytes to account for. Need to address while programming. I think make an addition avrdude.conf, copy the 1284p section and change signature bytes. Add a board type with "m1284" vs "m1284p"
Sort of. Are really a couple of EEPROM bytes that define the device configuration, vs one time PROM bits.
.hex file - yes, the result of the compilation of your sketch. Does not change whether you have bootloader or not - as long as the fuses are set the same.
You don't need to put the bootloader on to set the fuses - but it does seem the easiest way to do it (to me) from within the IDE and is how I do it. Loading a skecth that overwrites the bootloader does not change the fuses as far as I can tell.
I requested 3x 1284P-PU DIP packages from the Atmel samples page, and just got an email to say they've been shipped - so bit of a result.
Please elaborate on your question 1 response, I'm not sure I'm with you. I've read through the following a couple of times. Given that I will be using the P model, it seems all I need to do is download the file, put the mighty folder in place... which I have done - so I now have Bobuino, Mighty 1284p, Original 1284p etc as board options. To burn the bootloader, do I simply select 'Mighty 1284p 16MHz' as the board, select AVR ISP MKII as the programmer and click Burn Bootloader whilst connected to the ISCP header. Arduino on ATmega1284P | maniacbug
I haven't seen anything about signature bytes?
If you look in your copy of avrdude.conf, and find the '1284 section (might be 'm1284p'), you will see the signature bytes.
The different board types represent the pinouts used. You can look in the '1284 variants folders for the 3 board types, each has a pins_arduino.h file. Browse that to see the pinout being used. Notepad++ is a free download and very nice for looking at C/C++ files.
I don't know if the 1.0.1 supplied avrdude.conf includes the 1284 section, or if the mighty1284 files provide it. Am not at home to check.
So,
I've got the basic layout of a my standalone 1284P - seems to me this is the correct way to go about it, anybody care to confirm this or tear it apart? I would test it now, but my AVR ISP Mkii hasn't turned up in the post just yet.
