[TUT][HARD][SOFT] USBasp Internals. Learning & sharing

Go To Last Post
29 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The following is to share hours of testing and findings around tweeking USBasp 2009 firmware and hardware. Perhaps others doing similar work could post their experiences here.

File Package: usbasp.2009-02-28.tar.gz (260kBytes)
Location: http://www.fischl.de/usbasp/
By: Thomas Fischl (Germany)

The package supplied was written in C language, and contains few assembly routines at the USB side of the firmware, to provide correct timming within the USB communication.

The package contains:

 bin           [dir] Ready made .hex files  
    firmware   [dir] Firmwares for Atmega48/Atmega8
    win-driver [dir] Windows Drivers

 circuit       [dir] Hardware Schematics 
 firmware      [dir]
    usbdrv     [dir] Source files USB communications
    clock.h   
    clock.c   
    isp.h
    isp.c     
    main.c    
    Makefile
    usbasp.h
    usbconfig.h

For studying purposes, I built the exact schematics in a jumperboard, flashed an AtMega48 with the supplied firmware (using another USBasp unit), and it worked. To make sure I had installed the GNU toolchain (AVR-GCC), then compiled the supplied files (make main.hex) and reflashed the AtMega48, and it worked.

I also needed to build a third AVR board to be the target of this programmer JumperBoardUSBasp. After this setup, I had enough confidence to change anything I want in the hardware/firmware and test.

The main function of this USBasp project is this AVR being used to program other AVRs via the ISP 10 pins connector. But the way the schematic was done, this AVR can also be programmed (firmware update) from an external programmer, via the same ISP 10 pins connector.

SELF PROGRAMMING JUMPER - JP2

The AVR datasheet, ISP programming section, states the target AVR's RESET pin must be held down while programming. As a "programmer", this circuit uses pin PortB.2 (PB2) wired to ISP connector pin 5, to control the RESET pin of the other AVR being programmed. So, the external (other) AVR being programmed needs to have its own RESET pin connected to ISP connector pin 5. This is the standard Atmel ISP 10 pins connector setup.

The way this schematics were done, it is possible to program the AVR onboard, by use an external programmer, anything that uses ISP 10 pins. AVRISP-mkII, Dragon, parallel port cheap solutions, even another USBasp similar programmer.

But to program this AVR, its RESET pin should be held down during programming. So, there is a jumper connecting its own RESET pin to ISP connector pin 5. This "Self programming" jumper must be removed for normal operation, but must be inserted for change firmware on this chip on board.

During my dozens tests of reflashing this AVR on the jumperboard, I was tired of inserting and removing this jumper, so I made it automatically. I was using another USBasp programmer to flash this one. Considering that pin 3 of the ISP connector is empty, I wired this pin to the RESET pin of the jumperboard via the "Self Programming" jumper. At the external USBasp programmer, I wired pin 5 to pin 3, with a simple solder blob.

This way, whenever a 10 wire flat cable is connecting both programmers, and the jumper installed, the jumperboard one will automatically have its RESET pin tied to the PB2 of the external programmer. This eliminates the need of the "Self Programming" jumper on and off. That is very good during development, when you need massive reflashing, but to avoid problems on normal operation, just remove such jumper.

USING D+ and D- in OTHER AVR PINS

The usbconfig.h contains several configuration that the user may change and adapt to his own compilation. Normally the user doesn't need to change anything, if using the original circuit diagram setup. The default setup uses pins PB0 (PortB.0) and PB1 (PortB.1) for connection with USB connector.

If while designing a new printed circuit board the user decides for a better pins to be connected with USB +D and -D, the user needs to change such configuration at the usbconfig.h.

Inside the usbconfig.h, after line #13, the section "Hardware Config", the user will find three definitions.

#define USB_CFG_IOPORTNAME   B
#define USB_CFG_DMINUS_BIT   0
#define USB_CFG_DPLUS_BIT    1

In the above setup, the definition is saying that pin D- and D+ from the USB plug needs to be connected to PORTB bits 0 and 1 respectivelly. If you verify at the schematics supplied, will find out the connections are correct. The AVR needs an interruption from D+ pin, this is programmed to happens at INT0, also pin PortD.2. You can see at the schematics that pin PB1 is connected to PD2, for that reason.

But D+ doesn't need to be on those pins, it may also be only on PD2 (PortD.2), so it will do the double function, will work as D+ and will generate the interrupt on the same pin. So I wanted to change it.

As I would change D+ to be at only one pin (PD2) I also wanted to change D- to be close by, so I chose PD3 or PD4, leaving PD0 and PD1 free for a possible RX and TX use of the USART.

Then I changed usbconfig.h to:

#define USB_CFG_IOPORTNAME   D
#define USB_CFG_DMINUS_BIT   4
#define USB_CFG_DPLUS_BIT    2

Compiled (make main.hex) and programmed the main.hex to the AtMega48 on board, change the wires connecting USB connector to D+ and D- new pins, and... voilá... didn't work. It took me lunch time to find out the problem.

Using osciloscope, I found pin D- down, it should not, it has a 1k5 or 2k2 Ohms resistor to VCC. The original setup (PB0) had a +5V via the pull up resistor, right after powering up the circuit. Why this new setup for D- tied to PD4 is down?

Something what messing with the initial setup of the ports. Searching in the files, I fould that the new pins I choose for D+ and D- (PD2 and PD4) were not setup correctly at the main.c file, despite the text below at the usbconfig.h, that could make one think changing setup here would be enough. It is not.

/* This is the port where the USB bus is connected. When you configure it to "B", the registers PORTB, PINB and DDRB will be used. */

At the end of main.c file, below, PORTD (DDRD) is set with all pins output, except for the INT0 pin PD2 that needs to be input. Also, PortD is set all pins down, and no pullup at PD2. PortB is also set with all pins down, and DDRB making all PortB pins as inputs. Down in the code, PortC is setup to have both LEDs as required, DDRC having all inputs, except for the LED pins PC0 and PC1, and immediately set PORTC as 0xFE, ir means, PC0 bit down will force that LED to lit immediately.

But see, PORTD has all pins outputs, except PD2, and

int main(void){
    uchar i, j;
    /* no pullups on USB and ISP pins */
    PORTD = 0;
    PORTB = 0;
    /* all outputs except PD2 = INT0 */
    DDRD = ~(1 << 2);

    /* output SE0 for USB reset */
    DDRB = ~0;
    j = 0;
    /* USB Reset by device only required on Watchdog Reset */
    while (--j) {
        i = 0;
        /* delay >10ms for USB reset */
        while (--i)
            ;
    }
    /* all USB and ISP pins inputs */
    DDRB = 0;

    /* all inputs except PC0, PC1 */
    DDRC = 0x03;
    PORTC = 0xfe;

It was easy, just inserted DDRD &= 11101011b; at the end, making pins PD2 and PD4 also as inputs. This was enough to not kill the USB traffic and after compiling and reflashing, it worked nicely.

    /* all USB and ISP pins inputs */
    DDRB = 0;
    DDRD &= 11101011b;
    /* all inputs except PC0, PC1 */
    DDRC = 0x03;
    PORTC = 0xfe;

But that will "hardwire" the pins and the possible change in configuration at the usbconfig.h will be of no sense.

Then I found at usbdrv.h (lines 530+) some #defines using the setup at usbconfig.h for port and pins to be used with USB.

#define USBOUT          USB_OUTPORT(USB_CFG_IOPORTNAME)
#define USB_PULLUP_OUT  USB_OUTPORT(USB_CFG_PULLUP_IOPORTNAME)
#define USBIN           USB_INPORT(USB_CFG_IOPORTNAME)
#define USBDDR          USB_DDRPORT(USB_CFG_IOPORTNAME)
#define USB_PULLUP_DDR  USB_DDRPORT(USB_CFG_PULLUP_IOPORTNAME)
#define USBMINUS        USB_CFG_DMINUS_BIT
#define USBPLUS         USB_CFG_DPLUS_BIT
#define USBIDLE         (1<<USB_CFG_DMINUS_BIT) /* value representing J state */
#define USBMASK         ((1<<USB_CFG_DPLUS_BIT) | (1<<USB_CFG_DMINUS_BIT))  /* mask for USB I/O bits */

Now I have the port and pins selected at usbconfig.h in form of names, so I used it. Also, included an extra LED at PortC pin 2 (PORTC.2), so changed DDRC to val 0x07 instead of 0x03 as default.

    /* all USB and ISP pins inputs */
    USBDDR = ~USBMASK;
    /* confirm INT0 DDRD.2 as INPUT no matter what was setup at usbconfig.h */
    DDRD &= 0xFB;
    /* all inputs except PC0, PC1 */
    DDRC = 0x07;
    PORTC = 0xfe;

Now everything works fine. Sent and email to Thomas about this, no answer.

THIRD LED = WRITING FLASH/EEPROM/FUSES

Okay, now to include the third LED to lit when the programmer is programming Flash, Eeprom and Fuses. I thought that was easy. It is not. First I include the ledYellowOn() and ledYellowOff() macros at the end of usbasp.h, along with the already existent macros for Red and Green LEds. As already defined at main.c, Yellow Led will be connected at PortC bit 2:

/* macros for gpio functions */
#define ledRedOn()    PORTC &= ~(1 << PC1)
#define ledRedOff()   PORTC |= (1 << PC1)
#define ledGreenOn()  PORTC &= ~(1 << PC0)
#define ledGreenOff() PORTC |= (1 << PC0)

#define ledYellowOn()  PORTC &= ~(1 << PC2)
#define ledYellowOff() PORTC |= (1 << PC2)

Now I need to insert those On/Off macros for the Yellow LED somewhere in the code to turn on the LED while programming Flash/Eeprom and Fuses.

Found in main.c and isp.c some functions and routines with suggestive names as

uchar ispReadFlash(unsigned long address)
uchar ispWriteFlash(unsigned long address, uchar data, uchar pollmode)
uchar ispFlushPage(unsigned long address, uchar pollvalue)
uchar ispReadEEPROM(unsigned int address)
uchar ispWriteEEPROM(unsigned int address, uchar data)

The ispWriteFlash() and ispWriteEeprom() were perfect to insert the ledYellowOn(), so I did it, for my dismay, it didn't work, at all. I tested the ledYellowOn() and ledYellowOff() macros in the main.c where they lit the other LED on/off, and the yellow worked along, so the LED connection, PortC.2 and macro were working nice.

The problem is within the ispWritexxx() routines, they are not executing the macro. I even disassembled the main.hex, search for those routines, and found the hexadecimal code for the instruction CBI PORTC,0x02 in there, but the LED still off all the time, no matter how many other AVR I was reading/writting after flashing that AtMega48 on board of the jumpberboard acting as a programmer.

You can imagine how many times I shuffled USB cables between PC USB port and one or another programmer, wait the windows driver to kick in, switching flat 10 wires cables between programmers, kick in the flashing of this AVR or the ISP operations to the third AVR by this jumperboard AVR serving as a programmer. It took a long time to figure out what was happening. I needed to test the ledYellowOn() macro in all routines, and find out which lit the LED and which does not. Then I realize only the basic routines lit the LED, such as

ispConnect()
ispDisconnect()
ispTransmit_hw(uchar send_byte) 
ispTransmit_sw(uchar send_byte)
uchar ispEnterProgrammingMode()

but none of the relatives to read/write flash, eeprom, lit the LED.

Okay, okay, JTAG exists for a reason, I had them, but I thought I would find the problem soon.

Why the ispWriteFlash() is not executing the CBI PORTC, instruction? How the routine code is running, writing the flash, without doing the CBI instruction? No hints, until last night, when I thought about the only possible and simple explanation.

If the ispWriteFlash() and ispWriteEeprom() routines are not executing the CBI, probably they are not running at all.

But how it writes the flash and eeprom? The explanation was simple; Those routines are never being called. All the ISP control bytes to be sent to the target AVR is comming directly from the PC windows software, and being transferred directly to the target AVR via this USBasp programmer, acting as a dumb stupid interface. Nothing fancy or astonishing is being done in this contraption. All the AVR+USBasp is doing, is just receiving the bytes from the PC via USB, and transmitting to the target AVR via the ISP internal circuit, via OUT SPDR, Byte instruction, if the ISP speed is higher than 93.75kbps, lower than that it does bit-bang for slow pace. The only really fancy job this AVR+USBasp is doing, is just preparing the target AVR for the ISP programming, like dropping RESET (PB.2), doing some extra SCK pulse when necessary, sending the initial 0xAC + 0x53 + 0x00 + 0x00 bytes to the AVR to make it enter programming mode, etc., but nothing else.

To prove this theory, I just slashed all those read/write Flash and Eeprom routines from ISP.C and MAIN.C, compiled, flashed and it still working, with USBasp code size reduced. Everything is being sent by the windows application. AVRDUDE and KHAZAMA does not send any special command to the USBasp to initialize the target AVR with read/write flash or eeprom code, they do the dirty job themselves. I understand that USBasp is written to allow a "smart" windows software to use its inteligence in firmware, but I think they don't trust it and choose to do it themselves. I didn't test BASCOM nor eXtreme Burner.

So, now I am creating a little piece of code to capture bytes sent by the windows application into a small "n" bytes buffer, right after the ispConnect() and analyze it to concluded it is a write flash or write eeprom, if positive then will run the macro ledYellowOn() and lit the Write Flash yellow LED.

For a while I made a trap at the ispTransmit() routine, checking for a byte equals to 0xC0, and if found lit the LED. Apparently such byte value is most used among writings than commands to read. WriteEeprom uses such command byte, but it is not rare to find 0xC0 in middle of a code being writting to the flash memory. It works, but I want to make it better.

__________________
Wagner Lipnharski
Orlando Florida USA

Wagner Lipnharski
Orlando Florida USA

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'll move this to Tutorial Forum - it looks very useful.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use USBASP myself.
One of the problems is that the project has never been quite finished.
It was meant to include serial interface to target and the connections RX and TX are shown on the circuit but the firmware has never been developed.
It is quite possible to do with V-USB in a separate dongle.
Including this would bring USBASP up to the best in world standard programmers.

As you are getting an in depth knowledge how about finishing the project off yourself?

John

If all else fails, read the instructions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello John, I am willing to keep playing with USBasp, since I am understanding it more and more everyday.

As an example, I already was able to include the third LED that only lights with programming the Flash or EEprom, it was quite simple to do, after I was able to understand how that part of the program works.

There is a 4 bytes buffer, as data[n], since the ISP commands and data traffic is done in 4 bytes packets, always. Checking for the command byte, that is always at the data[2], I was able to know when a write command was issued by the program at the PC. And believe me, no program that I tested is using the internal USBasp's functions of read/write/etc. All of them send the commands directly for the USBasp work as a simples bridge, interface that does a very simple and not so smart job.

I also found few not yet discovered bugs in the latest Fischl's version 2011.

1) When the unit is using low speed communication, doing the bit-bang internally, the SCK line is pulsed at the wrong time. It is 180 degrees out of pace. It causes communication problems, repetitions, low speed throughput, etc. The raise of the clock pulse must happen in the middle of the period of data (MOSI). The correct is like this:

a) set data bit on MOSI,
b) wait half bit time,
c) raise SCK,
d) read target's MISO line and deserialize to a byte.
e) wait half bit time,
f) drop SCK
g) repeat this for the other 7 remaining data bits.

The Fischl versions are setting SCK at the wrong time, look at the waiting half bit time above and compare below. Items (b) and (d) above are in the wrong place (time) below.

a) set data bit on MOSI,
b) read target's MISO and deserialize to a byte,
b) raise SCK,
c) wait half bit time,
d) drop SCK
e) wait half bit time,
f) repeat this for the other 7 remaining data bits.

Note that the SCK raise didn't wait half bit time, so the SCK raises fast, few nanoseconds after the data is set on MOSI, sometimes MOSI is not settled yet, what causes the trouble. The ISP rules is clear about those timmings. When using speeds of clock/64 (93.75kbps) or higher, the transmit and receive control (MOSI and SCK) is given to the AVR ISP circuit, and it does that correctly.

The USBasp code has a counter of 32 attempts in case of communication problem with the target. I mean, it has 32 chances to do it right, and believe me, my protocol analyzer did show several repetitions while communicating. The user doesn't know that, but it happens.

Also, there are some glitches in the MOSI and RESET, at the initialization time, that is strange. Reset is asserted twice before sending 0xAC 0x53 (connection), that is strange and not recommended.

I also found out, that is IMPERATIVE to use very short cables, the USB and the parallel ISP cable between the USBasp and the target. Long cables are prone to pickup electrical noise and interferences and cause repetitions. You can make a test with Khazama's PC software. Set the speed to 750kbps (if the target is running with 6MHz crystal or more)... in some cases it takes longer to read the flash memory than if you use 93.75kbps... This extra delays are caused by repetitions. Using short cables it is avoided.

I fixed that in my testing units, will post the changes here later this month.

Using my protocol analyzer, I found that Khazama PC program forces the reading of the last 4 bytes of eeprom immediately after reading device's signature. That is strange, Khazama probably is doing that for when reading other (not AVR) device's information from eeprom, but it is not documented on Khazama program.

Also, I found that the existent cheap chinese USBasp on sale at eBay, that adjusts ISP speed automatically according to the success of communication, does not accept the Set Speed command send by the PC program, it simply ignores it, and causes Khazama (for example) to post a message of error in clock speed setup, requiring you to click [OK] at the popup error message screen all the time. The chinese wrote the routine for auto-speed, but forgot to answer the usual speed setup command received from the PC. Hump! If the chinese only published their firmware files, we could fix it. If Khazama read his emails, he could fix it.

Also, I was able to install a bootloader in the USBasp programmers running with AtMega8 uC, but not Fischl's bootloader. I installed another one, the bootloadhid version. It also uses a neat and 100% working PC software to download the update of the regular program to the AtMega, even testing versions of USBasp, much better and faster than using a second programmer to program the one under testing.

http://www.obdev.at/products/vus...

Is uses the Tool (PC software) from Mario Steiner to do the download when the programmer is under control of the bootloader, neat:

http://vusb.wikidot.com/project:...

This speeds up all the testing of new versions of USBasp, including downloading any other programs (not even related to the USBasp) to the programmer and use it as a development platform.

Can you explain please, in what situations, or what kind of operations or PC software, you would use the serial interface (RX and TX) in the USBasp? It is not that difficult to implement it, once the intentions or operations is stated.

Cheers,

Wagner Lipnharski
Orlando Florida USA

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Can you explain please, in what situations, or what kind of operations or PC software, you would use the serial interface (RX and TX) in the USBasp? It is not that difficult to implement it, once the intentions or operations is stated.

I certainly can.

Serial comunication chip to PC is used after the chip has been programmed and the chip is running.
Values of variables can be read out on the PC.
Text messages can be sent to the PC.
A terminal program is used at the PC side.
Typically Hyperterminal for windows and Minicom for Linux.

At the moment I use USBASP to program the chip and a separate dongle for communication.

John

If all else fails, read the instructions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey John, I got it.

You are talking about using the USBasp hardware & firmware to provide Serial Communication capability as a simply assynchronous communication interface, between the PC and the Target. Exactly what a dirty FT232 or CP2102 would do. You are not talking about using RX and TX during chip programming or something like that.

For that double application of the USBasp hw+sw, lets give names for the things:

1) The USBasp ISP programming firmware module, the one we have today.

2) The USBasp serial interface, emulating a CP2102 or FT232 chip, creating an assynchronous communication between PC and the target, for multi and general use.

3) The actual hardware board, used as a programmer, usually with a simply AtMega48, AtMega8, AtMega88, with the actual firmware from Fischl.

For what I think initially (there are other solutions, with more time expenses to develop), is to move the item [1], programmer firmware, to the bootloader are of the AVR [3], and install another firmware at the regular low address area of the [3].

Requirements:

a) Hardware: The [3] board should use a minimum of 8 kBytes of flash, it could not be a AtMega48, needs to be an AtMega8, 88 or higher. Most of the units being sold at eBay, as today, uses an AtMega8, in bulk they cost few cents more than the 48, the chinese are not stupid, they install a better unit. Also, one must construct by himself the RX and TX connections from the [3] board, even at expense to deal with very tinny AVR pins on the SMD packages.

b) More Hardware updates: Perhaps the chinese would notice that and include a sequential 7 holes in the little board, with Ground, VCC, TX, RX, space, PinD.7 and Ground again, so the user could solder 4 bar pins for the serial communication, plus two pins for the selection jumper, or solder wires for the target board. By doing that, the selection of programmer or serial interface could be done at target's board. Neat.

c) Fuses: The AVR fuses should be changed in order to jump to the bootloader area upon reset, and first run the [1] firmware.

d) The new [1] firmware in the bootloader area: It must be changed somehow to read an unused port pin, lets say PORTD.7 or PORTC.4, and see if it is shorted to ground (a switch or a jumper). If the pin is down, then they jump back to the [2] area and execute the serial interface firmware, and stays there until a new power cycle is applied to the unit. If the jumper is not there, then they still running the modified [1] firmware, and the unit will behaves as a Fischl programmer until the next power cycle.

How is this sound? good?

For a more inteligent approach, I would suggest modify the actual [1] firmware to do both things, upon a jumper selection on board, no needing to use the bootloader solution. By doing that, [1] and [3] will do a single enumeration with Windows USB upon insertion at the USB port, but the application on Windows might be one or another, ISP programming or serial port emulation. I don't know if they could use the same USB unit without power cycling it at the USB port. I don't understand (yet) this area very well, need to research more. Initially I think it is possible, since I could use two different USBasp programmer softwares at the PC, side by side, for example, AVRDUDE and Khazama programs. I can read flash with Khazama and seconds later write a new flash code with AVRDUDE.

Wagner Lipnharski
Orlando Florida USA

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes that is correct.
Use USBASP instead of FT232.
This has always been a TODO on the USBASP project.
From the USBASP web page:-

Quote:
•Planned: serial interface to target (e.g. for debugging).

John

If all else fails, read the instructions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Am I understanding that, for the simple purpose of programming the target chip, that the USBasp firmware doesn't really do anything? That its all done on the software side?

If that's the case, there's an interesting learning tool to be gained. Can we produce a simplest-case ISP programmer schematic and firmware? Ie. what is the MINIMUM hardware and code necessary to interface target and PC for successful programming?

Sorry if that's off-topic. I just think it would be extremely useful for beginners (like me) to build a simple tool and compile simple firmware without having all the extraneous and magical code and connections (if its useless).

For example, I found this thread because I found myself staring at the USBasp schematics wondering what the heck purpose PD0 and PD1 could possibly have. And in terms of programming... it appears they don't have any purpose. So that's a) confusion, b) a waste of a perfectly good resistor (in the scope of basic learning of pc/target ISP programming interface).

- Steven

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Am I understanding that, for the simple purpose of programming the target chip, that the USBasp firmware doesn't really do anything? That its all done on the software side?

USBtinyISP (close cousin) was designed for cost reasons to live in a tiny2313. In a 2K chip without USB hardware there isn't very much room to do anything but the USB software simulation (I think it had 4 bytes free in the end) so this meant that all the "smarts" had to be done at the PC side and nothing but SPI wire wiggling was left for the AVR side of things.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The USBasp firmware is relatively intelligent.

All the same, most Atmel programmers work on the basis of being simple. i.e. let the controlling software do most of the work.

The minimum hardware is an LPT dongle.
The next simple is a "ponyser" dongle.

Quite honestly, you might just as well splash out $3.99 for a Chines usbasp. It will be faster and more reliable.

If you are not tight, buy a real AVRISP-2 or Dragon.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

David, if you were responding to me... you missed the point. It has nothing to do with cost, but rather education. Put yourself in the shoes of someone just starting out that knows nothing about AVR programming but wants to learn. Building a simple programmer is a very useful exercise. But throwing together the hardware without understanding "why" and then flashing a hex file onto it serves no purpose. That's why... when I read this thread and saw that perhaps it could be done a lot simpler than the it is... I wondered if we could strip it down to its most bare (but not so bare that it becomes an encumbrance in today's world... ie, it should be USB) basics and built up from there. As a useful and practical learning exercise.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Many programmers are open-source.

I feel that you need to use tools you can rely on. i.e. not home-made.

Of course you can always read and modify the open- source code for your own purposes (and education).

Just write and run a regular SPI application. The AVR in RESET is just a regular SPI device.

Send it the SPI commands as documented in the data sheet. It will do exactly what it says on the tin.

The PC side is relatively complicated. The AVR is simple SPI. I am happy with say the usbasp firmware. Avrdude on multiple platforms is a different can of worms.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You're not understanding what I'm getting at. A beginner would have no clue what you just said.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A beginner would not attempt a USB application ----- ever.

A beginner who has mastered blinky, UART, SPI etc can send simple SPI commands and display the response on the UART.

However the beginner cannot even do a blinky until she has got a working reliable ISP programmer.

IMHO, you start with the factory made programmer.
Then make your own version when you have the experience. (if that is what appeals to you)

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your first statement is 100% untrue. I'm sure you've been doing this a long time, but for the purposes of determining what a beginner may or may not do... you have to check YOUR preconceptions at the door. I am a beginner and I am wanting to do just that.

USB is familar to everyone. I find it silly, really, that the only "beginner" programmer tutorials I can find are related to a parallel port. A what now? Yes, I know what it is... no I haven't had a pc in a decade with one.

You're third paragraph is also wrong. There are plenty of chips with built-in USB bootloader space.

Anyway, again you miss the point. Its about learning, not about whether or not the tool you build works reliably in future siturations (although that just presents more opportunity to learn). I have 3 "factory made" programmers... that's not the point. The point is, they all have a bunch of code in them and hardware on them and I don't know why. And your answer to the beginner is, "Just write and run a regular SPI application." OK... so I open up Word, I type in "regular SPI application" and then I yell at the screen, "run program, RUN". The point was to construct a very basic tutorial, not gloss over everything that's considered "basic" to trivialize the concept purely to express that you know what YOU are doing already.

Forget I mentioned it... i was off-topic enough.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I am a beginner and I am wanting to do just that.

Buit surely David's point is that the last thing a beginner wants is some half-baked, unreliable programming tool that completely spoils their first AVR experience. Sure set an ISP programmer as your first major AVR project (Dean did and look where that's got him!) but make sure you have a reliable, well built, tried and tested ISP programmer already to do the work.

About 5-10% of threads here are about people having all kinds of problems with ISP, often with "home brew". they get seriously peeved when they are just starting out. Thankfully the replacement of serial/parallel with the one choice of USB is putting paid to that now as most people could not home berw a USB programmer (well not as a 1st project anyway!).

At least that's how I read it. YMMV.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, I realize that was his point. And that's why I said he missed mine.

I don't think I ever said, or even hinted, that this proposed tutorial-born programmer would be the programmer the student would use for other projects (though that could certainly be a goal of the student). But saying that the student should forget making his programmer and instead buy one... holy crap, what's the point then? Pick any project. ANY project. "Don't make your own half-baked robot when you can just buy a factory made one". What's the difference?

Look, I'd get it if instead of AVR programming hopefuls, we were talking about writers... and I said "hey, start by making your own pencil". Because then the pencil - a necessary tool for the job - isn't itself part of the skill the student is hoping to learn (ie. woodworking vs writing). But in this case, the AVR programmer is itself an AVR device so the project is directly related to the skill. Buying a programmer and magically transferring a pre-built hex file to an AVR on a circuit you meticulously put together by looking at an unexplained schematic... what's that achieve really?

I'm sure someday - if I ever get ANYWHERE in learning this craft (which I can't seem to do since nobody ever answers my questions straight and ALL "beginner" tutorials contain more jargon and acronyms than a bathroom stall) - I'm sure I'll look back at this and wonder how I ever knew so little. But from the perspective of where I am now... I think there'd be a lot to gain from what I was proposing.

And while I call myself a "beginner", I shutter at how the truly uninformed must feel when trying to learn. While my background is in business, I have myself had hands-on experience with hundreds of microcontroller based products (mostly PIC) and I have a programming background and I *STILL* struggle because everything glosses over the fundamentals like David.

Colour me frustrated. My last post should have been my last post, but now this one is. I'm unsubscribed so don't mind my not responding from here on.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
For example, I found this thread because I found myself staring at the USBasp schematics wondering what the heck purpose PD0 and PD1 could possibly have.

Exactly
They have no purpose because the software to use them has never been writen. Like a lot a open source projects it needs finishing off. Possibly someone new to pick it up and finish it off. That is what my posts are about.

John

If all else fails, read the instructions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hi, a noob question: should Usbasp to be plugged into pc usb port to be reprogrammed by another programmer? So as to be powered by USB port 5Vcc?
thx

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That surely depends on what that "another programmer" is and whether it provides power to the circuit it is programming.

(BTW your question is off-topic for this thread - discussion should be reserved solely for feedback about the text of the first post)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
That surely depends on what that "another programmer" is and whether it provides power to the circuit it is programming.
)

it is a simple "parallel port programmer"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't know why Thomas Fischl has implemented SCK clock reduction via JP3?!

I asked him but hi didn't replied.

So I do the job in dirty way:

if(replyBuffer[0]) {
			ispSetSCKOption(USBASP_ISP_SCK_8);
			ispConnect();
			replyBuffer[0] = ispEnterProgrammingMode();
		}

Download main.c from http://github.com/Electronic-Pro...

Also I've posted a topic for it, maybe it's better to merge that with this one.

And about Khazama software, it is GUI for AVRDUDE which is embedded in its executable.

For GUI I use PROGISP 1.72 from Chinese company zhifengsoft.com.

پروژه الکترونیک میکروکنترلر اتوماسیون صنعتی ARM AVR LPC STM32 dsPIC 8051

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But you can lower the clock with -B in avrdude since a long time ago

The usbasp ChangLog wrote:
usbasp.2009-02-28 (v1.3)
------------------------
- added support for software control of ISP speed (based on patch by Jurgis Brigmanis)
Or are you talking about something else?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

snigelen wrote:
But you can lower the clock with -B in avrdude since a long time agoپروژه هاي الکترونيک کنترل مانيتورينگ اتوماسيون صنعتي ارایه انواع پروژه هاي صنعتي آزمايشگاهي دانشگاهي تحقيقاتي automasys.wordpress.com انواع میکروکنترلرهاي میکروچيپ اتمل اينتل فيليپس AVR ARM LPC STM32 PIC dsPIC 8051 8086 z80 انواع اينترفيس و پروتکل هاARM AVR PIC MicroController Electronic Project GPRS GSM USB BlueTooth Ethernet Network CAN I2C SPI RS485 Automation PLC پروژه الکترونيک میکروکنترلر آرم 8051 اتمل فيليپس میکروچيپ Interface اينترفيس ويژوال استاديو Visual Studio 2010 C# VB.Net Protel DXP Altium Eagle PCB SPICE PSPICE HSPICE ADS OrCAD Silvaco
The usbasp ChangLog wrote:
usbasp.2009-02-28 (v1.3)
------------------------
- added support for software control of ISP speed (based on patch by Jurgis Brigmanis)
Or are you talking about something else?

With that piece of code, there is no need to JP3 nor -B!

It's done automatically by USBasp.

When some newbies want to program a new chip (with built-in 1MHz crystal oscillator) they don't know they must set JP3 or use -B and think the micro/programmer is unusable.

Also some GUIs does not support this option or it may be annoying.

So the USBasp tries to communicate with the chip,
if there is no response it lowers its clock automatically and do the job again.

پروژه الکترونیک میکروکنترلر اتوماسیون صنعتی ARM AVR LPC STM32 dsPIC 8051

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello wagnerlip, We are group of two newbies came across http://www.avrfreaks.net/index.php?name ... p;p=927971 and we learnt a lot from your experience.we need your help here,we are making an AVR development board
(you can find the manual from here https://code.google.com/p/uniboard/wiki/Documentation ) with onboard programmer (as atmega Cool. We are stuck in a place- whether this onboard programmer IC ( atmega 8 )needs any dedicated program to do its work as programmer IC or Is the USBasp (2011)Firmware is enough to do its work??.
USB asp2011 Firmware: http://www.fischl.de/usbasp/

Its very urgent for us to complete this project,hope you help us and Thanks a lot in advance for your help and further suggestions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So, is there any implementation of the TX and RX as a usb to serial interface? I'm interested in one that can be used on the fly without need to reprogram the chip or to disconnect the usb.

 

Thanks,

Dusan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

wagnerlip wrote:

So, now I am creating a little piece of code to capture bytes sent by the windows application into a small "n" bytes buffer, right after the ispConnect() and analyze it to concluded it is a write flash or write eeprom, if positive then will run the macro ledYellowOn() and lit the Write Flash yellow LED.

For a while I made a trap at the ispTransmit() routine, checking for a byte equals to 0xC0, and if found lit the LED. Apparently such byte value is most used among writings than commands to read. WriteEeprom uses such command byte, but it is not rare to find 0xC0 in middle of a code being writting to the flash memory. It works, but I want to make it better.

 

Would you mind writing that piece of code here?

Thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi. Any update about the serial interface?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, I know this thread is 5 years old, but I think it's still interesting enough to talk about USBASP.

 

I accidentally found this thread while googling for prog_blockflags inside USBASP firmware and found this interesting post from wagnerlip

I know maybe he don't even look at this nowadays but maybe usefull for others.

 

wagnerlip wrote:
If the ispWriteFlash() and ispWriteEeprom() routines are not executing the CBI, probably they are not running at all.
 

 

They did run if we call them.

 

 

wagnerlip wrote:
But how it writes the flash and eeprom? The explanation was simple; Those routines are never being called. All the ISP control bytes to be sent to the target AVR is comming directly from the PC windows software, and being transferred directly to the target AVR via this USBasp programmer, acting as a dumb stupid interface. Nothing fancy or astonishing is being done in this contraption.
 

 

If it's true, then PC software must be use this all in one function:

} else if (data[1] == USBASP_FUNC_TRANSMIT) {
		replyBuffer[0] = ispTransmit(data[2]);
		replyBuffer[1] = ispTransmit(data[3]);
		replyBuffer[2] = ispTransmit(data[4]);
		replyBuffer[3] = ispTransmit(data[5]);
		len = 4;
}

If they did use above function, those PC software had to do so many USB transaction, ex. for 128 bytes page will be done in 128 USB transaction. fhew.

 

I tried  ispWriteFlash() and ispWriteEeprom()  and it can writes flash (128 bytes page) or eeprom in just a single transaction.

With 128 transaction there be 16384 bytes transfered smiley

Wonder why they didn't use those function.

 

 

wagnerlip wrote:
The ispWriteFlash() and ispWriteEeprom() were perfect to insert the ledYellowOn(), so I did it, for my dismay, it didn't work, at all. I tested the ledYellowOn() and ledYellowOff() macros in the main.c where they lit the other LED on/off, and the yellow worked along, so the LED connection, PortC.2 and macro were working nice. The problem is within the ispWritexxx() routines, they are not executing the macro. I even disassembled the main.hex, search for those routines, and found the hexadecimal code for the instruction CBI PORTC,0x02 in there, but the LED still off all the time, no matter how many other AVR I was reading/writting after flashing that AtMega48 on board of the jumpberboard acting as a programmer.

 

As USB transaction is very too fast for human eye, the LED seems to be on or off, but actually it blink so fast so we can't see it.

I proved that using toggling.

PORTC ^= (1<<0)

It blinks but still too fast. But my eye still can catch the blink. (the scope shows better pulse reading cheeky)

 

 

wagnerlip wrote:
I was able to know when a write command was issued by the program at the PC. And believe me, no program that I tested is using the internal USBasp's functions of read/write/etc.
 

 

All those function are fully functional actually, guess they prefer with only this:

} else if (data[1] == USBASP_FUNC_TRANSMIT) {
		replyBuffer[0] = ispTransmit(data[2]);
		replyBuffer[1] = ispTransmit(data[3]);
		replyBuffer[2] = ispTransmit(data[4]);
		replyBuffer[3] = ispTransmit(data[5]);
		len = 4;
}

 

wagnerlip wrote:
All of them send the commands directly for the USBasp work as a simples bridge, interface that does a very simple and not so smart job.

 

And so other programmers do, including LUFA laugh ,if you add multi function like USBASP_FUNC_TRANSMIT.

 

 

I wonder if he still working with VUSB or move to LUFA.

 

 

MiGy 

 

 

 

 

I don't know why I'm still doing this hobby