List of compatible hardware/software

[Don_Kirby]

The recent thread discussing calling AVRDude from within the IDE brings up the idea of creating a list of successful hardware/software combinations along with the relevant command line details for said combination. It would be a good resource for those getting started with a generic device (or AVR hardware in general).

The list of pertinent details might include the following (in no particular order):

Operating system
Programmer
Software
ZBasic compiler version
Target device
Target device carrier board (if applicable)
Command line to be placed in the SciTEUser.properties file.


-Don Kirby

[dkinzer]

For ISP programmers with a substantial following, we can probably add macros that simplify the command line. For example, for AVRdude we can (almost certainly) provide a macro for the device name that evaluates to the abbreviated form it uses.

[stevech]

And for AVRdude -- that doggone time-wasting gotcha about the driver Letter's colon in the command line leading to the need for the :I suffix to the .hex file name.

Operating system: Win7
Programmer: AVR Dude, Arduino standard bootloader in AVR
Software
ZBasic compiler version
Target device: mega328P
Target device carrier board (if applicable) Jee Labs JeeNode
Command line to be placed in the SciTEUser.properties file. see prior post


Operating system: Win7
Programmer: Teensy USB hex downloader, Arduino bootloader target
Software
ZBasic compiler version
Target device: at90USB2 - should work same for Teensy II with ATmega32U4
Target device carrier board (if applicable) Teensy I
Command line to be placed in the SciTEUser.properties file. n/a, used GUI of Teensy USB downloader

[Don_Kirby]

Picked up a new 1284p the other day, and after a few minutes of 'adjusting', the result was positive:

avrdude.exe: verifying ...
avrdude.exe: 18390 bytes of flash verified

avrdude.exe done. Thank you.

>Exit code: 0

Details as follows:
Operating system: XP
Programmer: USBTinyISP
Software: AVRDude
ZBasic compiler version: 3.4.1
Target device: ATMega1284p
Target device carrier board (if applicable): Olimex
Command line to be placed in the SciTEUser.properties file: command.project.avr.go="C:\Program Files\WinAVR-20100110\bin\avrdude.exe" -c usbtiny -pm1284p COM1 -b 57600 -F -U flash:w:$(project.base).hex:i"



-Don Kirby

[dkinzer]

Command line to be placed in the SciTEUser.properties file: command.project.avr.go="C:\Program Files\WinAVR-20100110\bin\avrdude.exe" -c usbtiny -pm1284p COM1 -b 57600 -F -U flash:w:$(project.base).hex:i"

AVRdude accepts device names like ATmega1284P so you could have used the $(target_device) macro in the command line:

Code: Select all

"C:\Program Files\WinAVR-20100110\bin\avrdude.exe" -c usbtiny -p$(target_device) COM1 -b 57600 -F -U flash:w:$(project.base).hex:i

The nice thing about this strategy is that it automatically adapts when you change target devices.

For command lines that don't accept device names like ATmega1284P, you can provide a mapping. Consider these User Properties entries and the related downloader command.

Code: Select all

avrdude.ATmega1284P=m1284p
avrdude.ATmega644P=m644p
command.project.avr.go="C:\Program Files\WinAVR-20100110\bin\avrdude.exe" -c usbtiny -p$(avrdude.$(target_device)) COM1 -b 57600 -F -U flash:w:$(project.base).hex:i"

Macros in the command line are recursively expanded so the first pass converts -p$(avrdude.$(target_device)) to -p$(avrdude.ATmega1284p) and then finally to -pm1284p.

[Don_Kirby]

I like the mapping trick. It shouldnt be hard to great a map for every device for AVRDude.

Is there a method available to poll the IDE's download COM port setting and speed as well?

-Don

[dkinzer]

It shouldnt be hard to great a map for every device for AVRDude.

Yes, but it is unnecessary in that particular case. AVRDude accepts full device names, e.g. ATmega1284P, in addition to the abbreviated forms.

Is there a method available to poll the IDE's download COM port setting and speed as well?

The entry in the User Options file that specifies the COM port is debug.comport and its value is the numerical part of the COM port. You could, therefore, use something like COM$(debug.comport) for a port parameter. However, this probably won't be useful in general because, in most cases, the device programmer will be on a different serial port than that of the chip's console channel.

[Don_Kirby]

Am I correct in assuming that download.speed can be used also?

It's clear to me now that the User Properties in SciTE is taken from the Serial port options and other similar dialogs. Is it possible to add a text area in one of them (or an additional one) for entering the generic device command line string? The same dialog would also be a good place to make note of the available variables that can be used. Of course, having some prefab samples for common hardware would be useful, as would the the ability to remember previously used command line arguments.

-Don Kirby

[dkinzer]

Am I correct in assuming that download.speed can be used also?

Sure. You can use any property defined in the User Properties file - the syntax is $(property-name) which is replaced by the property's value when the command line is expanded. That said, it is not necessarily true that the download.speed value is appropriate for a particular downloading application. Some downloader applications expect to operate a a predetermined baud rate that cannot be changed.

It's clear to me now that the User Properties in SciTE is taken from the Serial port options and other similar dialogs. Is it possible to add a text area in one of them (or an additional one) for entering the generic device command line string?

Yes, the configuration values that you select or specify in various dialogs are stored in the User Properties file, generally as a name/value pair.

While it is true that a dialog could be created with an edit control to allow modifying the download command, doing so doesn't afford much of an advantage. It seems that it is nearly as easy to load the User Properties file (one click on the Options menu), find the property and edit its value.

[Don_Kirby]

While it is true that a dialog could be created with an edit control to allow modifying the download command, doing so doesn't afford much of an advantage. It seems that it is nearly as easy to load the User Properties file (one click on the Options menu), find the property and edit its value.

True, although the same argument could be made for the options currently accessible via the dialogs.

I would argue that, as ZBasic is such a great beginners tool, it makes sense to keep the IDE as consistent as possible, rather than 'hide' options in the properties file. That point is moot though; if the user is working with generic AVR hardware, they probably aren't beginners anymore.

-Don

[stevech]

The Arduino (Java based) IDE is dumbed-down to four GUI buttons!
But C++ even with the hiding they try to do, must be intimidating to newbies.