Arduino Forum

Using Arduino => Microcontrollers => Topic started by: jtw11 on Oct 14, 2012, 12:02 am

Title: Standalone USB communications
Post by: jtw11 on Oct 14, 2012, 12:02 am
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?
Title: Re: Standalone USB communications
Post by: CrossRoads on Oct 14, 2012, 04:27 am
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.
http://www.mouser.com/ProductDetail/mikroElektronika/MIKROE-483/?qs=%2fha2pyFadugsEwyLV5fFyIWdPbushEDhRSvnBE0ODG8%3d

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.
(http://www.crossroadsfencing.com/BobuinoRev17/1284_thruhole2.JPG)
Title: Re: Standalone USB communications
Post by: jtw11 on Oct 14, 2012, 11:43 am
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?

http://www.ebay.co.uk/itm/1x-USB-2-0-TO-RS232-Converter-UART-TTL-Serial-CP2102-For-Arduino-UNO-ATMEGA-PIC-/221067324467?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item3378a3ac33

I'll list my questions;

1) 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

2) How do I go about boot loading the 1284?

3) 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!!!
Title: Re: Standalone USB communications
Post by: CrossRoads on Oct 14, 2012, 06:06 pm
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.

(http://www.crossroadsfencing.com/BobuinoRev17/piano_card_assy_small.jpg)

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.
(http://www.crossroadsfencing.com/BobuinoRev17/card1.jpg)

question 1 - the core files and pin definition files for the '1284 can added using maniacbug's files here
https://github.com/maniacbug/mighty-1284p
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:
http://www.gammon.com.au/scripts/forum.php?bbtopic_id=123
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
http://arduino.cc/forum/index.php/topic,80483.msg954816.html#msg954816

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.
Title: Re: Standalone USB communications
Post by: dc42 on Oct 14, 2012, 07:29 pm

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.
Title: Re: Standalone USB communications
Post by: CrossRoads on Oct 14, 2012, 07:40 pm
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
Title: Re: Standalone USB communications
Post by: dc42 on Oct 14, 2012, 09:37 pm
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.
Title: Re: Standalone USB communications
Post by: CrossRoads on Oct 14, 2012, 10:12 pm
Cool, thanks for the location. This stuff really gets buried!
Title: Re: Standalone USB communications
Post by: jtw11 on Oct 15, 2012, 12:07 am
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?

http://www.ebay.co.uk/itm/1x-USB-2-0-TO-RS232-Converter-UART-TTL-Serial-CP2102-For-Arduino-UNO-ATMEGA-PIC-/221067324467?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item3378a3ac33

...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?
Title: Re: Standalone USB communications
Post by: retrolefty on Oct 15, 2012, 12:19 am

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?

http://www.ebay.co.uk/itm/1x-USB-2-0-TO-RS232-Converter-UART-TTL-Serial-CP2102-For-Arduino-UNO-ATMEGA-PIC-/221067324467?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item3378a3ac33

...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
Title: Re: Standalone USB communications
Post by: jtw11 on Oct 15, 2012, 12:35 am
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? :-)
Title: Re: Standalone USB communications
Post by: CrossRoads on Oct 15, 2012, 12:59 am
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.
Title: Re: Standalone USB communications
Post by: jtw11 on Oct 15, 2012, 01:06 am
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.
Title: Re: Standalone USB communications
Post by: CrossRoads on Oct 15, 2012, 01:14 am
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.
Title: Re: Standalone USB communications
Post by: jtw11 on Oct 15, 2012, 02:03 pm
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!

1) 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?

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?

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.

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?

Title: Re: Standalone USB communications
Post by: dc42 on Oct 15, 2012, 02:46 pm

1) 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).


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.


As for .hex files, is this the binary code file that the compiler writes and flashes to the chip?


Yes.


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 http://miscsolutions.wordpress.com/2011/08/09/prototyping-small-embedded-projects-with-arduino/ (http://miscsolutions.wordpress.com/2011/08/09/prototyping-small-embedded-projects-with-arduino/) for more.
Title: Re: Standalone USB communications
Post by: CrossRoads on Oct 15, 2012, 11:56 pm
1.  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"

2. 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.

3.  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.

3.
Title: Re: Standalone USB communications
Post by: jtw11 on Oct 16, 2012, 04:55 pm
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. http://maniacbug.wordpress.com/2011/11/27/arduino-on-atmega1284p-4/

I haven't seen anything about signature bytes?
Title: Re: Standalone USB communications
Post by: CrossRoads on Oct 16, 2012, 05:20 pm
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.
Title: Re: Standalone USB communications
Post by: jtw11 on Oct 23, 2012, 10:56 pm
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.

(http://i1206.photobucket.com/albums/bb451/julianwest/1284PStandalone_zps4daaa4c5.png)
Title: Re: Standalone USB communications
Post by: cyclegadget on Oct 24, 2012, 01:11 am

You need a 100uf capacitor to GND on the AREF pin.

Only issue I have spotted.
Title: Re: Standalone USB communications
Post by: CrossRoads on Oct 24, 2012, 02:28 am
100nF is enough for Aref.
Make sure VCC/AVCC have 100nF also.
Title: Re: Standalone USB communications
Post by: jtw11 on Oct 25, 2012, 05:06 pm

Make sure VCC/AVCC have 100nF also.


Many thanks for the replies - just to confirm, the cap I've already put on the output of my voltage reg - C5 - is the cap for VCC/AVCC that should be 100nF?
Title: Re: Standalone USB communications
Post by: CrossRoads on Oct 25, 2012, 05:17 pm
Most 7805 regulators need like 10uF & 1uF caps, they are good for large current filtering.
In addition, you should have 100nF caps right at the VCC, AVCC, and Aref pins to filter out any high frequency noise on the power lines and to provide high-speed bursts of current to support the 16 MHz switching that goes on inside the chip.
Title: Re: Standalone USB communications
Post by: jtw11 on Oct 29, 2012, 02:19 pm
Okay, will get those values plugged in. Going back to what we were talking about early on in this thread, I've just realised - if I do not have USB connectivity, I've lost the ability to debug over serial.

I still do not plan to use a bootloader, but rather flash programs using my new AVR ISP Mk ii over ICSP. Serial comms will still work fine without the bootloader correct?
Title: Re: Standalone USB communications
Post by: CrossRoads on Oct 29, 2012, 04:31 pm
Yes, Serial comms will still work fine without the bootloader.
Title: Re: Standalone USB communications
Post by: jtw11 on Oct 31, 2012, 10:14 pm

Yes, Serial comms will still work fine without the bootloader.


Good good.

Now - I've wired up a 1284P on a breadboard just as I've shown in my Eagle schematic. I've connected up my AVR ISP Mk II to the relevant ICSP pins. I've got 'Mighty 1284P 16MHz using Optiboot' selected as my board. I have AVR ISR Mk II selected as the programmer.

When I click Burn Bootloader, I get the following error - avrdude: usbdev_open(): did not find any USB device "usb"

The ISP must be communicating with the chip, as if I go into Atmel Studio and click Device Programming, I can read the fuse states and signature etc.

My copy of avrconf has entries for the 1284P. Not that I know what they mean? Do I need to change the signature in there, for the signature I've read in Atmel Studio?
Title: Re: Standalone USB communications
Post by: CrossRoads on Oct 31, 2012, 11:19 pm
Probably just need to install the AVR ISP drivers.
Here's the file path:
Title: Re: Standalone USB communications
Post by: jtw11 on Nov 01, 2012, 12:00 am
I've run all the .exe files, but they don't seem to be installers. I guess what I need to do is do something with the file "avrisp2" - but I don't know what to do with this type of file?
Title: Re: Standalone USB communications
Post by: CrossRoads on Nov 01, 2012, 12:56 am
Don't you need to do Control Panel: Device Manager:Install new hardware, then browse to the folder, something along those lines?
Title: Re: Standalone USB communications
Post by: jtw11 on Nov 01, 2012, 11:40 am
Ah - that option isn't there in Win 7 by the looks of things, seems there's now a seperatate wizard (I'm usually a Mac user, but use Windows for Arduino related things for the support community here) I ran the 'hdwwiz' command to open the new hardware wizard.

However - seems the driver is unsigned, so just trying to find a workaround for that. I've tried temporarily allowing unsigned files using F8 during boot, and by disabling UAC and signing the driver using DSEO tool - still to no avail.

Now I know why I use Mac - installed Arduino on my iMac, added the Mighty files, connected the ISP Mk II - installed no drivers, modified nothing, worked first time. Result. Burned the bootloader, then overwrote with the blink sketch - it works fine.

However, I do need it working on my Windows laptop - any ideas?
Title: Re: Standalone USB communications
Post by: CrossRoads on Nov 01, 2012, 06:50 pm
I haven't made it past Vista yet, am not aware of what's  needed in Win7.

"Now I know why I use Mac - ... - installed no drivers, modified nothing, worked first time."'
That's just why I don't like Mac's - no user thinking needed, you never leam about what goes on inside.
Title: Re: Standalone USB communications
Post by: jtw11 on Nov 01, 2012, 08:34 pm
Point taken  :smiley-red:
Title: Re: Standalone USB communications
Post by: CrossRoads on Nov 02, 2012, 05:25 am
I wasn't trying to put you down, please don't take it that way.
Apple does a fine job of keeping their software suppliers in line, while MS seems to be in ongoing uphill battle to be everything to everybody all the time and constantly exposing themselves to some kind of hack/virus/malware/worm etc.
Apparently they are now trying to enforce this digital signature thing and making it harder to do things that were easier to do with XP and Vista.
Workarounds have been posted.
Try this one for the driver.
http://arduino.cc/forum/index.php/topic,118089.0.html
Title: Re: Standalone USB communications
Post by: jtw11 on Nov 02, 2012, 11:33 am

I wasn't trying to put you down, please don't take it that way.


Nono, I didn't take it in that way at all - do not worry!

I'll try the suggestions, many thanks.