ISP Prigramming from AVR Studio 3.2

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

I have down loaded and installed AVR studio 3.2 on my win 95 PC.

I have designed a PCB with an AT90S8535-8AC CPU on it and a 10 pin headder for in system programming.

Can some one tell me whether AVR studio 3.2 expects the programmer to be on the serial or the parallel port and where I can get a schematic for the interconnecting cable / device to go between the PC and the Atmel CPU for in system programming.

admin's test signature
 

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

Hi Frank,

The AVR Studio expects its programmer to be on the serial port. I have a notion that you're visualizing something like the Kanda ISP dongle to connect directly to your target AVR device. For this, the AVRprog software will support the ISP programming cable described in the application note AVR910 in the Tools section of this website.

Best regards,

Morten, AVR tech. support, Atmel FAE

admin's test signature
 

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

Thank you for prompt response clarifying the port used and pointing me to a schematic which I have down loaded.

Here are a few follow on questions:-

I have noticed that a number of people have come up with ways of using the parallel port to program the atmet CPUs. One solution I have seen just uses 3 resistors and another solution uses a 74HC244. These solutions are obviously simpler and cheaper. Tthe 3 resistor solution could be implemented by putting the resistors on the PCB. This makes for an easier and cheaper way of implementing a system that includes field up gradability as the person doing the upgrade only needs to make a cable so allowing the software file to be sent by email.

So is there a risk in using these parallel port programming methods? (What is the down side to the parallel port programmers?)

Why has Atmel gone for a more complicated approach using a CPU in the dongle.

Can AVR Studio 3.2 access the parallel port programmers and if not, what is the chance of including that functionality in the next version of AVR studio.

Regards, Frank

admin's test signature
 

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

Hi Frank,

I figure that the 74HC244 way of doing things, offers a degree of protection for your parallel port.
Take this buffer chip away and put the interface job in the hands of an electronics novice and you run the risk of having to say goodbye to your parallel port.
If the parallel port is an integral part of your PC's motherboard then you can have a costly repair job on your hands.
A cheap parallel port PCI card is a good investment for experimenters, so you don't have to go near your motherboard's parallel port.

>So is there a risk in using these parallel port programming >methods? (What is the down side to the parallel port >programmers?)

Cheers Jack

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

Hi Jack,

The STK500 interface and all future Atmel interfaces are made avoiding the parallel port. This is because this port is "hard to drive" in Windows and because the parallel cables are prone to picking up noise (ask anyone who've used the STK100 about this, and they will probably confirm it or something to the effect...). There are a lot of people on this forum that know more about this than I do, so please comment if you like.

The complexity of the Kanda dongle is not something I can comment, because I don't know enough about it. Is there someone from Kanda on this forum? The interface is _not_ a parallel one, though. This might be one of the reasons.

Anyhow, Atmel is not zealous about only supporting its own protocols. I'm sure that if a valid, "juicy" protocol solution were presented to the software department (through the avr@atmel.com channel), they'd take it into consideration. If anyone out there feels like writing a comprehensive application note, please do. I'd be happy to have it considered.

Best regards,

Morten, AVR tech. support, Atmel FAE

admin's test signature
 

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

So where is the STK500 protocol then? Great that Atmel have decided that parallel port programmers are crap, but without publishing the STK500 protocol it too is crap. What is the hold up Morten? If I worked for Atmel I would be embarassed about this issue - how about some action. Give me the email address of someone at Atmel who can actually get this protocol published.

JPK

admin's test signature