AVR-Chat

HI,
I have a question:
when I sent a Long(4 bytes) variable from the PC to the AVR which 
byte is first? LSB ? MSB ?
and if a need to sent a Long from the AVR to the PC USART (with a 
Borland Delphi program) what byte is needed to be first? LSB ? MSB?

also I´m using WINAVR GCC, my LCD rutine is with printf, how can I 
set the GCC to use LCD & USART simutaneusly with printf/fdevopen ?

At 01:28 PM 14/03/2005, you wrote:

>HI,
>I have a question:
>when I sent a Long(4 bytes) variable from the PC to the AVR which
>byte is first? LSB ? MSB ?

You decide. The code for the AVR (or any other processor) has
to match the sender's protocol.

Regards

John Samperi

******************************************************
                         Ampertronics Pty. Ltd.
   11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
          Tel. (02) 9674-6495       Fax (02) 9674-8745
                Email: samperi@ampertronics.com.au
                  Website  http://www.ampertronics.com.au
* Electronic Design   * Custom Products   * Contract Assembly
******************************************************

A common practice, where a bit of inefficiency is OK, is to send numeric
information larger than a byte is its HEX-ASCII or Decimal-ASCII form,
rather than, say, 4 binary digits. That way, there are no byte-order or bit
order issues for the other end of the link to have a-priori knowledge of.

-----Original Message-----
From: John Samperi [mailto:samperi@ampertronics.com.au] 
Sent: Sunday, March 13, 2005 6:45 PM
To: AVR-Chat@yahoogroups.com
Subject: Re: [AVR-Chat] Serial format


At 01:28 PM 14/03/2005, you wrote:

>HI,
>I have a question:
>when I sent a Long(4 bytes) variable from the PC to the AVR which
>byte is first? LSB ? MSB ?

You decide. The code for the AVR (or any other processor) has
to match the sender's protocol.

Regards

John Samperi

******************************************************
                         Ampertronics Pty. Ltd.
   11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
          Tel. (02) 9674-6495       Fax (02) 9674-8745
                Email: samperi@ampertronics.com.au
                  Website  http://www.ampertronics.com.au
* Electronic Design   * Custom Products   * Contract Assembly
******************************************************




 
Yahoo! Groups Links

sorry I´m having problems because I´m sending a Long(4 bytes) from 
the PC serial port to the AVR and when I sent back the 4 Bytes its 
seem to be in reverse order!.
Is the PC serial format LSB first and the AVR MSB first?
 




--- In AVR-Chat@yahoogroups.com, John Samperi <samperi@a...> wrote:

> At 01:28 PM 14/03/2005, you wrote:
> 
> >HI,
> >I have a question:
> >when I sent a Long(4 bytes) variable from the PC to the AVR which
> >byte is first? LSB ? MSB ?
> 
> You decide. The code for the AVR (or any other processor) has
> to match the sender's protocol.
> 
> Regards
> 
> John Samperi
> 
> ******************************************************
>                          Ampertronics Pty. Ltd.
>    11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
>           Tel. (02) 9674-6495       Fax (02) 9674-8745
>                 Email: samperi@a...
>                   Website  http://www.ampertronics.com.au
> * Electronic Design   * Custom Products   * Contract Assembly
> ******************************************************

At 12:12 PM 3/14/2005, fjch100 wrote:


>sorry I´m having problems because I´m sending a Long(4 bytes) from
>the PC serial port to the AVR and when I sent back the 4 Bytes its
>seem to be in reverse order!.
>Is the PC serial format LSB first and the AVR MSB first?
>

It all depends on the program in the PC. There isn't a definite order to 
things this way.

When you pick up the 4 byte value you start from the first address 
of the array of bytes.  So, this gets to the concept of 'endian'.  
In a 'little endian' architecture the low order byte will be stored 
first followed at higher addresses by higher order bytes.  In 
the 'big endian' architecture the high order byte is stored first.

The thing is, since the AVR doesn't really deal with 4 byte values 
in hardware, it doesn't know or care about endian.  The compiler, in 
this case, makes the decision of how it wants to store the data.

On the PC, I believe the order will be little endian but even there, 
the compiler can change the order.

You can determine the byte order within the long value by using a 
union to overlay a 4 byte array on top of a long variable.  Put a 
long value in the data element and then look at the bytes from low 
to high.  Or check the compiler documentation - search for 'endian'.

Something like:

union test {
    long lval;  /* whatever type has 4 bytes */
    char cval(4);
} t;

t.lval = 0x76543210;

printf("%x\n",t.lval);
printf("%x %x %x %x\n",t.cval(0),t.cval(1),t.cval(2),t.cval(3));

You will have to work out the details.

--- In AVR-Chat@yahoogroups.com, "fjch100" <fjch100@c...> wrote:
> 
> sorry I´m having problems because I´m sending a Long(4 bytes) from 
> the PC serial port to the AVR and when I sent back the 4 Bytes its 
> seem to be in reverse order!.
> Is the PC serial format LSB first and the AVR MSB first?
>  
> 
> 
> 
> 
> --- In AVR-Chat@yahoogroups.com, John Samperi <samperi@a...> wrote:
> > At 01:28 PM 14/03/2005, you wrote:
> > 
> > >HI,
> > >I have a question:
> > >when I sent a Long(4 bytes) variable from the PC to the AVR 
which

> > >byte is first? LSB ? MSB ?
> > 
> > You decide. The code for the AVR (or any other processor) has
> > to match the sender's protocol.
> > 
> > Regards
> > 
> > John Samperi
> > 
> > ******************************************************
> >                          Ampertronics Pty. Ltd.
> >    11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
> >           Tel. (02) 9674-6495       Fax (02) 9674-8745
> >                 Email: samperi@a...
> >                   Website  http://www.ampertronics.com.au
> > * Electronic Design   * Custom Products   * Contract Assembly
> > ******************************************************

--- In AVR-Chat@yahoogroups.com, "fjch100" <fjch100@c...> wrote:
> 
> HI,
> I have a question:
> when I sent a Long(4 bytes) variable from the PC to the AVR which 
> byte is first? LSB ? MSB ?
> and if a need to sent a Long from the AVR to the PC USART (with a 
> Borland Delphi program) what byte is needed to be first? LSB ? MSB?
> 
> also I´m using WINAVR GCC, my LCD rutine is with printf, how can I 
> set the GCC to use LCD & USART simutaneusly with printf/fdevopen ?

That depends on the protocol. If you are sending a file you are 
sending binary info. I know nothing about how programs do that but I 
have written programs that an AVR sends command "B0102\r" consisting 
of 5 ASCII characters followed CR, another ASCII.

The equipment that receives this command is a Audio/Video switcher. 
The switcher is expecting the command to consist of 
A=Audio V=Video B=Both
Outport port, there are 2, 01 and 02
Input port, there are 8, 01 through 08
Carriage Return

In the above I'm switching Both, to Output 1, from Input 2.

I'm using CodeVision and the above string is stored in Flash as
flash char    S12[]="B0102\r";
When the appropriate pushbutton is pushed the above string is sent 
out the serial port. The fact that the switcher changes correctly as 
commanded proves that that string arrives at the switcher exactly as 
it is stored in Flash with the exception that the '\r' is replaced 
with a CR.

The fact that you are sending bytes may be the problem. 

Could you show us a snippet of your code?

Mike

It's delivery day, and once again, my AVR tools have all decided to go nuts.
Anyone have any ideas for preventing this garbage?

I have two AVRISPs, an STK-500, an Atmel Jtag ice, and two Olimex Jtag Ices.

I have three M128 target systems in hand. Supposed to be identical.

One is running, the other two not.  The two that don't run are fresh 
builds, after getting to my goal with the first one.
I don't dare touch the one that's running until I can trust my tools again.

I've checked everything as best I can on the new systems,  The chips are 
the same date code, same 8.00 MHz crystals, same (proper value) caps, VCC 
is in tolerance (3.0V), /Reset is pulled up with 1k.  The oscillator is 
running a rail-to-rail sinewave of the right frequency, which at least 
confirms that the CKOPT fuse has been set.

All the programmers say that they can program and verify the chip 
successfully, and that all the fuses are set right. (including M103 fuse, 
CKOPT, WD, and BOD fuses)  Sometimes they fail to verify, or read wierd 
fuse values, but they are all in agreement at the moment that everything's 
fine.

All three Jtag ices agree that they can load the program, but cannot read 
the SRAM, registers, or anything else, and cannot run, or even single-step.

The programmed targets do not run, and apparently do not even run a little. 
The init code isn't even setting up the I/O ports, which is about the first 
thing that I do after qualifying the reset, and setting up the stack.

I've rebooted everything multiple times, no help

It happens on at least four different computers, running XP Pro, and '98, 
and with old and new studio, though USB serial ports and "legacy COM1" 
(note, these are high end industrial USB serial boxen, not the $20 junk)
These are real machines with other software installed, that I actually use.

Basically, anything studio drives will pack it up at random times, for some 
random duration.


I've had this happen any number of times, and it always "goes away" after a 
while, but I REALLY CAN"T AFFORD THIS SHIT ANYMORE. (anyone sensing a high 
level of frustration here?)

At this point, I feel like taking all my AVR tools out into the parking 
lot, making a pile of them, and pounding them into sand with a splitting maul.

I love the chips, but I really despise the tools.

> All the programmers say that they can program and verify the chip
> successfully, and that all the fuses are set right. (including M103 fuse,
> CKOPT, WD, and BOD fuses)  Sometimes they fail to verify, or read wierd
> fuse values, but they are all in agreement at the moment that everything's
> fine.

And the OCDEN fuse ?

> All three Jtag ices agree that they can load the program, but cannot read
> the SRAM, registers, or anything else, and cannot run, or even 
> single-step.

See above.


/Jesper

At 07:20 AM 15/03/2005, you wrote:
>It's delivery day, and once again, my AVR tools have all decided to go nuts.
>Anyone have any ideas for preventing this garbage?

I feel your pain my friend!! As you know I struggled for more than
a year with the old ICE200 and studio 4.xx without getting any help
from Atmel, they could not replicate the VERY REAL problems I was
having. I feel that they have some serious comms problems with
studio 4 as pretty much everything misbehaves from ISP upgrade to
ICEs. I'm very fortunate that, since I put 2 more additional serial
ports in my new computer, the whole thing as been solid as a rock
for more than 2 months, there is nothing I can do to break it!!

The card has 2 com ports (com 3 and 4) and a parallel port and is made
by Sunix co ltd. Of course the ICE still misbehaves, or doesn't work
with the normal serial port on the computer....but I'm happy now.

I should get my updated PCB that uses a M64 today. It has JTAG debugging
facilities, so I'll see what disasters await me when I switch to JTAG :-(

Of course there is a certain person lurking in the background in this
forum that LOVES his JTAG ICE and Studio4.....

Regards

John Samperi

******************************************************
                         Ampertronics Pty. Ltd.
   11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
          Tel. (02) 9674-6495       Fax (02) 9674-8745
                Email: samperi@ampertronics.com.au
                  Website  http://www.ampertronics.com.au
* Electronic Design   * Custom Products   * Contract Assembly
******************************************************

At 03:57 PM 3/14/2005, Jesper Hansen wrote:


> > All the programmers say that they can program and verify the chip
> > successfully, and that all the fuses are set right. (including M103 fuse,
> > CKOPT, WD, and BOD fuses)  Sometimes they fail to verify, or read wierd
> > fuse values, but they are all in agreement at the moment that everything's
> > fine.
>
>And the OCDEN fuse ?
>
> > All three Jtag ices agree that they can load the program, but cannot read
> > the SRAM, registers, or anything else, and cannot run, or even
> > single-step.
>
>See above.

Enabled.

Also wouldn't explain the total failure to run the program independently of 
the ice.

>
>Of course there is a certain person lurking in the background in this
>forum that LOVES his JTAG ICE and Studio4.....

I love mine when it works.

When it actually talks to studio through any sort of serial port.
When it actually loads the chip.
When it doesn't skip instructions in single-step.
When it doesn't invent breakpoints that don't exist.
and the list goes on...

>> > All the programmers say that they can program and verify the chip
>> > successfully, and that all the fuses are set right. (including M103 
>> > fuse,
>> > CKOPT, WD, and BOD fuses)  Sometimes they fail to verify, or read wierd
>> > fuse values, but they are all in agreement at the moment that 
>> > everything's
>> > fine.
>>
>>And the OCDEN fuse ?
>>
>> > All three Jtag ices agree that they can load the program, but cannot 
>> > read
>> > the SRAM, registers, or anything else, and cannot run, or even
>> > single-step.
>>
>>See above.
>
> Enabled.
>
> Also wouldn't explain the total failure to run the program independently 
> of
> the ice.

True.
I just remembered I had a similar problem some time ago. I programmed the 
chip
but it didn't run. I verified the code, recompiled, programmed, verified - 
nothing
worked. After trying variants of this for a while, and pulling a decent 
amount of
hair, it turned out to be a problem with the code. Can't remember exactly 
what,
but the tools were actually working perfectly all the time.
As you can program and verify, and the fuses looks good, what else is left 
but
a code problem.
Try read out the code from the working board and program that on the other 
two.

Also, another trap is that setting the wrong CPU type with the STK-500 
programmer,
will NOT hold back programming or notify you in any way. Been there, tried 
that.

/Jesper

>
>Try read out the code from the working board and program that on the other
>two.

I'll try it, but I didn't touch that code since it was put in the working 
board.

>Also, another trap is that setting the wrong CPU type with the STK-500
>programmer,
>will NOT hold back programming or notify you in any way. Been there, tried
>that.

Not a problem, but a good suggestion..
Yes, I also love the helpful messages that tell you an ERROR has occurred.
Nothing USEFUL about debugging it, just that SOMETHING went wrong.

>
>As you can program and verify, and the fuses looks good, what else is left
>but a code problem.
>Try read out the code from the working board and program that on the other
>two.

The AVRISP that I tired first had an ERROR and couldn't read the chip.
Mulltiple tries, restarts etc.
The Jtag is reading it.

Hex looks sane, got an int vector table, and some code anyway.

Switched boards, could NOT program the target with the same Jtag that 
pulled the program from the working board.
So, I switched to the AVRISP, which is now programming the board that the 
Jtag wouldn't.

Well, that was short lived, it had an ERROR while programming.

I really wish I had some information beyond "IT DIDNT WORK." when it fails.

MSGTAG has notified the sender that you have read this message.

At 05:50 PM 3/14/2005, Ivan Vernot wrote:
>Hi David,
>Not sure if any of this will solve it but a few things to try (in no
>particular order)
>1. Copy the code from the running micro into the units that don't run. to
>prove that the h/w of the two units is ACTUALLY ok.

I'd love to be able to do that, but I can't..
I was, after some greif, able to pull the hex out of the working unit, and 
it looks sane to me in notepad.
However, at this point, I am unable to get the same unit that I used to 
pull the software out of the working board, into the suspect 
board.  Another unit (see prev message) claims to program but has a verify 
error.
Both of these programmed and verified earlier today.

I've also checked the AVRISPs and Jtag ices on known good systems (AVR 
production products) and they are NFG.

>2. Double (triple) check the Fuse bits on the working and non working
>units - especially OCDEN , the brownout detect bits and the clock fuses
>(sorry if I am telling you the obvious)

No problem, sometimes it's the obvious things that bite you.

>3. It really sounds like a h./w problem. Are all three boards built at the
>same time by the same people? (ie. are you SURE they are really identical?)

Well, I built them.   I also checked against known good systems (M128's in 
production products) and they fail similarly, and I KNOW that hardware is good.

>4. Do you have watchdog fuse enabled?

Nope

>Any External Reset sources?

Nope. pulled high with 1k and verified high with meter and scope.

>The JTAG will 'disconnect' if the device is reset and it will look like it 
>has lost
>sync with AVRStudio. I had a dodgy PSU that would glitch when switching a
>load and the micro would reset - lots of fun as the JTAG got 'lost'.



>5. Are you using your JTAG and/or ISP pins for other things (ie. is it
>possible for them to be loaded down when in program mode - remember in the
>mega128 the ISP program pins are shared with a UART)

Nope,

>6. Check your BOD bits - I seem to remember that even though the micro VCC
>is <5v the BOD level 4.7v and 2.7v are fixed values (ie. regardless of VCC)

Yup, BOD at 2.7V,and the same problem with BOD off.

>7. What Baudrate do you run to the JTAG ICE? I normally run at 115K but you
>might try different values to see if that helps (better to run slow than not
>at all)

9600, 19200, 115200

>8. What if your 'JTag Port Frequency'  - remember that this must be 1/4 of
>the xtal freq (I have had LOTS of weird things happening when this was not
>right) - Consider the possibility of JTAG Port Freq that is set top
>2MHz -which is fine if xtal is 8MHz. However a 'virgin micro has (by
>default) the 1MHz internal osc enabled. (Something to think about?)

Tried it at 200kHz, no help, and that's slow enough even for 800kHz clock.


>Unfortunately these JTAG settings are only adjustable when one is connected
>to a micro! This can lead to an obvious Catch-22 situation where one can't
>connect to a micro when internal OSC enabled because of JTAG clock freq is
>too high but one can't get into the appropriate AVRStudio option to change
>it!!! ARGHH Where's the Sledge hammer ;-)

Exactly.

>9. Do you have an STK500 around? Can you double check your tools with it?

Yup. It's also hosed.
I'm really thinking it's studio that's out to lunch here.


>10. You mention 3V VCC - You _are_ using the Mega128-L part aren't you?
>(sorry)

Yes, a nice big "L" in the part number, and the crystal is 8 MHz, and 
that's what the fuses are set for.


>11. Do you have any s/w running in the background that may affect timing.
>Can you see a pattern as to when it all fails (eg. in the afternoon might
>mean the PC might be overheating etc) - I know that this one is a long shot
>(sorry).

It isn't even starting up. The Port inits aren't happening.
Same in emulation, it just sits at the reset vector and whines that it 
can't read data from the part.

>HTH.
>Please let us know how you get on.
>Kind Regards,
>
>Ivan
>
>
>----- Original Message -----
>From: "Dave VanHorn" <<mailto:dvanhorn@dvanhorn.org>dvanhorn@dvanhorn.org>
>To: <<mailto:AVR-Chat@yahoogroups.com>AVR-Chat@yahoogroups.com>
>Sent: Tuesday, March 15, 2005 7:20 AM
>Subject: [AVR-Chat] Oh, I am so tired of this..
>
>
> >
> >
> > It's delivery day, and once again, my AVR tools have all decided to go
>nuts.
> > Anyone have any ideas for preventing this garbage?
> >
> > I have two AVRISPs, an STK-500, an Atmel Jtag ice, and two Olimex Jtag
>Ices.
> >
> > I have three M128 target systems in hand. Supposed to be identical.
> >
> > One is running, the other two not.  The two that don't run are fresh
> > builds, after getting to my goal with the first one.
> > I don't dare touch the one that's running until I can trust my tools
>again.
> >
> > I've checked everything as best I can on the new systems,  The chips are
> > the same date code, same 8.00 MHz crystals, same (proper value) caps, VCC
> > is in tolerance (3.0V), /Reset is pulled up with 1k.  The oscillator is
> > running a rail-to-rail sinewave of the right frequency, which at least
> > confirms that the CKOPT fuse has been set.
> >
> > All the programmers say that they can program and verify the chip
> > successfully, and that all the fuses are set right. (including M103 fuse,
> > CKOPT, WD, and BOD fuses)  Sometimes they fail to verify, or read wierd
> > fuse values, but they are all in agreement at the moment that everything's
> > fine.
> >
> > All three Jtag ices agree that they can load the program, but cannot read
> > the SRAM, registers, or anything else, and cannot run, or even
>single-step.
> >
> > The programmed targets do not run, and apparently do not even run a
>little.
> > The init code isn't even setting up the I/O ports, which is about the
>first
> > thing that I do after qualifying the reset, and setting up the stack.
> >
> > I've rebooted everything multiple times, no help
> >
> > It happens on at least four different computers, running XP Pro, and '98,
> > and with old and new studio, though USB serial ports and "legacy COM1"
> > (note, these are high end industrial USB serial boxen, not the $20 junk)
> > These are real machines with other software installed, that I actually
>use.
> >
> > Basically, anything studio drives will pack it up at random times, for
>some
> > random duration.
> >
> >
> > I've had this happen any number of times, and it always "goes away" after
>a
> > while, but I REALLY CAN"T AFFORD THIS SHIT ANYMORE. (anyone sensing a high
> > level of frustration here?)
> >
> > At this point, I feel like taking all my AVR tools out into the parking
> > lot, making a pile of them, and pounding them into sand with a splitting
>maul.
> >
> > I love the chips, but I really despise the tools.
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> <http://groups.yahoo.com/group/AVR-Chat/>http://groups.yahoo.com/group/AVR-Chat/
> >
> <mailto:AVR-Chat-unsubscribe@yahoogroups.com>AVR-Chat-unsubscribe@yahoogroups.com
> >
> >
> >
> >
> >
> >
>
>
><http://www.msgtag.com/?source=pfooter>MSGTAG has notified the sender that 
>you have read this message.
>
>[]
>
>Yahoo! Groups Sponsor
>ADVERTISEMENT
><http://us.ard.yahoo.com/SIG=129q0v4be/M=298184.6018725.7038619.3001176/D=groups/S=1706554205:HM/EXP=1110927049/A=2593423/R=0/SIG=11el9gslf/*http://www.netflix.com/Default?mqso=60190075>
>click here
>
>
>
>----------
>Yahoo! Groups Links
>    * To visit your group on the web, go to:
>    * 
> <http://groups.yahoo.com/group/AVR-Chat/>http://groups.yahoo.com/group/AVR-Chat/ 
>
>    *
>    * To unsubscribe from this group, send an email to:
>    * 
> <mailto:AVR-Chat-unsubscribe@yahoogroups.com?subject=Unsubscribe>AVR-Chat-unsubscribe@yahoogroups.com 
>
>    *
>    * Your use of Yahoo! Groups is subject to the 
> <http://docs.yahoo.com/info/terms/>Yahoo! Terms of Service.

At 06:11 PM 3/14/2005, Ivan Vernot wrote:

>----- Original Message -----
>From: "John Samperi" 
><<mailto:samperi@ampertronics.com.au>samperi@ampertronics.com.au>
>To: <<mailto:AVR-Chat@yahoogroups.com>AVR-Chat@yahoogroups.com>
>Sent: Tuesday, March 15, 2005 8:23 AM
>Subject: Re: [AVR-Chat] Oh, I am so tired of this..
>
>
><snip>
>
> > I should get my updated PCB that uses a M64 today. It has JTAG debugging
> > facilities, so I'll see what disasters await me when I switch to JTAG :-(
> >
>
>Woo hoo 64K the next thing I will hear form you is that you will start
>coding in C
>(go-on.... try it... come over to the dark side... you'll like it... I won't
>hurt (much) ;-)
>
> > Of course there is a certain person lurking in the background in this
> > forum that LOVES his JTAG ICE and Studio4.....
>
>Well I've had my share of frustration with the AVR tools. Unfortunately, it
>seems that David and yourself have had extra portions.

In multiple projects, over multiple years.
Ever since Studio 4.x was in beta, with the ice-50.  Up to a certain point, 
no problems, then it seems everything went to hell.

At 10:11 AM 15/03/2005, you wrote:

>Woo hoo 64K the next thing I will hear form you is that you will start
>coding in C

I have to do something to fill up ALL that memory space......I could
have a 56k file filled with NOPs and assemble it too :-)

>Well I've had my share of frustration with the AVR tools. Unfortunately, it
>seems that David and yourself have had extra portions.

I'm keeping all that good info on the JTAG....just in case I need it.

Regards

John Samperi

******************************************************
                         Ampertronics Pty. Ltd.
   11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
          Tel. (02) 9674-6495       Fax (02) 9674-8745
                Email: samperi@ampertronics.com.au
                  Website  http://www.ampertronics.com.au
* Electronic Design   * Custom Products   * Contract Assembly
******************************************************

Dave VanHorn wrote:
> 
>>Of course there is a certain person lurking in the background in this
>>forum that LOVES his JTAG ICE and Studio4.....
> 
> 
> I love mine when it works.
> 
> When it actually talks to studio through any sort of serial port.
> When it actually loads the chip.
> When it doesn't skip instructions in single-step.
> When it doesn't invent breakpoints that don't exist.
> and the list goes on...

If you're using jtag-ice mk-I, do *not* use a fast baud rate like 115k,
because the mk-I protocol has absolutely *no* error checking. It might
be true of other earlier tools too. Using longer serial cables and going
thru switch-boxes will exacerbate this.

MSGTAG has notified the sender that you have read this message.

At 08:03 PM 3/14/2005, Russell Shaw wrote:

>Dave VanHorn wrote:
> >
> >>Of course there is a certain person lurking in the background in this
> >>forum that LOVES his JTAG ICE and Studio4.....
> >
> >
> > I love mine when it works.
> >
> > When it actually talks to studio through any sort of serial port.
> > When it actually loads the chip.
> > When it doesn't skip instructions in single-step.
> > When it doesn't invent breakpoints that don't exist.
> > and the list goes on...
>
>If you're using jtag-ice mk-I, do *not* use a fast baud rate like 115k,
>because the mk-I protocol has absolutely *no* error checking. It might
>be true of other earlier tools too. Using longer serial cables and going
>thru switch-boxes will exacerbate this.

Hmm.. I have pretty much always used 1152, but wasn't aware of the lack of 
error checking.
Still, I would think that on a 6' cable, the error rate should be zero.

Today I've tried various combinations of three computers, two running XP, 
and one running 98.
Olimex and Atmel Jtag ICEs
AVRISP, and STK-500.
Different serial cables, different serial ports, USB and legacy.
Different target systems.
Different target power supplies.

At 12:24 PM 15/03/2005, you wrote:

>What about the PEN pin - that should be pulled high.

HOHO I left it N/C in my board. Does it not have it's
own internal pullup?.....Whaduya mean look at the data sheet?

Regards

John Samperi

******************************************************
                         Ampertronics Pty. Ltd.
   11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
          Tel. (02) 9674-6495       Fax (02) 9674-8745
                Email: samperi@ampertronics.com.au
                  Website  http://www.ampertronics.com.au
* Electronic Design   * Custom Products   * Contract Assembly
******************************************************

Dave VanHorn escreveu:
> 
> Hmm.. I have pretty much always used 1152, but wasn't aware of the lack of 
> error checking.
> Still, I would think that on a 6' cable, the error rate should be zero.
> 
> Today I've tried various combinations of three computers, two running XP, 
> and one running 98.
> Olimex and Atmel Jtag ICEs
> AVRISP, and STK-500.
> Different serial cables, different serial ports, USB and legacy.
> Different target systems.
> Different target power supplies.
> 

I see Studio as a constant. Why dont you try avrdude, uisp, sp12k, ponyprog...

--
Francisco

Dave,

 Sorry to hear you're having a bad time.
A suggestion..

Download the CV-AVR demo, compile your code on studio, and then use CV-AVR 
to program the chips.

I have no end of hassle with the bloody avr studio programmer, but CVAVR 
always seems to work perfectly.

Paul

----- Original Message ----- 

From: "Dave VanHorn" <dvanhorn@dvanhorn.org>
To: <AVR-Chat@yahoogroups.com>
Sent: Monday, March 14, 2005 8:20 PM
Subject: [AVR-Chat] Oh, I am so tired of this..


>
>
> It's delivery day, and once again, my AVR tools have all decided to go 
> nuts.
> Anyone have any ideas for preventing this garbage?
>
> I have two AVRISPs, an STK-500, an Atmel Jtag ice, and two Olimex Jtag 
> Ices.
>
> I have three M128 target systems in hand. Supposed to be identical.
>
> One is running, the other two not.  The two that don't run are fresh
> builds, after getting to my goal with the first one.
> I don't dare touch the one that's running until I can trust my tools 
> again.
>
> I've checked everything as best I can on the new systems,  The chips are
> the same date code, same 8.00 MHz crystals, same (proper value) caps, VCC
> is in tolerance (3.0V), /Reset is pulled up with 1k.  The oscillator is
> running a rail-to-rail sinewave of the right frequency, which at least
> confirms that the CKOPT fuse has been set.
>
> All the programmers say that they can program and verify the chip
> successfully, and that all the fuses are set right. (including M103 fuse,
> CKOPT, WD, and BOD fuses)  Sometimes they fail to verify, or read wierd
> fuse values, but they are all in agreement at the moment that everything's
> fine.
>
> All three Jtag ices agree that they can load the program, but cannot read
> the SRAM, registers, or anything else, and cannot run, or even 
> single-step.
>
> The programmed targets do not run, and apparently do not even run a 
> little.
> The init code isn't even setting up the I/O ports, which is about the 
> first
> thing that I do after qualifying the reset, and setting up the stack.
>
> I've rebooted everything multiple times, no help
>
> It happens on at least four different computers, running XP Pro, and '98,
> and with old and new studio, though USB serial ports and "legacy COM1"
> (note, these are high end industrial USB serial boxen, not the $20 junk)
> These are real machines with other software installed, that I actually 
> use.
>
> Basically, anything studio drives will pack it up at random times, for 
> some
> random duration.
>
>
> I've had this happen any number of times, and it always "goes away" after 
> a
> while, but I REALLY CAN"T AFFORD THIS SHIT ANYMORE. (anyone sensing a high
> level of frustration here?)
>
> At this point, I feel like taking all my AVR tools out into the parking
> lot, making a pile of them, and pounding them into sand with a splitting 
> maul.
>
> I love the chips, but I really despise the tools.
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>

On Mon, 2005-03-14 at 19:43 -0500, Dave VanHorn wrote:
> Yes, a nice big "L" in the part number, and the crystal is 8 MHz, and 
> that's what the fuses are set for.

What type of crystal are you using? I have experienced wonky behavior
between identical boards after hot-air hand-soldering a SMT crystal
down. Turns out my hot air rework station was set too hot, and I had
overheated the part.

Just an idea, on the off chance you're using a SMT crystal...

Dave

>
>Do you use Imagecraft C for the AVR? If so can you try using the inbuilt
>programmer with the ISP and see what happens.
>I assume you are using the serial ISP - have you tried the Parallel port
>version? (perhaps even using PonyProg?)

Nope, I'm an assembler guy.
Remember now, the target has been ruled out as it's still behaving badly on 
known good production hardware.

>It won't necessarily solve your problem but might vindicate the h/w -
>although the way you describe it, sounds like it is the tools - but what has
>changed??
>
> > >Any External Reset sources?
> > Nope. pulled high with 1k and verified high with meter and scope.
>
>What about the PEN pin - that should be pulled high.

It floats high, internal pullup on the M128

> > >9. Do you have an STK500 around? Can you double check your tools with it?
> >
> > Yup. It's also hosed.
> > I'm really thinking it's studio that's out to lunch here.
>
>Looks like it..
>What version of AVRStudio are you using? I seem to remember something on
>avrfreaks about Atmel upgrading the ISP/JTAG protocol with Studio 4.11 and
>that some people had problems upgrading the s/w in their JTAGs/ISPs.
>Your might want to check that avenue.

Latest and greatest 4.11   Yes, I have another AVRISP that studio 
consistently fails to upgrade as well.
Everything else has been upgraded


>Is it possible to run the board at 5V (or at least 'as high as you
>dare) -'just to see' if it makes a difference?

No, the board won't tolerate that. Too many $$$ 3V parts.


>Just a thought Dave - what EXATly is the problem with nor connectiong.
>Does AVRStudio not detect the JTAG/ISP or is it that the ice does not detect
>the device?

Well, it varies, but at the moment, the ICEs and AVRISPs are detecting, and 
sort of working, to various degrees.
Like I said yesterday, I was not able to read the hex out of the working 
unit with one Jtag, but I was with another.
That one wouldn't program a target, but the first one would...  It's 
nonsensical stuff like that.

>If it is the former then running up a terminal program at 19K2,8,n,1 and
>typing 'S' at the JTAGICE should result in 'AVRBOOT' being returned to you.
>(you may need to cycle pwr to the ICE as it defaults to 19K2). This verifies
>you serial port etc.
>
>Did you want to read out the fuse settings and post them here - so that
>others can 'double check' them for you. - problem being, I suppose, that you
>can't connect to the micro to read them out!!? Can you erase the micro and
>start again?

I've checked and re-checked, and as I said, I've ruled out any target 
problems, since the tools are also misbehaving on known good hardware.

But, I've left everything powered down overnight, and either that, or the 
passage of time, seems to cure most of these issues.

At 09:35 PM 3/14/2005, John Samperi wrote:

>At 12:24 PM 15/03/2005, you wrote:
>
> >What about the PEN pin - that should be pulled high.
>
>HOHO I left it N/C in my board. Does it not have it's
>own internal pullup?.....Whaduya mean look at the data sheet?

It do.

>
>I see Studio as a constant. Why dont you try avrdude, uisp, sp12k, ponyprog...

Yes, you're right there, and that's where I suspect the problem is.

Why I haven't tried it, is that I have no experience with that toolchain.
Perhaps today is the day to get some.

At 08:37 AM 3/15/2005, Paul Maddox wrote:

>Dave,
>
>  Sorry to hear you're having a bad time.
>A suggestion..
>
>Download the CV-AVR demo, compile your code on studio, and then use CV-AVR
>to program the chips.
>
>I have no end of hassle with the bloody avr studio programmer, but CVAVR
>always seems to work perfectly.

Well, that's a non-linear solution.. :)

I never thought that CV would help me in assemblerland.

Ok, now I have two alternatives.


I have also seen some talk about AVRORA or AVORA?? Not sure what's up with 
that.

At 08:39 AM 3/15/2005, David D. Rea wrote:

>On Mon, 2005-03-14 at 19:43 -0500, Dave VanHorn wrote:
> > Yes, a nice big "L" in the part number, and the crystal is 8 MHz, and
> > that's what the fuses are set for.
>
>What type of crystal are you using? I have experienced wonky behavior
>between identical boards after hot-air hand-soldering a SMT crystal
>down. Turns out my hot air rework station was set too hot, and I had
>overheated the part.

Ouch!       No, these are HC49U cans, and I'm soldering them without hot air.
That's one small point of sanity though. WHEN THE PROGRAMMERS DECIDE TO 
WORK, I can change the fuse bits, and I see the oscillator turn on and off 
accordingly.  So, at least something's working.

>Just an idea, on the off chance you're using a SMT crystal...

Even if I was, I would have hand-soldered it. :)  I don't have hot air here.

--- In AVR-Chat@yahoogroups.com, "David D. Rea" <dave@d...> wrote:
> On Mon, 2005-03-14 at 19:43 -0500, Dave VanHorn wrote:
> > Yes, a nice big "L" in the part number, and the crystal is 8 
MHz, and 
> > that's what the fuses are set for.
> 
> What type of crystal are you using? I have experienced wonky 
behavior
> between identical boards after hot-air hand-soldering a SMT crystal
> down. Turns out my hot air rework station was set too hot, and I 
had
> overheated the part.
> 
> Just an idea, on the off chance you're using a SMT crystal...
> 
> Dave

Hi Dave,


Did you have a look at your serial port connections?? all the 
devices are connected over your PC's serial port, if there is a 
ground potential difference you might have your communications 
garbled up.
Can try to put your PC power at the same outlet as the PSU of your 
test boards.You can also have a look if the casing of your serial 
connector 'sparks' if you touched with it to the PC serial port 
ground shield of the PC serial connector.
I have had very bad experience with PC paralel port and printers, 
sometimes a ground difference of 40 VAC!!!!


 Also check your test board PSU, good DC??? , low ripple??, check 
with a scope!!!.

Just a suggestions..

good luck


ron

>
>Did you have a look at your serial port connections?? all the
>devices are connected over your PC's serial port, if there is a
>ground potential difference you might have your communications
>garbled up.

It's not a problem. The gounds of everything on the bench tie to the same 
point.


>Can try to put your PC power at the same outlet as the PSU of your
>test boards.You can also have a look if the casing of your serial
>connector 'sparks' if you touched with it to the PC serial port
>ground shield of the PC serial connector.
>I have had very bad experience with PC paralel port and printers,
>sometimes a ground difference of 40 VAC!!!!
>
>
>  Also check your test board PSU, good DC??? , low ripple??, check
>with a scope!!!.

Bench power supply, or batteries, no difference.


FWIW, It's all working today..

I walked in, turned it on, assembled, loaded, and am debugging in the ice, 
as if nothing happened yesterday at all.

#$!@@#!@$ Typical..

At least it's in a good mood so far.

>
>
>FWIW, It's all working today..


Let me qualify that, I just saw it return from a "do nothing ISR" that is 
active, but it returned to several instructions past where it should 
have.  IOW, it skipped several instructions on the return.

The ISR is exactly this:

ISR:
         reti

No possible problem there.

At 12:46 AM 16/03/2005, you wrote:
> >I see Studio as a constant. Why dont you try avrdude, uisp, sp12k, 
> ponyprog...

AND there is also the good old AVR910 programmer :-). The latest version 3.2
is located in the files section of this forum. It is a little sluggish for
large chips I guess, but seem to be reliable and can be used from Studio.
Well at least you can have a backup programmer to check your fuses with.

Regards

John Samperi

******************************************************
                         Ampertronics Pty. Ltd.
   11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
          Tel. (02) 9674-6495       Fax (02) 9674-8745
                Email: samperi@ampertronics.com.au
                  Website  http://www.ampertronics.com.au
* Electronic Design   * Custom Products   * Contract Assembly
******************************************************

On Tue, Mar 15, 2005 at 08:46:55AM -0500, Dave VanHorn wrote:

> >I see Studio as a constant. Why dont you try avrdude, uisp, sp12k, ponyprog...
> 
> Yes, you're right there, and that's where I suspect the problem is.
> 
> Why I haven't tried it, is that I have no experience with that toolchain.
> Perhaps today is the day to get some.

Just a word of warning - Atmel's new 2.x firmware for the STK500 /
AVRISP has broken backward compatibility for all tools that supported
them, except their own.  If you have updated the firmware to 2.x on
the STK500, you will need to revert it back to 1.x to work with
AVRDUDE, and most other third-party programming tools.

We're currently working to support 2.x in AVRDUE, but it's not there
yet.  I recently purchased a second STK500 so that I could take it to
2.x in order to work on the new firmware support without messing up my
production unit that is at 1.18 which I rely on daily :-)

-Brian
-- 
Brian Dean
BDMICRO - ATmega128 Based MAVRIC Controllers
http://www.bdmicro.com/

>
>Just a word of warning - Atmel's new 2.x firmware for the STK500 /
>AVRISP has broken backward compatibility for all tools that supported
>them, except their own.  If you have updated the firmware to 2.x on
>the STK500, you will need to revert it back to 1.x to work with
>AVRDUDE, and most other third-party programming tools.

Bloody lovely.
I only have the one AVRISP that hasn't been upgraded, because it won't.
It still works as well as any of them, but it always fails the upgrade.


>We're currently working to support 2.x in AVRDUE, but it's not there
>yet.  I recently purchased a second STK500 so that I could take it to
>2.x in order to work on the new firmware support without messing up my
>production unit that is at 1.18 which I rely on daily :-)

Oh, Ok I didn't realise you were THAT brian! :)
I feel better now, my Mavric works just fine.

Cross-thought.. Ever considered laying the Jtag ice option right into the 
mavric?

>-Brian
>--
>Brian Dean
>BDMICRO - ATmega128 Based MAVRIC Controllers
>http://www.bdmicro.com/

On Tue, Mar 15, 2005 at 03:16:59PM -0500, Dave VanHorn wrote:

> >We're currently working to support 2.x in AVRDUE, but it's not there
> >yet.  I recently purchased a second STK500 so that I could take it to
> >2.x in order to work on the new firmware support without messing up my
> >production unit that is at 1.18 which I rely on daily :-)
> 
> Oh, Ok I didn't realise you were THAT brian! :)
> I feel better now, my Mavric works just fine.

Guilty :-)

> Cross-thought.. Ever considered laying the Jtag ice option right into the
> mavric?

The JTAG 10-pin header is there - it works great.  Is there something
missing?  Or do you mean incorporating JTAGICE functionality directly
on the board so that a JTAGICE is not needed?  That'd be interesting.
Alternatively, it might be more cost effective to use one of Graham's
ICE-Cubes from ECROS Technology for only around $40 - which would
allow you to add JTAG-ICE functionality to any board with a 10-pin
JTAG header.  I've tested Graham's ICE-Cube and it works as advertised
- and it's hard to beat the price.

-Brian
-- 
Brian Dean
BDMICRO - ATmega128 Based MAVRIC Controllers
http://www.bdmicro.com/

>
>The JTAG 10-pin header is there - it works great.  Is there something
>missing?  Or do you mean incorporating JTAGICE functionality directly
>on the board so that a JTAGICE is not needed?  That'd be interesting.

That's what I meant.

>Alternatively, it might be more cost effective to use one of Graham's
>ICE-Cubes from ECROS Technology for only around $40 - which would
>allow you to add JTAG-ICE functionality to any board with a 10-pin
>JTAG header.  I've tested Graham's ICE-Cube and it works as advertised
>- and it's hard to beat the price.

I have some of the Olimex units, they are just as good as the Atmel ones 
apparently. :)

But for some guys, the MAVRIC is the only platform they will ever be on, 
and at a cost of what, say $10 extra, it makes sense.

Dave -

I've been watching your travails and don't recall whether
or not you have this same problem with a simple, basic
diagnostic program, say a pin toggler.

Jim 
---------------------------------------------------------------
The Think Different Store
http://www.thinkdifferentstore.com/
For All Your Mac Gear
---------------------------------------------------------------

This is my code:

unsigned char Rxindex;
unsigned char Rxbuffer[11];
unsigned char frec_buffer[12];
unsigned char ad_volt[13];

union ad9850_data {
unsigned long ldata;
unsigned char cdata[4];
};
unsigned char ad9850_control=0; //control byte for AD9850,
union ad9850_data ad9850_frec; //frecuency data(32 bits) for AD9850



void RF_commander(unsigned char rscomd){

unsigned char combuffer2, i;

if ((rscomd>13) && (rscomd<123)) {
    Rxbuffer[Rxindex]=rscomd;
    uart_putc(rscomd);              //transmit LSB to PC
    if (Rxindex>10) {               //check if Rxindex<12
        Rxindex=0;                  //
        clear_Rxbuffer();
    }
    else Rxindex++;
return;
}

if (rscomd==13){
switch(Rxbuffer[0])
    {

    //! command An = adquire A/D(n) and sent in ASCII to PC
    //if (Rxbuffer[0]=="A")
    case 65:  //!"A"=65
     .
     .
     .
     break;

//! F0x89ABCDEF = "F" + 4 bytes(32 bits) ->  
//set frecuency to 89ABCDEF Herz

    //if (Rxbuffer[0]=="F")
    case 70:  //!"F"=70
       for (i=0;i<(Rxindex+1);i++) {
            ad9850_frec.cdata[i]=Rxbuffer[(i+1)];
        }

       /*for (i=0;i<(Rxindex+1);i++) {
            frec_buffer[i]=Rxbuffer(i+1)];            
                //eliminate "F"
        }  
        Rxindex--;                                  //dec index
        uart_putc(10);                             // new line
        uart_putc(13);                             // CR
        uart_puts_p(PSTR("Frec = "));
        uart_puts(ltoa(ad9850_frec.ldata,ad_volt,10));
        uart_puts_p(PSTR(" Hz"));
        uart_putc(10);                             // new line
        uart_putc(13);                             // CR
        Rxindex=0;
        clear_Rxbuffer();
        break;




to test: in hyperterminal I put:
F0001(ASCII) + Return = 0x30303031hex = 808464433dec
and the AVR return the bytes in reverse order "1000" 
but in binary = 0x31303030hex = 825241648dec




--- In AVR-Chat@yahoogroups.com, "brewski922" <brewski@i...> wrote:
> 
> --- In AVR-Chat@yahoogroups.com, "fjch100" <fjch100@c...> wrote:
> > 
> > HI,
> > I have a question:
> > when I sent a Long(4 bytes) variable from the PC to the AVR 
which 
> > byte is first? LSB ? MSB ?
> > and if a need to sent a Long from the AVR to the PC USART (with 
a 
> > Borland Delphi program) what byte is needed to be first? LSB ? 
MSB?
> > 
> > also I´m using WINAVR GCC, my LCD rutine is with printf, how can 
I 
> > set the GCC to use LCD & USART simutaneusly with 
printf/fdevopen ?
> 
> That depends on the protocol. If you are sending a file you are 
> sending binary info. I know nothing about how programs do that but 
I 
> have written programs that an AVR sends command "B0102\r" 
consisting 
> of 5 ASCII characters followed CR, another ASCII.
> 
> The equipment that receives this command is a Audio/Video 
switcher. 
> The switcher is expecting the command to consist of 
> A=Audio V=Video B=Both
> Outport port, there are 2, 01 and 02
> Input port, there are 8, 01 through 08
> Carriage Return
> 
> In the above I'm switching Both, to Output 1, from Input 2.
> 
> I'm using CodeVision and the above string is stored in Flash as
> flash char    S12[]="B0102\r";
> When the appropriate pushbutton is pushed the above string is sent 
> out the serial port. The fact that the switcher changes correctly 
as 
> commanded proves that that string arrives at the switcher exactly 
as 

> it is stored in Flash with the exception that the '\r' is replaced 
> with a CR.
> 
> The fact that you are sending bytes may be the problem. 
> 
> Could you show us a snippet of your code?
> 
> Mike

At 07:34 PM 3/15/2005, you wrote:


>Maybe it's the right answer, to just have a separate machine for 
>this.  Cumbersome though, you can't get away from the keyboard, mouse and 
>screen.  (I-glasses???)

  Not too cumbersome. Invest a few bucks in a KVM. I did this a few  months 
ago and it's has really improved productivity around here. I personally 
like having all my eggs in one basket for development, but....

   The extra dollars for a dedicated dev box seem minor when compared to 
the wasted hours and frustration.
   Does not have to be a powerhouse, just the bare minimum to do the job.

Get it working and then freeze it. Make a disk image, and when things start 
getting flaky restore the snapshot and reset to a known condition.

  (had my own nightmares with ice-200)

>
>   Not too cumbersome. Invest a few bucks in a KVM. I did this a few  months
>ago and it's has really improved productivity around here. I personally
>like having all my eggs in one basket for development, but....

Hmm.. I tried those before, and had bad luck. but they were just mechanical 
switches.
Is there better stuff available now?

>    The extra dollars for a dedicated dev box seem minor when compared to
>the wasted hours and frustration.
>    Does not have to be a powerhouse, just the bare minimum to do the job.

Yeah, I would have rather spend that $500 twoard buying a nice little system.

>Get it working and then freeze it. Make a disk image, and when things start
>getting flaky restore the snapshot and reset to a known condition.
>
>   (had my own nightmares with ice-200)

You know, I never had a problem with the ICE-200, but I haven't actually 
used it since before S4 came out.
That may not be a coincidence.
It was solid as a rock for me under the older S2.x and 3.x
I shoveled out some BIG projects with that thing, in fact my first project 
was on an 8515, and I went from "what's an AVR" to a completed commercial 
project in 6 weeks.

At 07:59 PM 3/15/2005, you wrote:


> >
> >   Not too cumbersome. Invest a few bucks in a KVM. I did this a few  months
> >ago and it's has really improved productivity around here. I personally
> >like having all my eggs in one basket for development, but....
>
>Hmm.. I tried those before, and had bad luck. but they were just mechanical
>switches.
>Is there better stuff available now?

The current ones are very slick. Handle hi-res displays. ps-2 style mice 
and keyboards. Newest ones do USB.
Hot key switches between PCs. They also got quite cheap. Under 50 bucks for 
name brand / two machine version with cables. More then two machines, or 
very long cable lengths, price goes up .

  Honestly, it made a huge difference around here not having to deal with 
two keyboards and monitors. Actually I do have two monitors because I run a 
dual headed system normally. But a quick hot key press and suddenly the 
second monitor is on the secondary box, and keyboard and mouse follow along.


> >
> >   (had my own nightmares with ice-200)
>
>You know, I never had a problem with the ICE-200, but I haven't actually
>used it since before S4 came out.
>That may not be a coincidence.
>It was solid as a rock for me under the older S2.x and 3.x
>I shoveled out some BIG projects with that thing, in fact my first project
>was on an 8515, and I went from "what's an AVR" to a completed commercial
>project in 6 weeks.

  Love the ice-200. Very early on I was having some very weird inconsistent 
problems and was about to give up on it.. Tracked it down to some weird 
windows / comm port issue. Never had a problem after that. And it's a great 
bargain.  I really really wish there was something equivalent for the 
mega8. (yes I know about debug wire and various jtag options)

--- In AVR-Chat@yahoogroups.com, Dave VanHorn <dvanhorn@d...> wrote:
> >   Not too cumbersome. Invest a few bucks in a KVM. I did this a 
few  months
> >ago and it's has really improved productivity around here. I 
personally
> >like having all my eggs in one basket for development, but....
> 
> Hmm.. I tried those before, and had bad luck. but they were just 
mechanical 
> switches.
> Is there better stuff available now?

Absolutely.  Some stuff is expensive as hell, but others are pretty 
good.  I use a Cybex (now Avocent) AutoView 400 myself - very nice.  
It will talk to regular systems as well as those without PS2 ports, 
just USB.  It does the keyboard/mouse translation internally, and it 
works flawlessly.  It will allow two keyboard/monitor/mouse setups 
to access 8 systems, both at once.

I run my dev box and main box at 1920x1440, the game box at 
1600x1200 and the CD/DVD burner box at 1280x1024.  It will switch 
with buttons on the front (it's mounted to the side of the desk at 
my right) or via key-toggle (Ctrl-Ctrl).

I cannot imagine working without it.  It was expensive, and worth 
every penny.

Note - everything is still regular DB15 VGA type connectors.  I 
don't know of any (affordable) DVI kvm setup out there yet.

Dean.

At 12:22 PM 16/03/2005, you wrote:
> > >   (had my own nightmares with ice-200)
>   Love the ice-200. Very early on I was having some very weird inconsistent
>problems and was about to give up on it.. Tracked it down to some weird
>windows / comm port issue.

I have had my shares of headaches with the ICE200, but it
seemed that the comm ports issue was the main culpirit as
I feel is also for most of the other problems with all the
other tools.

Since I got (by accident) a PCI serial card for additional
ports for my new computer AND some small bug fixes in
Studio4.11 it has been solid as a rock.....it's nice to have
reliable working tools...

Not looking forward to JTAGICE though....may have to start using
it next week.


Regards

John Samperi

******************************************************
                         Ampertronics Pty. Ltd.
   11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
          Tel. (02) 9674-6495       Fax (02) 9674-8745
                Email: samperi@ampertronics.com.au
                  Website  http://www.ampertronics.com.au
* Electronic Design   * Custom Products   * Contract Assembly
******************************************************

----- Original Message -----

From: Lasse Madsen

To: AVR-Chat@yahoogroups.com

Sent: Wednesday, March 16, 2005 12:00 AM

Subject: RE: [AVR-Chat] Oh, I am so tired of this..

I share your frustration regarding the AVR tools…

I’ve worked for 5 years in an embedded development company using AVR processors and Kanda tools everyday from 9 to 17:00 sometimes you could sit a whole day doing nothing because your tools decided to strike on you. We where six on the office and everyone of us have had those problems at least once a month, think about the cost of having engineers sitting on their ass doing nothing because of bullshit tools…

Today I run my own business doing practically the same as I did before and I still have those problems from time to time, I’ve tried a lot of alternatives to the AVR such as PIC, Zilog, OKI, LPC ARM’s and MSP430 but even though I have tried all these processors and wasted A LOT of time trying, I always fall back to AVR as my 5 year experience means that I can get the job done “of the back” always knowing that I’m doing the right thing from the start… Starting a new project requiring PCB artwork with a new processor can cost you a shit load of problems and money, Been there done that and paid the cheque ! For me trying out the LPC2106 for a new project became my worst nightmare as it turned out there where a lot of internal “bugs” in the processor such as the ADC/IO port that couldn’t be used digitally when also used with Analog signals not to mention a useless internal reset circuit that would latch up the device… and a lot of misunderstandings with the SPI port … I cant even assemble my thoughts about all the problems I’ve had with that one… I ended up designing an AVR board in my holiday having the board made ASAP and mounted at the cost of a Boeing 747…

What I’m saying is … AVR has arrived to stay, there’s no evidence that they would stop production or any processors taking its throne as the “king of 8bits” also there’s an AVR for almost every project I’ve ever had, and I’ve actually found a reliable solution to my problems which is having a separate VIA EPIA (a very small size computer) that is used ONLY as a programming device its placed inches from my regular pc and I can switch my screen from my regular pc to the EPIA with a monitor switch box at the push of a button having the EPIA already set up for programming from the network drive where I compile my project…

IIs that the Mini-ITX or Nano-? I'm putting together a Mini-ITX EPIA system.

Leon

--

Leon Heller, G1HSM
http://www.geocities.com/leon_heller

----- Original Message -----

From: Henry Carl Ott

To: AVR-Chat@yahoogroups.com

Sent: Wednesday, March 16, 2005 1:22 AM

Subject: RE: [AVR-Chat] Oh, I am so tired of this..

At 07:59 PM 3/15/2005, you wrote:


> >
> > Not too cumbersome. Invest a few bucks in a KVM. I did this a few months
> >ago and it's has really improved productivity around here. I personally
> >like having all my eggs in one basket for development, but....
>
>Hmm.. I tried those before, and had bad luck. but they were just mechanical
>switches.
>Is there better stuff available now?

The current ones are very slick. Handle hi-res displays. ps-2 style mice
and keyboards. Newest ones do USB.
Hot key switches between PCs. They also got quite cheap. Under 50 bucks for
name brand / two machine version with cables. More then two machines, or
very long cable lengths, price goes up .

Honestly, it made a huge difference around here not having to deal with
two keyboards and monitors. Actually I do have two monitors because I run a
dual headed system normally. But a quick hot key press and suddenly the
second monitor is on the secondary box, and keyboard and mouse follow along.


> >
> > (had my own nightmares with ice-200)
>
>You know, I never had a problem with the ICE-200, but I haven't actually
>used it since before S4 came out.
>That may not be a coincidence.
>It was solid as a rock for me under the older S2.x and 3.x
>I shoveled out some BIG projects with that thing, in fact my first project
>was on an 8515, and I went from "what's an AVR" to a completed commercial
>project in 6 weeks.

Love the ice-200. Very early on I was having some very weird inconsistent
problems and was about to give up on it.. Tracked it down to some weird
windows / comm port issue. Never had a problem after that. And it's a great
bargain. I really really wish there was something equivalent for the
mega8. (yes I know about debug wire and various jtag options)

On Tue, 2005-03-15 at 20:22 -0500, Henry Carl Ott wrote:
> The current ones are very slick. Handle hi-res displays. ps-2 style mice 
> and keyboards. Newest ones do USB.
> Hot key switches between PCs. They also got quite cheap. Under 50 bucks for 
> name brand / two machine version with cables. More then two machines, or 
> very long cable lengths, price goes up .
> 
>   Honestly, it made a huge difference around here not having to deal with 
> two keyboards and monitors. Actually I do have two monitors because I run a 
> dual headed system normally. But a quick hot key press and suddenly the 
> second monitor is on the secondary box, and keyboard and mouse follow along.

There are dual-head KVM (kbd, video, mouse) switches out there now, and
it's hard to find a KVM switch that *isn't* solid-state nowadays. The
dual-head units are somewhat pricey, but worth it if you've already
invested in two computers, two dual-head video cards, and two largish
displays!

I highly recommend the KVM switch products from StarTech. I use a
Starview KVM at my office, where I switch between a dual-head Windows
and a single-head Gentoo Linux box. The StarTech was the most
cost-effective switch (4 ports for around $100, including cables) and it
is the ONLY one that doesn't bork my X server's mouse, requiring a CTRL
+ALT+F1 --> CTRL+ALT+F7 recycle of the display.

Best,
Dave

Dave,

> One of my biggest frustrations is that I can buy a Dell Latitude
> notebook that has a 14" LCD panel running at an impressive 1400x1050 -
> but the highest resolution that a freestanding LCD panel will run is a
> piddly 1280x1024 - even at 17" or 19"!

go and check out the apple displays.
I have a 23" display, 1600 by 1050, and such a crystal clear sharp picture.
 
> Has anyone come across any desktop LCD panels in 17" or 19" that will
> run at a reasonable resolution (read: 1400x1050 or 1600x1200)?!

visit www.apple.com :-)

Paul

1920x1440? Is that on a CRT or an LCD?

One of my biggest frustrations is that I can buy a Dell Latitude
notebook that has a 14" LCD panel running at an impressive 1400x1050 -
but the highest resolution that a freestanding LCD panel will run is a
piddly 1280x1024 - even at 17" or 19"!

A friend of mine actually asked me if it would be possible to rip the
panel out of one of these laptops and run it on his desktop. We would
have had to buy a VGA-->LVDS interface board, and the only one we could
find was a development system that ran over $700.

Has anyone come across any desktop LCD panels in 17" or 19" that will
run at a reasonable resolution (read: 1400x1050 or 1600x1200)?!

Dave

On Wed, 2005-03-16 at 02:58 +0000, fnatmed wrote:
> 
> --- In AVR-Chat@yahoogroups.com, Dave VanHorn <dvanhorn@d...> wrote:
> > >   Not too cumbersome. Invest a few bucks in a KVM. I did this a 
> few  months
> > >ago and it's has really improved productivity around here. I 
> personally
> > >like having all my eggs in one basket for development, but....
> > 
> > Hmm.. I tried those before, and had bad luck. but they were just 
> mechanical 
> > switches.
> > Is there better stuff available now?
> 
> Absolutely.  Some stuff is expensive as hell, but others are pretty 
> good.  I use a Cybex (now Avocent) AutoView 400 myself - very nice.  
> It will talk to regular systems as well as those without PS2 ports, 
> just USB.  It does the keyboard/mouse translation internally, and it 
> works flawlessly.  It will allow two keyboard/monitor/mouse setups 
> to access 8 systems, both at once.
> 
> I run my dev box and main box at 1920x1440, the game box at 
> 1600x1200 and the CD/DVD burner box at 1280x1024.  It will switch 
> with buttons on the front (it's mounted to the side of the desk at 
> my right) or via key-toggle (Ctrl-Ctrl).
> 
> I cannot imagine working without it.  It was expensive, and worth 
> every penny.
> 
> Note - everything is still regular DB15 VGA type connectors.  I 
> don't know of any (affordable) DVI kvm setup out there yet.
> 
> Dean.
> 
> 
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
>

> go and check out the apple displays.
> I have a 23" display, 1600 by 1050, and such a crystal clear sharp 
> picture.

my bad, its running at 1920 by 1200 :-)

Paul

http://www.geocities.com/leon_heller

----- Original Message ----- 
From: David D. Rea
To: AVR-Chat@yahoogroups.com
Sent: Wednesday, March 16, 2005 2:50 PM
Subject: RE: [AVR-Chat] Oh, I am so tired of this..


On Tue, 2005-03-15 at 20:22 -0500, Henry Carl Ott wrote:
> The current ones are very slick. Handle hi-res displays. ps-2 style mice
> and keyboards. Newest ones do USB.
> Hot key switches between PCs. They also got quite cheap. Under 50 bucks 
> for
> name brand / two machine version with cables. More then two machines, or
> very long cable lengths, price goes up .
>
>   Honestly, it made a huge difference around here not having to deal with
> two keyboards and monitors. Actually I do have two monitors because I run 
> a
> dual headed system normally. But a quick hot key press and suddenly the
> second monitor is on the secondary box, and keyboard and mouse follow 
> along.

There are dual-head KVM (kbd, video, mouse) switches out there now, and
it's hard to find a KVM switch that *isn't* solid-state nowadays. The
dual-head units are somewhat pricey, but worth it if you've already
invested in two computers, two dual-head video cards, and two largish
displays!

I highly recommend the KVM switch products from StarTech. I use a
Starview KVM at my office, where I switch between a dual-head Windows
and a single-head Gentoo Linux box. The StarTech was the most
cost-effective switch (4 ports for around $100, including cables) and it
is the ONLY one that doesn't bork my X server's mouse, requiring a CTRL
+ALT+F1 --> CTRL+ALT+F7 recycle of the display.

I've just got a KVM, only 17 GBP from a local shop.

Leon

Easy equation to balance:

Apple Cinema Display + Dual-processor Power Mac G5 + Gentoo Linux =
Happy Dave + Empty Wallet

:)

Dave

On Wed, 2005-03-16 at 15:52 +0000, Paul Maddox wrote:
> Dave,
> 
> > One of my biggest frustrations is that I can buy a Dell Latitude
> > notebook that has a 14" LCD panel running at an impressive 1400x1050 -
> > but the highest resolution that a freestanding LCD panel will run is a
> > piddly 1280x1024 - even at 17" or 19"!
> 
> go and check out the apple displays.
> I have a 23" display, 1600 by 1050, and such a crystal clear sharp picture.
>  
> > Has anyone come across any desktop LCD panels in 17" or 19" that will
> > run at a reasonable resolution (read: 1400x1050 or 1600x1200)?!
> 
> visit www.apple.com :-)
> 
> Paul
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
>

> 1920x1440? Is that on a CRT or an LCD?
>
> One of my biggest frustrations is that I can buy a Dell Latitude
> notebook that has a 14" LCD panel running at an impressive 1400x1050 -
> but the highest resolution that a freestanding LCD panel will run is a
> piddly 1280x1024 - even at 17" or 19"!

I've got one of those notebooks. It's a great picture, but you'll need 
reading
glasses ! :-)

> A friend of mine actually asked me if it would be possible to rip the
> panel out of one of these laptops and run it on his desktop. We would
> have had to buy a VGA-->LVDS interface board, and the only one we could
> find was a development system that ran over $700.
>
> Has anyone come across any desktop LCD panels in 17" or 19" that will
> run at a reasonable resolution (read: 1400x1050 or 1600x1200)?!

You'll have a very hard time finding any 17 " or 19" with more than 
1280*1024.
I have a Samsung 213T (which is actually a 21") that does 1600*1200, but 
most
20" does that too.
It's not really that big (compared to my previous 21" Eizo CRT, 26 kg !! 
urrk),
and the picture is awesome.

/Jesper

On Wed, 16 Mar 2005 15:52:48 -0000 you wrote:

>
>Dave,
>
>> One of my biggest frustrations is that I can buy a Dell Latitude
>> notebook that has a 14" LCD panel running at an impressive 1400x1050 -
>> but the highest resolution that a freestanding LCD panel will run is a
>> piddly 1280x1024 - even at 17" or 19"!
>
>go and check out the apple displays.
>I have a 23" display, 1600 by 1050, and such a crystal clear sharp picture.
> 
>> Has anyone come across any desktop LCD panels in 17" or 19" that will
>> run at a reasonable resolution (read: 1400x1050 or 1600x1200)?!

http://www.iiyama.de/default.asp?SID=&NAV=236&PROD=1029
has some 1600 x 1200 displays but they are 20" +
--
Ralph Hilton
http://www.ralphhilton.org
C-Meter: http://www.cmeter.org
FZAOINT http://www.fzaoint.net

www.Costco.com has 20" 1600x1200 monitors for $550.

But a better deal is 2x17" 1280x1024 monitors (~$200/ea).  About the same
price as one 1600x1200, but >30% more real estate for the debugger & editor,
etc.  I got one of their cheap 17" units this xmas and I am very satisfied.
Every year the (cheap) LCD displays get brighter and better color.

Most reasonable graphics cards, even cheap ones from two or three years ago
support dual displays.  Anyway, it has been years since I have been
restricted to one display - I would never develop any other way.

> [...] and the AVR return the bytes in reverse order "1000" 
> but in binary = 0x31303030hex = 825241648dec

This is pretty simple.  If you have source code for both ends of the 
comm channel, then modify one end to match the other.  If you only 
have source code for one end of the channel, you'll have to modify it 
to match the byte order of the other end.  Done.

Hint: don't use any library functions unless you know exactly what 
they do.

On Wednesday 16 March 2005 23:51, Larry Barello wrote:
> www.Costco.com has 20" 1600x1200 monitors for $550.
>
> But a better deal is 2x17" 1280x1024 monitors (~$200/ea).  About the same
> price as one 1600x1200, but >30% more real estate for the debugger &
> editor, etc.  I got one of their cheap 17" units this xmas and I am very
> satisfied. Every year the (cheap) LCD displays get brighter and better
> color.
>
> Most reasonable graphics cards, even cheap ones from two or three years ago
> support dual displays.  Anyway, it has been years since I have been
> restricted to one display - I would never develop any other way.
>
>
You can always add a cheap or old PCI graphics card. Two displays is very 
addictive. One for the editor, other for the pdf reader with your favorite 
AVR datasheet. Well, lots of possibilities...

I agree, duel display is great.  

But one word of caution.   What is written on the box as duel display is 
not always "true" duel display.    I ran into this awhile back.   After 
having a computer that had a  duel display that would allow displaying 
of different programs on each monitor, I decided to obtain another 
display card that was clearly marked " Duel Display "   After two days 
of not being able to make it work, I called the support center.   Their 
definition of " duel display " was the same information on both monitor, 
not different information on two monitors.   The purpose was to allow 
some one else to view this information on the 2nd screen.   They also 
admitted they had many complaints about their definition of "duel display"

Bottom line.    Verify you can display different information on each 
monitor at the same time.   Once you try it, you will never have 
anything else. 
Bruce


Cláudio E. Elicker wrote:

>On Wednesday 16 March 2005 23:51, Larry Barello wrote:
>  
>
>>www.Costco.com has 20" 1600x1200 monitors for $550.
>>
>>But a better deal is 2x17" 1280x1024 monitors (~$200/ea).  About the same
>>price as one 1600x1200, but >30% more real estate for the debugger &
>>editor, etc.  I got one of their cheap 17" units this xmas and I am very
>>satisfied. Every year the (cheap) LCD displays get brighter and better
>>color.
>>
>>Most reasonable graphics cards, even cheap ones from two or three years ago
>>support dual displays.  Anyway, it has been years since I have been
>>restricted to one display - I would never develop any other way.
>>
>>
>>    
>>
>You can always add a cheap or old PCI graphics card. Two displays is very 
>addictive. One for the editor, other for the pdf reader with your favorite 
>AVR datasheet. Well, lots of possibilities...
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>  
>

I use an nVidia dual-head GeForce card at work, which works great under
Winblows XP. I have a 21" monitor for PCB layout and CAD work, and a 17"
beside it to park all my libraries, toolboxes, log windows, etc. We use
Protel for EDA, and that package is well-set-up for dual-head work.

At home, I use Linux exclusively with exactly one exception: MSP430
design. I use AVR-GCC for AVR work. Under Linux, it's [relatively] easy
to get two (or more!) different video cards to run two stitched
displays.

Only thing holding me back now is that I want 1600x1200 (or at least
1400x1050) in a 17" or 19" LCD, and I don't want to pay through the nose
for it!

I found a series from Princeton that has 1600x1200 in a 19" LCD panel,
but it's analog-only. DVI only gets you 1280x1024. But that works for
me! Now I've just gotta wait for the price tag to go down below $500 a
pop.

Thanks, all, for your suggestions! :)

Dave

On Thu, 2005-03-17 at 00:10 -0500, Bruce wrote:
> I agree, duel display is great.   
> 
> But one word of caution.   What is written on the box as duel display
> is not always "true" duel display.    I ran into this awhile back.
> After having a computer that had a  duel display that would allow
> displaying of different programs on each monitor, I decided to obtain
> another display card that was clearly marked " Duel Display "   After
> two days of not being able to make it work, I called the support
> center.   Their definition of " duel display " was the same
> information on both monitor, not different information on two
> monitors.   The purpose was to allow some one else to view this
> information on the 2nd screen.   They also admitted they had many
> complaints about their definition of "duel display" 
> 
> Bottom line.    Verify you can display different information on each
> monitor at the same time.   Once you try it, you will never have
> anything else.  
> Bruce 
> 
> 
> Cláudio E. Elicker wrote:
> > On Wednesday 16 March 2005 23:51, Larry Barello wrote:
> >   
> > > www.Costco.com has 20" 1600x1200 monitors for $550.
> > > 
> > > But a better deal is 2x17" 1280x1024 monitors (~$200/ea).  About the same
> > > price as one 1600x1200, but >30% more real estate for the debugger &
> > > editor, etc.  I got one of their cheap 17" units this xmas and I am very
> > > satisfied. Every year the (cheap) LCD displays get brighter and better
> > > color.
> > > 
> > > Most reasonable graphics cards, even cheap ones from two or three years ago
> > > support dual displays.  Anyway, it has been years since I have been
> > > restricted to one display - I would never develop any other way.
> > > 
> > > 
> > >     
> > You can always add a cheap or old PCI graphics card. Two displays is very 
> > addictive. One for the editor, other for the pdf reader with your favorite 
> > AVR datasheet. Well, lots of possibilities...
> > 
> > 
> >  
> > Yahoo! Groups Links
> > 
> > 
> > 
> >  
> > 
> > 
> > 
> > 
> >   
> 
>                         Yahoo! Groups Sponsor
>                                           ADVERTISEMENT
>                                              click here
> 
> 
> 
> ______________________________________________________________________
> Yahoo! Groups Links
>       * To visit your group on the web, go to:
>         http://groups.yahoo.com/group/AVR-Chat/
>           
>       * To unsubscribe from this group, send an email to:
>         AVR-Chat-unsubscribe@yahoogroups.com
>           
>       * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>         Service.
>

Brian,

>     http://wsmanager.sourceforge.net/

yeah, I got that on my G4, its superb!!!

> BTW, even though AVR Studio doesn't support MacOS X, the open source
> tools for the AVR run very very well on Mac OS X.  All tools basically
> compile right out of the box, just like on any other Unix system -
> gcc, binutils, avr-libc, avrdude, avarice (avarice needs a little
> help, but it is minor).

UGH!
The headache I've had trying to get them to work.
I run Virtual PC 7 with windows 2000...
If you or anyone wants to do 'an idiots guide to develop for AVR under OSX' 
I'd be a very very happy bunny..

> Oh - and Eagle for schematic capture and layout supports native MacOS
> X.  It works great also.

I can't get on with eagle. I've got OrCAD for the PC, I wish they'd do an 
OSX verson.


> It's a very nice system to use for development!  You gain a lot and
> give up nothing.

hair, I lost a lot of that trying to get the OSX tool chain working (despite 
following ononline guide and buying a bloody keyspan USB->Serial convertor 
which OSX ignores!)

Paul

On Wed, Mar 16, 2005 at 11:03:19AM -0500, David D. Rea wrote:

> Easy equation to balance:
> 
> Apple Cinema Display + Dual-processor Power Mac G5 + Gentoo Linux =
> Happy Dave + Empty Wallet
> :)

My setup is a PowerMac dual G5 + 23" Cinema display (1920x1200) + a
second 20" 1600x1200 LCD for dual head.  Combine that with a virtual
desktop switcher like Workspace Manager:

     http://wsmanager.sourceforge.net/

And load up X11 + emacs - geez, it doesn't get much better.

And with the native MacOS X which gives the best of both worlds -
powerful Unix (Berkeley FreeBSD based - the way Unix was meant to be)
with the best GUI in the business - I can't fathom why you'd want to
downgrade that to ordinary run of the mill Linux :-)

And yes, my wallet is empty :))

BTW, even though AVR Studio doesn't support MacOS X, the open source
tools for the AVR run very very well on Mac OS X.  All tools basically
compile right out of the box, just like on any other Unix system -
gcc, binutils, avr-libc, avrdude, avarice (avarice needs a little
help, but it is minor).

Oh - and Eagle for schematic capture and layout supports native MacOS
X.  It works great also.

I did spring for a copy of Virtual PC, though, so that I can run AVR
Studio when I need to flash my STK500 or run the occasional Windows
program.  But I don't use it for day to day work - I prefer the open
source tools over AVR Studio.

It's a very nice system to use for development!  You gain a lot and
give up nothing.

-Brian
-- 
Brian Dean
BDMICRO - ATmega128 Based MAVRIC Controllers
http://www.bdmicro.com/

On Thu, Mar 17, 2005 at 04:00:50PM -0000, Paul Maddox wrote:

> UGH!
> The headache I've had trying to get them to work.
> I run Virtual PC 7 with windows 2000...
> If you or anyone wants to do 'an idiots guide to develop for AVR under OSX'
> I'd be a very very happy bunny..

Maybe I'll do that at some point, but ... honestly, all I did for each
one was to extract the source and then:

    ./configure --prefix=/usr/local/avr --target=avr
    make && make install

For gcc, you need to add --enable-languages=c to the configure.

Avr-libc was a little picky about the compile directory.  For it, do,
at the top level source directory:

    mkdir obj && cd obj && --configure --prefix=/usr/local/avr && make && make install

Avarice requires you to tell it explicitly where the bfd lib was
installed since binutils seems to install it in a place where other
tools don't look for it.  You also need to have libintl installed and
to tell it where that was if I recall.

Add /usr/local/avr/bin to your path and you should be golden.

If the primary issue is an unfamiliarity with Unix development, most
any good Unix book will apply directly to MacOS X for the most part.

> I can't get on with eagle. I've got OrCAD for the PC, I wish they'd
> do an OSX verson.

While Eagle runs very well on MacOS X, I admit it definitely requires
some getting used to.  I've learned to work with it, it does what I
need, but there is a learning curve.  But that is not specific to the
MacOS X port - I've heard the same complaint from Windows users.

> hair, I lost a lot of that trying to get the OSX tool chain working (despite
> following ononline guide and buying a bloody keyspan USB->Serial convertor
> which OSX ignores!)

I use the Keyspan USA-19HS - it has worked fine for me from day one.
In fact, I have 4 of them in use simultaneous for 4 serial ports - one
to the STK500, two to my target board, and one for a second STK500.

-Brian
-- 
Brian Dean
BDMICRO - ATmega128 Based MAVRIC Controllers
http://www.bdmicro.com/

--- In AVR-Chat@yahoogroups.com, "fnatmed" <fnatmed@y...> wrote:
> 
> Note - everything is still regular DB15 VGA type connectors.  I 
> don't know of any (affordable) DVI kvm setup out there yet.

I take it back.  I just found this ...

http://www.kvms.com/nav/item.asp?item=9524

Looks like it will do two systems with dual-display cards ...

So, one keyboard, one mouse, two 23" Apple displays, and you can 
switch between two dual-display G5 systems :)

Yum.

Now if only they do an 8-system model ...

Dean.

Brian Dean said:
>
> Maybe I'll do that at some point, but ... honestly, all I did for each
> one was to extract the source and then:
>
>     ./configure --prefix=/usr/local/avr --target=avr
>     make && make install
>
> For gcc, you need to add --enable-languages=c to the configure.
>
> Avr-libc was a little picky about the compile directory.  For it, do, at
> the top level source directory:
>
>     mkdir obj && cd obj && --configure --prefix=/usr/local/avr && make
> && make install
>
> Avarice requires you to tell it explicitly where the bfd lib was
> installed since binutils seems to install it in a place where other
> tools don't look for it.  You also need to have libintl installed and to
> tell it where that was if I recall.
>

This is all that I've done as well, but from recent discussion there is
probably a handful of patches that needed to be added before the tools
were built...


>> hair, I lost a lot of that trying to get the OSX tool chain working
>> (despite following ononline guide and buying a bloody keyspan
>> USB->Serial convertor which OSX ignores!)
>
> I use the Keyspan USA-19HS - it has worked fine for me from day one. In
> fact, I have 4 of them in use simultaneous for 4 serial ports - one to
> the STK500, two to my target board, and one for a second STK500.

My Keyspan adapter also works flawlessly.  I've also seen mention that if
you need more than 1 adapter and you don't want the port names to change
in Mac OS X to use their 4 port adapter.  I believe there is also one that
includes a parallel port, but I'm not sure of what use that would be on a
Mac.

Mike

--- In AVR-Chat@yahoogroups.com, "Cláudio E. Elicker" <elicker@g...> 
wrote:
> You can always add a cheap or old PCI graphics card. Two displays 
is very 
> addictive. One for the editor, other for the pdf reader with your 
favorite 
> AVR datasheet.

Well, that's what I use my tablet-PC for most of the time. A rather 
complete but lightweight databook...

Stefan

Brian,

> Maybe I'll do that at some point, but ... honestly, all I did for each
> one was to extract the source and then:
>
>    ./configure --prefix=/usr/local/avr --target=avr
>    make && make install

huh?

> For gcc, you need to add --enable-languages=c to the configure.

ok, perhaps I shoudl explain, I know nothing about unix :-)
I can do LS, and I know about changing owners and permissions, but thats 
where it ends.

> If the primary issue is an unfamiliarity with Unix development, most
> any good Unix book will apply directly to MacOS X for the most part.

thats the big issue :-)
I hate to say it, but on windows, all I do is hit 'install' and it works :-)

> While Eagle runs very well on MacOS X, I admit it definitely requires
> some getting used to.  I've learned to work with it, it does what I
> need, but there is a learning curve.  But that is not specific to the
> MacOS X port - I've heard the same complaint from Windows users.

yeah, the trouble is the only time I need to use it, I need something 
quick'ish..

> I use the Keyspan USA-19HS - it has worked fine for me from day one.

doesn't for me, OSX doesn't see it at all, at least I can see any serial 
devices appear anywhere (/etc/dev/ I think is where itshould appear).

Paul

Paul Maddox said:

>> If the primary issue is an unfamiliarity with Unix development, most
>> any good Unix book will apply directly to MacOS X for the most part.
>
> thats the big issue :-)
> I hate to say it, but on windows, all I do is hit 'install' and it works
> :-)

Only because Eric has taken his time to build a package to install that
way.  The Windows build started the very same way...


>> I use the Keyspan USA-19HS - it has worked fine for me from day one.
>
> doesn't for me, OSX doesn't see it at all, at least I can see any serial
>  devices appear anywhere (/etc/dev/ I think is where itshould appear).

Try: ls /dev/tty.*

If that doesn't work, find and download a copy of ZTerm.  Look at the
available devices for the port settings, the USB adapter should be there.

Your USB adapter should be plugged in before you do these.

Mike

Mike,

> Only because Eric has taken his time to build a package to install that
> way.  The Windows build started the very same way...

Agreed, anyone care do the OSX development world a HUGE favour and do the 
same for OSX?

> Try: ls /dev/tty.*

I did check there (I ran through the keyspan documentation, which is sparse 
to say the least).

> If that doesn't work, find and download a copy of ZTerm.  Look at the
> available devices for the port settings, the USB adapter should be there.

ok, I'll give that a go.

> Your USB adapter should be plugged in before you do these.

hehe, yeah I'm not that much of a novice, honest :-)

Paul (MCSE, but clueless when it comes to *nix)

Paul Maddox said:
>
> Mike,
>
>> Only because Eric has taken his time to build a package to install
>> that way.  The Windows build started the very same way...
>
> Agreed, anyone care do the OSX development world a HUGE favour and do
> the  same for OSX?

You can make the process a little easier by going to:

http://fink.sourceforge.net

This is a port/package installation system and there are ports for the avr
tools there.  They are not necessarily the latest and greatest versions,
but they are stable.  Also a Google search should lead you to an article
that shows how to use the Mac OS X development environment, Xcode, with
the avr tools.  I believe that it is at O'Reilly's web site.


> I did check there (I ran through the keyspan documentation, which is
> sparse  to say the least).

Keyspan probably doesn't expect that most Mac users are going to be using
command line UNIX tools too often.

> hehe, yeah I'm not that much of a novice, honest :-)
>
> Paul (MCSE, but clueless when it comes to *nix)

Even Windows still has a command line, but very few people still remember
how to use it.
Mac OS X gives us the best of both worlds and there are still a few things
that are damn near impossible to do from the GUI.

Mike

>
> Paul Maddox said:
>
>> I did check there (I ran through the keyspan documentation, which is
>> sparse  to say the least).

Checked tonight (first time home in 3 days, wife was in hospital) and I 
get a new device when I plug the Keyspan adapter in.  Device name is:  
tty.USA19QW3b1P1.1

Mike

Paul, olddosorcad will run just fine under osx.  

-
Mike


On Thu, 17 Mar 2005 16:00:50 -0000, Paul Maddox
<P.Maddox@signal.qinetiq.com> wrote:

>  Brian,
>  
>  >     http://wsmanager.sourceforge.net/
>  
>  yeah, I got that on my G4, its superb!!!
>  
>  > BTW, even though AVR Studio doesn't support MacOS X, the open source
>  > tools for the AVR run very very well on Mac OS X.  All tools basically
>  > compile right out of the box, just like on any other Unix system -
>  > gcc, binutils, avr-libc, avrdude, avarice (avarice needs a little
>  > help, but it is minor).
>  
>  UGH!
>  The headache I've had trying to get them to work.
>  I run Virtual PC 7 with windows 2000...
>  If you or anyone wants to do 'an idiots guide to develop for AVR under OSX'
>  I'd be a very very happy bunny..
>  
>  > Oh - and Eagle for schematic capture and layout supports native MacOS
>  > X.  It works great also.
>  
>  I can't get on with eagle. I've got OrCAD for the PC, I wish they'd do an 
>  OSX verson.
>  
>  
>  > It's a very nice system to use for development!  You gain a lot and
>  > give up nothing.
>  
>  hair, I lost a lot of that trying to get the OSX tool chain working
> (despite 
>  following ononline guide and buying a bloody keyspan USB->Serial convertor 
>  which OSX ignores!)
>  
>  Paul
>  
>  
>  
>  
>  Yahoo! Groups Sponsor 
>  
>  ADVERTISEMENT
>  
>  
>  ________________________________
>  Yahoo! Groups Links
>  
>  
> To visit your group on the web, go to:
> http://groups.yahoo.com/group/AVR-Chat/
>   
> To unsubscribe from this group, send an email to:
> AVR-Chat-unsubscribe@yahoogroups.com
>   
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

On Thu, Mar 17, 2005 at 04:00:50PM -0000, Paul Maddox wrote:

GH!
The headache I've had trying to get them to work.
I run Virtual PC 7 with windows 2000...
If you or anyone wants to do 'an idiots guide to develop for AVR under OSX'
I'd be a very very happy bunny..

hair, I lost a lot of that trying to get the OSX tool chain working (despite
following ononline guide and buying a bloody keyspan USB->Serial convertor
which OSX ignores!)
    

I use the Keyspan USA-19HS - it has worked fine for me from day one.
In fact, I have 4 of them in use simultaneous for 4 serial ports - one
to the STK500, two to my target board, and one for a second STK500.


  

On Mar 18, 2005, at 9:02 PM, Mike Murphree wrote:

>
>
>
>>
>> Paul Maddox said:
>>
>>> I did check there (I ran through the keyspan documentation, which is
>>> sparse  to say the least).
>
> Checked tonight (first time home in 3 days, wife was in hospital) and I
> get a new device when I plug the Keyspan adapter in.  Device name is:
> tty.USA19QW3b1P1.1

If you installed the software for the adapter, there is also a program 
in the Applications folder called "Keyspan Serial Assistant" that will 
show if its connected.

Mike

David -

Did you ever get your problem cleard up?

Jim Wagner
---------------------------------------------------------------
The Think Different Store
http://www.thinkdifferentstore.com/
For All Your Mac Gear
---------------------------------------------------------------

--- In AVR-Chat@yahoogroups.com, Dave VanHorn <dvanhorn@d...> wrote:

> I have some of the Olimex units,
> they are just as good as the Atmel
> ones apparently. :)

Well, I originally invented the AVR ICE-Cube because I was totally 
disgusted with the poor quality of the Olimex JTAG ICE I bought. I 
think some problems may now have been solved, such as the procedure for 
loading in the Atmel software and operation below 4.5 volts, but I 
doubt that the PCB layout has been improved and that was very bad.

Regarding putting the circuitry of a JTAG interface directly on Brian's 
MAVRIC, your cost estimate is pretty good. I think it depends what 
people do with MAVRICs. If they just develop software, your idea is a 
good one. If the MAVRIC becomes part of the final system, then it's not 
so good. I don't know why a serious user would balk at $39.95 for a 
JTAG interface, though.

On the other hand, my personal circumstances have changed so that I 
don't need the income from ECROS Technology any more. I'm only in it 
now out of loyalty to the AVR community and it's increasingly hard to 
find the time to make, test and ship ICE-Cubes. If Brian wanted to put 
a JTAG interface on a MAVRIC I would give him the ICE-Cube design, 
including the bootloader (which isn't as straightforward as people like 
to think). If I were Brian, though, I would "stick to my knitting" if I 
knew my customers could pick up a JTAG interface for less than forty 
bucks.

Graham.

At 09:45 PM 3/28/2005, Graham Davies wrote:


>--- In AVR-Chat@yahoogroups.com, Dave VanHorn <dvanhorn@d...> wrote:
>
> > I have some of the Olimex units,
> > they are just as good as the Atmel
> > ones apparently. :)
>
>Well, I originally invented the AVR ICE-Cube because I was totally
>disgusted with the poor quality of the Olimex JTAG ICE I bought. I
>think some problems may now have been solved, such as the procedure for
>loading in the Atmel software and operation below 4.5 volts, but I
>doubt that the PCB layout has been improved and that was very bad.

I haven't looked inside, but my entire use of the Olimex units so far has 
been at 3V.

>On the other hand, my personal circumstances have changed so that I
>don't need the income from ECROS Technology any more. I'm only in it
>now out of loyalty to the AVR community and it's increasingly hard to
>find the time to make, test and ship ICE-Cubes. If Brian wanted to put
>a JTAG interface on a MAVRIC I would give him the ICE-Cube design,
>including the bootloader (which isn't as straightforward as people like
>to think). If I were Brian, though, I would "stick to my knitting" if I
>knew my customers could pick up a JTAG interface for less than forty
>bucks.

I see that point as well.

When the Jtag was $300, it was hard to justify having two, but yet you 
should NEVER have only one of any critical equipment like that.   At $40, 
it's easy for me to buy a few, so that if one takes a hit, I'm still 
operational.

When you have one or less running around, the idea of having it built into 
the systems makes sense.

--- In AVR-Chat@yahoogroups.com, Dave VanHorn <dvanhorn@d...> wrote:

> I haven't looked inside, but my
> entire use of the Olimex units
> so far has been at 3V.

My Olimex JTAG ICE used an ATmega16, which is only specified down to 
4.5 volts. Now, in practice it is quite possible that an ATmega16 works 
down to 2.7 volts just as well as an ATmega16L. But, do you want to 
rely on that for a piece of diagnostic equipment that should be beyond 
reproach? Is it good design practice to run an ATmega16 at 3 volts? You 
may have an Olimex JTAG ICE with an ATmega16L or you may be running an 
ATmega16 outside its specified range and not know it.

The procedure to load the Atmel software in my Olimex involved taking 
the damned thing apart. This is how I discovered the above. If I hadn't 
noticed the MCU type, I would never have known it was not specified for 
use below 4.5 volts. I do not now trust Olimex as a supplier.

While I had the thing in pieces, I inspected the PCB layout. I have 
never seen worse. Ground and power were treated just like any other 
signal and routed all over the place. Again, is this what you want to 
be in the position of trusting while you're debugging sensitive or 
noisy equipment?

I'm not saying you should toss out your Olimex JTAG ICEs. If you're 
happy with them I suppose that's all that counts. I don't know what I 
am saying, really. It just bugs me that a piece of sloppy design like 
this succeeds in the market as well as painstaking and correct design 
because, well, I suppose for the most part it does seem to work.

Graham.

At 07:15 PM 3/29/2005, Graham Davies wrote:


>--- In AVR-Chat@yahoogroups.com, Dave VanHorn <dvanhorn@d...> wrote:
>
> > I haven't looked inside, but my
> > entire use of the Olimex units
> > so far has been at 3V.
>
>My Olimex JTAG ICE used an ATmega16, which is only specified down to
>4.5 volts. Now, in practice it is quite possible that an ATmega16 works
>down to 2.7 volts just as well as an ATmega16L. But, do you want to
>rely on that for a piece of diagnostic equipment that should be beyond
>reproach? Is it good design practice to run an ATmega16 at 3 volts? You
>may have an Olimex JTAG ICE with an ATmega16L or you may be running an
>ATmega16 outside its specified range and not know it.

Well, I guess I'll pop the top and check.
All of these low cost ices are compromise designs, I haven't seen one yet 
that terminates the cable properly like the atmel does.  I also have an 
atmel unit, which I would fall back on if there is any issue.
But, when I ordered these, I had reason to suspect that my jtag had gone to 
pieces, which turned out to be yet another avr studio "vacation day".


>The procedure to load the Atmel software in my Olimex involved taking
>the damned thing apart. This is how I discovered the above. If I hadn't
>noticed the MCU type, I would never have known it was not specified for
>use below 4.5 volts. I do not now trust Olimex as a supplier.

I didn't have to do this. I plugged it in, and it worked.

>While I had the thing in pieces, I inspected the PCB layout. I have
>never seen worse. Ground and power were treated just like any other
>signal and routed all over the place. Again, is this what you want to
>be in the position of trusting while you're debugging sensitive or
>noisy equipment?

Well, I haven't seen the board.  I'm a layout guy myself, and I rarely see 
anything that I like these days.

>I'm not saying you should toss out your Olimex JTAG ICEs. If you're
>happy with them I suppose that's all that counts. I don't know what I
>am saying, really. It just bugs me that a piece of sloppy design like
>this succeeds in the market as well as painstaking and correct design
>because, well, I suppose for the most part it does seem to work.

Well, if there's no operational difference, why would the customer 
differentiate?

--- In AVR-Chat@yahoogroups.com, Dave VanHorn <dvanhorn@d...> wrote:

> ... if there's no operational
> difference, why would the customer 
> differentiate?

I'm kind of surprised to have got to this point in the discussion. I 
thought my point would have been taken and now I think I'm just going 
to state the obvious and nobody will remember how we got here and what 
the hell I'm going on about.

The reason you care about design quality is that you can trust it. A 
poor quality design may work most of the time for some people and all 
of the time for most people. But, when you get into a tight spot you 
want to be able to trust your tools. You want tools that are designed 
to work in every reasonable situation. You want a JTAG interface that 
keeps on working if there is a lot of noise on the supply and does not 
inject noise into a circuit that is sensitive to supply noise. You want 
the interface to produce absolutely no EMI and to be insensitive to EMI 
when the test system generates it. The Atmel JTAG ICE probably meets 
these criteria. For $300 it should. If you don't want to pay $300, you 
might still prefer a good design to a shoddy one.

Graham.

At 06:39 PM 3/30/2005, Graham Davies wrote:


>--- In AVR-Chat@yahoogroups.com, Dave VanHorn <dvanhorn@d...> wrote:
>
> > ... if there's no operational
> > difference, why would the customer
> > differentiate?
>
>I'm kind of surprised to have got to this point in the discussion. I
>thought my point would have been taken and now I think I'm just going
>to state the obvious and nobody will remember how we got here and what
>the hell I'm going on about.
>
>The reason you care about design quality is that you can trust it. A
>poor quality design may work most of the time for some people and all
>of the time for most people.

I know that. Remember, I do this sort of thing for a living too.
But, when the customer is looking at the web page, deciding which to buy, 
you need to give him something to hold on to, to make the right decision.

I have gone to the point of adding lead weights in some products to make 
their perceived value higher.

The issues you are talking about are all things you discover (or not) after 
the purchase decision has been made.

>But, when you get into a tight spot you
>want to be able to trust your tools. You want tools that are designed
>to work in every reasonable situation. You want a JTAG interface that
>keeps on working if there is a lot of noise on the supply and does not
>inject noise into a circuit that is sensitive to supply noise. You want
>the interface to produce absolutely no EMI and to be insensitive to EMI
>when the test system generates it. The Atmel JTAG ICE probably meets
>these criteria. For $300 it should. If you don't want to pay $300, you
>might still prefer a good design to a shoddy one.

For one, I wasn't aware of these differences before I bought my olimex 
units, or all other things being equal, I would not have gone that way.
Put the data on your web site!  Show both boards, and explain the differences.
Have someone test the operating voltages and noise immunity. (it's better 
if it comes from a third party)
I'd be happy to review your unit, if you like, or I'm sure there are others 
who are able and willing.

Dave VanHorn wrote:
> At 06:39 PM 3/30/2005, Graham Davies wrote:
> 
> 
> 
>>--- In AVR-Chat@yahoogroups.com, Dave VanHorn <dvanhorn@d...> wrote:
>>
>>
>>>... if there's no operational
>>>difference, why would the customer
>>>differentiate?
>>
>>I'm kind of surprised to have got to this point in the discussion. I
>>thought my point would have been taken and now I think I'm just going
>>to state the obvious and nobody will remember how we got here and what
>>the hell I'm going on about.
>>
>>The reason you care about design quality is that you can trust it. A
>>poor quality design may work most of the time for some people and all
>>of the time for most people.
> 
> 
> I know that. Remember, I do this sort of thing for a living too.
> But, when the customer is looking at the web page, deciding which to buy, 
> you need to give him something to hold on to, to make the right decision.
> 
> I have gone to the point of adding lead weights in some products to make 
> their perceived value higher.
> 
> The issues you are talking about are all things you discover (or not) after 
> the purchase decision has been made.
> 
> 
>>But, when you get into a tight spot you
>>want to be able to trust your tools. You want tools that are designed
>>to work in every reasonable situation. You want a JTAG interface that
>>keeps on working if there is a lot of noise on the supply and does not
>>inject noise into a circuit that is sensitive to supply noise. You want
>>the interface to produce absolutely no EMI and to be insensitive to EMI
>>when the test system generates it. The Atmel JTAG ICE probably meets
>>these criteria. For $300 it should. If you don't want to pay $300, you
>>might still prefer a good design to a shoddy one.
> 
> 
> For one, I wasn't aware of these differences before I bought my olimex 
> units, or all other things being equal, I would not have gone that way.
> Put the data on your web site!  Show both boards, and explain the differences.
> Have someone test the operating voltages and noise immunity. (it's better 
> if it comes from a third party)
> I'd be happy to review your unit, if you like, or I'm sure there are others 
> who are able and willing.

I can offer to do independent testing, as I have just tested a few 
programmers for other chips (damn Pic's)

Lol

Regards,

Kat.

Wow Dave, this is about the same way my last few days have gone with 
the M128! Last week it was like when i waved a dead chicken over the 
boards it worked.  Today I had two new (better artwork/4 layer 
boards) boards with super stable supply rails and the darn things 
refused to program. I installed SP2 for the AVRStudio, updated the 
STK500 firmware, jtag firmware and still no joy.  Eventually, the 
jtag mkII was happy to indicate it was downloading my code but then 
it endlessly indicated it was in auto running mode, but never stopped 
at the usual entry point in the main program. STK500 did not work at 
all with the new boards.  I am miffed as to what is going on. I have 
not read all the replies to your post will do so now but I am glad to 
see i am not alone if feeling it is flaky to put it kindly.  I 
presume I will eventually find a solution but it sure is frustrating 
until you reach that point.

Al Welch

--- In AVR-Chat@yahoogroups.com, Dave VanHorn <dvanhorn@d...> wrote:
> 
> It's delivery day, and once again, my AVR tools have all decided to 
go nuts.
> Anyone have any ideas for preventing this garbage?
> 
> I have two AVRISPs, an STK-500, an Atmel Jtag ice, and two Olimex 
Jtag Ices.
> 
> I have three M128 target systems in hand. Supposed to be identical.
> 
> One is running, the other two not.  The two that don't run are 
fresh 
> builds, after getting to my goal with the first one.
> I don't dare touch the one that's running until I can trust my 
tools again.
> 
> I've checked everything as best I can on the new systems,  The 
chips are 
> the same date code, same 8.00 MHz crystals, same (proper value) 
caps, VCC 
> is in tolerance (3.0V), /Reset is pulled up with 1k.  The 
oscillator is 
> running a rail-to-rail sinewave of the right frequency, which at 
least 
> confirms that the CKOPT fuse has been set.
> 
> All the programmers say that they can program and verify the chip 
> successfully, and that all the fuses are set right. (including M103 
fuse, 
> CKOPT, WD, and BOD fuses)  Sometimes they fail to verify, or read 
wierd 
> fuse values, but they are all in agreement at the moment that 
everything's 
> fine.
> 
> All three Jtag ices agree that they can load the program, but 
cannot read 
> the SRAM, registers, or anything else, and cannot run, or even 
single-step.
> 
> The programmed targets do not run, and apparently do not even run a 
little. 
> The init code isn't even setting up the I/O ports, which is about 
the first 
> thing that I do after qualifying the reset, and setting up the 
stack.
> 
> I've rebooted everything multiple times, no help
> 
> It happens on at least four different computers, running XP Pro, 
and '98, 
> and with old and new studio, though USB serial ports and "legacy 
COM1" 
> (note, these are high end industrial USB serial boxen, not the $20 
junk)
> These are real machines with other software installed, that I 
actually use.
> 
> Basically, anything studio drives will pack it up at random times, 
for some 
> random duration.
> 
> 
> I've had this happen any number of times, and it always "goes away" 
after a 
> while, but I REALLY CAN"T AFFORD THIS SHIT ANYMORE. (anyone sensing 
a high 
> level of frustration here?)
> 
> At this point, I feel like taking all my AVR tools out into the 
parking 
> lot, making a pile of them, and pounding them into sand with a 
splitting maul.
> 
> I love the chips, but I really despise the tools.

At 08:55 PM 4/6/2005, alwelch93021 wrote:


>Wow Dave, this is about the same way my last few days have gone with
>the M128! Last week it was like when i waved a dead chicken over the
>boards it worked.  Today I had two new (better artwork/4 layer
>boards) boards with super stable supply rails and the darn things
>refused to program. I installed SP2 for the AVRStudio, updated the
>STK500 firmware, jtag firmware and still no joy.  Eventually, the
>jtag mkII was happy to indicate it was downloading my code but then
>it endlessly indicated it was in auto running mode, but never stopped
>at the usual entry point in the main program. STK500 did not work at
>all with the new boards.  I am miffed as to what is going on. I have
>not read all the replies to your post will do so now but I am glad to
>see i am not alone if feeling it is flaky to put it kindly.  I
>presume I will eventually find a solution but it sure is frustrating
>until you reach that point.

Yup..

On the thing with using common libraries, WHY DO IT?
I don't care how big the install is, I would rather have it sitting 
in it's own little corner with all it's own .ini files and DLL files, 
so that I know that it's going to work tomorrow.

Thing is though, it comes and goes,  like it just did for you, so I 
suspect registry more than I do the DLLs.

Hmm,

   You know, I have this happen with my Tiny26 boards too.  They just
start doing something "else" every once and a while and I can't figure
out why.  In most cases if I hold down the reset while I power the
boards on, they work.  And the vast majority of the time the boards
work fine, but every once and a while...  What the heck is it with
Atmel devices that they are so flaky?  I've tried every form of reset
circuit known to man to make my boards reliable, every kind of EMI
design trick in the book, and still, on occasion, a board goes flaky.

Hmmm, maybe I should just stay with PICs, they are dead solid reliable.

Hmmm,
DLC
P.S.
   Has anyone ever gotten Atmel to address this, or any other issue
you have found?  I've yet to get any response from their tech support
that didn't sound like a robot response from a "cheat sheet".


alwelch93021 wrote:
> 
> Wow Dave, this is about the same way my last few days have gone with 
> the M128! Last week it was like when i waved a dead chicken over the 
> boards it worked.  Today I had two new (better artwork/4 layer 
> boards) boards with super stable supply rails and the darn things 
> refused to program. I installed SP2 for the AVRStudio, updated the 
> STK500 firmware, jtag firmware and still no joy.  Eventually, the 
> jtag mkII was happy to indicate it was downloading my code but then 
> it endlessly indicated it was in auto running mode, but never stopped 
> at the usual entry point in the main program. STK500 did not work at 
> all with the new boards.  I am miffed as to what is going on. I have 
> not read all the replies to your post will do so now but I am glad to 
> see i am not alone if feeling it is flaky to put it kindly.  I 
> presume I will eventually find a solution but it sure is frustrating 
> until you reach that point.
> 
> Al Welch
> 
> --- In AVR-Chat@yahoogroups.com, Dave VanHorn <dvanhorn@d...> wrote:
> 
>>It's delivery day, and once again, my AVR tools have all decided to 
> 
> go nuts.
> 
>>Anyone have any ideas for preventing this garbage?
>>
>>I have two AVRISPs, an STK-500, an Atmel Jtag ice, and two Olimex 
> 
> Jtag Ices.
> 
>>I have three M128 target systems in hand. Supposed to be identical.
>>
>>One is running, the other two not.  The two that don't run are 
> 
> fresh 
> 
>>builds, after getting to my goal with the first one.
>>I don't dare touch the one that's running until I can trust my 
> 
> tools again.
> 
>>I've checked everything as best I can on the new systems,  The 
> 
> chips are 
> 
>>the same date code, same 8.00 MHz crystals, same (proper value) 
> 
> caps, VCC 
> 
>>is in tolerance (3.0V), /Reset is pulled up with 1k.  The 
> 
> oscillator is 
> 
>>running a rail-to-rail sinewave of the right frequency, which at 
> 
> least 
> 
>>confirms that the CKOPT fuse has been set.
>>
>>All the programmers say that they can program and verify the chip 
>>successfully, and that all the fuses are set right. (including M103 
> 
> fuse, 
> 
>>CKOPT, WD, and BOD fuses)  Sometimes they fail to verify, or read 
> 
> wierd 
> 
>>fuse values, but they are all in agreement at the moment that 
> 
> everything's 
> 
>>fine.
>>
>>All three Jtag ices agree that they can load the program, but 
> 
> cannot read 
> 
>>the SRAM, registers, or anything else, and cannot run, or even 
> 
> single-step.
> 
>>The programmed targets do not run, and apparently do not even run a 
> 
> little. 
> 
>>The init code isn't even setting up the I/O ports, which is about 
> 
> the first 
> 
>>thing that I do after qualifying the reset, and setting up the 
> 
> stack.
> 
>>I've rebooted everything multiple times, no help
>>
>>It happens on at least four different computers, running XP Pro, 
> 
> and '98, 
> 
>>and with old and new studio, though USB serial ports and "legacy 
> 
> COM1" 
> 
>>(note, these are high end industrial USB serial boxen, not the $20 
> 
> junk)
> 
>>These are real machines with other software installed, that I 
> 
> actually use.
> 
>>Basically, anything studio drives will pack it up at random times, 
> 
> for some 
> 
>>random duration.
>>
>>
>>I've had this happen any number of times, and it always "goes away" 
> 
> after a 
> 
>>while, but I REALLY CAN"T AFFORD THIS SHIT ANYMORE. (anyone sensing 
> 
> a high 
> 
>>level of frustration here?)
>>
>>At this point, I feel like taking all my AVR tools out into the 
> 
> parking 
> 
>>lot, making a pile of them, and pounding them into sand with a 
> 
> splitting maul.
> 
>>I love the chips, but I really despise the tools.

-- 
---------------------------------------
Dennis Clark    TTT Enterprises
---------------------------------------

Dennis Clark wrote:
> 
> Hmm,
> 
>    You know, I have this happen with my Tiny26 boards too.  They just
> start doing something "else" every once and a while and I can't figure
> out why.  In most cases if I hold down the reset while I power the
> boards on, they work.  And the vast majority of the time the boards
> work fine, but every once and a while...  What the heck is it with
> Atmel devices that they are so flaky?  I've tried every form of reset
> circuit known to man to make my boards reliable, every kind of EMI
> design trick in the book, and still, on occasion, a board goes flaky.
> 
> Hmmm, maybe I should just stay with PICs, they are dead solid reliable.
> 
> Hmmm,
> DLC

Well I have over 2000 units in the field with T26, running 16MHz with 5V 
psu, and not one is flaky, but then I know my supply is rock steady, the 
boards are in an EMC enclosure and all external wiring is well protected 
(by RC networks when they hit the inside of the enclosure).

I am yet to have a flaky product with ATMEL parts (except when I stuff 
up and forget to program things like the BOD enable fuse ;)

Regards,

Kat.

>
>I am yet to have a flaky product with ATMEL parts (except when I stuff
>up and forget to program things like the BOD enable fuse ;)

Or the CKOPT fuse!

I agree though, "Chips of Steel, Tools of Jello".

Kathy Quinlan wrote:
> Dennis Clark wrote:
> 
>>Hmm,
>>
>>   You know, I have this happen with my Tiny26 boards too.  They just
>>start doing something "else" every once and a while and I can't figure
>>out why.  In most cases if I hold down the reset while I power the
>>boards on, they work.  And the vast majority of the time the boards
>>work fine, but every once and a while...  What the heck is it with
>>Atmel devices that they are so flaky?  I've tried every form of reset
>>circuit known to man to make my boards reliable, every kind of EMI
>>design trick in the book, and still, on occasion, a board goes flaky.
>>
>>Hmmm, maybe I should just stay with PICs, they are dead solid reliable.
>>
>>Hmmm,
>>DLC
> 
> 
> Well I have over 2000 units in the field with T26, running 16MHz with 5V 
> psu, and not one is flaky, but then I know my supply is rock steady, the 
> boards are in an EMC enclosure and all external wiring is well protected 
> (by RC networks when they hit the inside of the enclosure).
> 
> I am yet to have a flaky product with ATMEL parts (except when I stuff 
> up and forget to program things like the BOD enable fuse ;)

   Hmm, now that you mention it...  Let me check that fuse bit, I _may_
have "stuffed up" and forgotten that on this board...

DLC

> Regards,
> 
> Kat.


-- 
---------------------------------------
Dennis Clark    TTT Enterprises
---------------------------------------

Ron wrote:
> It could be a problem of "slowly rising power". On most Atmel chips
> you can program the fuses to get a longer start up time, thus
> delaying the chip starting to run until the power is adequate. Ron

   I do use the 64ms slow startup, especially since I'm using the 
internal RC oscillator for this project.  Good comment though, I've 
tried this before with the fast rise and it doesn't work.

DLC

>     ----- Original Message -----
>     *From:* Dennis Clark <mailto:dlc@frii.com>
>     *To:* AVR-Chat@yahoogroups.com <mailto:AVR-Chat@yahoogroups.com>
>     *Sent:* Thursday, 07 April, 2005 12:19 PM
>     *Subject:* Re: [AVR-Chat] Re: Oh, I am so tired of this..
> 
> 
>     Hmm,
> 
>        You know, I have this happen with my Tiny26 boards too.  They just
>     start doing something "else" every once and a while and I can't figure
>     out why.  In most cases if I hold down the reset while I power the
>     boards on, they work.  And the vast majority of the time the boards
>     work fine, but every once and a while...  What the heck is it with
>     Atmel devices that they are so flaky?  I've tried every form of reset
>     circuit known to man to make my boards reliable, every kind of EMI
>     design trick in the book, and still, on occasion, a board goes flaky.
> 
>     Hmmm, maybe I should just stay with PICs, they are dead solid reliable.
> 
>     Hmmm,
>     DLC
>     P.S.
>        Has anyone ever gotten Atmel to address this, or any other issue
>     you have found?  I've yet to get any response from their tech support
>     that didn't sound like a robot response from a "cheat sheet".
> 
> 
>     alwelch93021 wrote:
>      >
>      > Wow Dave, this is about the same way my last few days have gone with
>      > the M128! Last week it was like when i waved a dead chicken over the
>      > boards it worked.  Today I had two new (better artwork/4 layer
>      > boards) boards with super stable supply rails and the darn things
>      > refused to program. I installed SP2 for the AVRStudio, updated the
>      > STK500 firmware, jtag firmware and still no joy.  Eventually, the
>      > jtag mkII was happy to indicate it was downloading my code but then
>      > it endlessly indicated it was in auto running mode, but never
>     stopped
>      > at the usual entry point in the main program. STK500 did not work at
>      > all with the new boards.  I am miffed as to what is going on. I have
>      > not read all the replies to your post will do so now but I am
>     glad to
>      > see i am not alone if feeling it is flaky to put it kindly.  I
>      > presume I will eventually find a solution but it sure is frustrating
>      > until you reach that point.
>      >
>      > Al Welch
>      >
>      > --- In AVR-Chat@yahoogroups.com, Dave VanHorn <dvanhorn@d...> wrote:
>      >
>      >>It's delivery day, and once again, my AVR tools have all decided to
>      >
>      > go nuts.
>      >
>      >>Anyone have any ideas for preventing this garbage?
>      >>
>      >>I have two AVRISPs, an STK-500, an Atmel Jtag ice, and two Olimex
>      >
>      > Jtag Ices.
>      >
>      >>I have three M128 target systems in hand. Supposed to be identical.
>      >>
>      >>One is running, the other two not.  The two that don't run are
>      >
>      > fresh
>      >
>      >>builds, after getting to my goal with the first one.
>      >>I don't dare touch the one that's running until I can trust my
>      >
>      > tools again.
>      >
>      >>I've checked everything as best I can on the new systems,  The
>      >
>      > chips are
>      >
>      >>the same date code, same 8.00 MHz crystals, same (proper value)
>      >
>      > caps, VCC
>      >
>      >>is in tolerance (3.0V), /Reset is pulled up with 1k.  The
>      >
>      > oscillator is
>      >
>      >>running a rail-to-rail sinewave of the right frequency, which at
>      >
>      > least
>      >
>      >>confirms that the CKOPT fuse has been set.
>      >>
>      >>All the programmers say that they can program and verify the chip
>      >>successfully, and that all the fuses are set right. (including M103
>      >
>      > fuse,
>      >
>      >>CKOPT, WD, and BOD fuses)  Sometimes they fail to verify, or read
>      >
>      > wierd
>      >
>      >>fuse values, but they are all in agreement at the moment that
>      >
>      > everything's
>      >
>      >>fine.
>      >>
>      >>All three Jtag ices agree that they can load the program, but
>      >
>      > cannot read
>      >
>      >>the SRAM, registers, or anything else, and cannot run, or even
>      >
>      > single-step.
>      >
>      >>The programmed targets do not run, and apparently do not even run a
>      >
>      > little.
>      >
>      >>The init code isn't even setting up the I/O ports, which is about
>      >
>      > the first
>      >
>      >>thing that I do after qualifying the reset, and setting up the
>      >
>      > stack.
>      >
>      >>I've rebooted everything multiple times, no help
>      >>
>      >>It happens on at least four different computers, running XP Pro,
>      >
>      > and '98,
>      >
>      >>and with old and new studio, though USB serial ports and "legacy
>      >
>      > COM1"
>      >
>      >>(note, these are high end industrial USB serial boxen, not the $20
>      >
>      > junk)
>      >
>      >>These are real machines with other software installed, that I
>      >
>      > actually use.
>      >
>      >>Basically, anything studio drives will pack it up at random times,
>      >
>      > for some
>      >
>      >>random duration.
>      >>
>      >>
>      >>I've had this happen any number of times, and it always "goes away"
>      >
>      > after a
>      >
>      >>while, but I REALLY CAN"T AFFORD THIS SHIT ANYMORE. (anyone sensing
>      >
>      > a high
>      >
>      >>level of frustration here?)
>      >>
>      >>At this point, I feel like taking all my AVR tools out into the
>      >
>      > parking
>      >
>      >>lot, making a pile of them, and pounding them into sand with a
>      >
>      > splitting maul.
>      >
>      >>I love the chips, but I really despise the tools.
> 
>     -- 
>     ---------------------------------------
>     Dennis Clark    TTT Enterprises
>     ---------------------------------------


-- 
---------------------------------------
Dennis Clark    TTT Enterprises
---------------------------------------

Today will debugging I had the JTAG MKII runining with it and it had 
downloaded just fine a few minuts ago and when i went to do it again 
it errored out and said power supply was down.  Quick check of the 
power with my fluke meter showed 4.99 VDC rock solid supply.

Reset circuit is a Texas Instrument TPS3828-50 with open drain reset 
with 10k pull up and 0.01 bypass on input. M128 is well bypassed, 
supplies on their own planes. 

Al Welch

--- In AVR-Chat@yahoogroups.com, "Ron" <drait1@y...> wrote:
> It could be a problem of "slowly rising power". On most Atmel chips
> you can program the fuses to get a longer start up time, thus
> delaying the chip starting to run until the power is adequate. Ron
>   ----- Original Message ----- 
>   From: Dennis Clark 
>   To: AVR-Chat@yahoogroups.com 
>   Sent: Thursday, 07 April, 2005 12:19 PM
>   Subject: Re: [AVR-Chat] Re: Oh, I am so tired of this..
> 
> 
> 
>   Hmm,
> 
>      You know, I have this happen with my Tiny26 boards too.  They 
just
>   start doing something "else" every once and a while and I can't 
figure
>   out why.  In most cases if I hold down the reset while I power 
the
>   boards on, they work.  And the vast majority of the time the 
boards
>   work fine, but every once and a while...  What the heck is it 
with
>   Atmel devices that they are so flaky?  I've tried every form of 
reset
>   circuit known to man to make my boards reliable, every kind of 
EMI
>   design trick in the book, and still, on occasion, a board goes 
flaky.
> 
>   Hmmm, maybe I should just stay with PICs, they are dead solid 
reliable.
> 
>   Hmmm,
>   DLC
>   P.S.
>      Has anyone ever gotten Atmel to address this, or any other 
issue
>   you have found?  I've yet to get any response from their tech 
support
>   that didn't sound like a robot response from a "cheat sheet".
> 
> 
>   alwelch93021 wrote:
>   > 
>   > Wow Dave, this is about the same way my last few days have 
gone with 
>   > the M128! Last week it was like when i waved a dead chicken 
over the 
>   > boards it worked.  Today I had two new (better artwork/4 layer 
>   > boards) boards with super stable supply rails and the darn 
things 
>   > refused to program. I installed SP2 for the AVRStudio, updated 
the 
>   > STK500 firmware, jtag firmware and still no joy.  Eventually, 
the 
>   > jtag mkII was happy to indicate it was downloading my code but 
then 
>   > it endlessly indicated it was in auto running mode, but never 
stopped 
>   > at the usual entry point in the main program. STK500 did not 
work at 
>   > all with the new boards.  I am miffed as to what is going on. 
I have 
>   > not read all the replies to your post will do so now but I am 
glad to 
>   > see i am not alone if feeling it is flaky to put it kindly.  I 
>   > presume I will eventually find a solution but it sure is 
frustrating 
>   > until you reach that point.
>   > 
>   > Al Welch
>   > 
>   > --- In AVR-Chat@yahoogroups.com, Dave VanHorn <dvanhorn@d...> 
wrote:
>   > 
>   >>It's delivery day, and once again, my AVR tools have all 
decided to 
>   > 
>   > go nuts.
>   > 
>   >>Anyone have any ideas for preventing this garbage?
>   >>
>   >>I have two AVRISPs, an STK-500, an Atmel Jtag ice, and two 
Olimex 
>   > 
>   > Jtag Ices.
>   > 
>   >>I have three M128 target systems in hand. Supposed to be 
identical.
>   >>
>   >>One is running, the other two not.  The two that don't run are 
>   > 
>   > fresh 
>   > 
>   >>builds, after getting to my goal with the first one.
>   >>I don't dare touch the one that's running until I can trust my 
>   > 
>   > tools again.
>   > 
>   >>I've checked everything as best I can on the new systems,  The 
>   > 
>   > chips are 
>   > 
>   >>the same date code, same 8.00 MHz crystals, same (proper 
value) 
>   > 
>   > caps, VCC 
>   > 
>   >>is in tolerance (3.0V), /Reset is pulled up with 1k.  The 
>   > 
>   > oscillator is 
>   > 
>   >>running a rail-to-rail sinewave of the right frequency, which 
at 
>   > 
>   > least 
>   > 
>   >>confirms that the CKOPT fuse has been set.
>   >>
>   >>All the programmers say that they can program and verify the 
chip 
>   >>successfully, and that all the fuses are set right. (including 
M103 
>   > 
>   > fuse, 
>   > 
>   >>CKOPT, WD, and BOD fuses)  Sometimes they fail to verify, or 
read 
>   > 
>   > wierd 
>   > 
>   >>fuse values, but they are all in agreement at the moment that 
>   > 
>   > everything's 
>   > 
>   >>fine.
>   >>
>   >>All three Jtag ices agree that they can load the program, but 
>   > 
>   > cannot read 
>   > 
>   >>the SRAM, registers, or anything else, and cannot run, or even 
>   > 
>   > single-step.
>   > 
>   >>The programmed targets do not run, and apparently do not even 
run a 
>   > 
>   > little. 
>   > 
>   >>The init code isn't even setting up the I/O ports, which is 
about 
>   > 
>   > the first 
>   > 
>   >>thing that I do after qualifying the reset, and setting up the 
>   > 
>   > stack.
>   > 
>   >>I've rebooted everything multiple times, no help
>   >>
>   >>It happens on at least four different computers, running XP 
Pro, 
>   > 
>   > and '98, 
>   > 
>   >>and with old and new studio, though USB serial ports 
and "legacy 
>   > 
>   > COM1" 
>   > 
>   >>(note, these are high end industrial USB serial boxen, not the 
$20 
>   > 
>   > junk)
>   > 
>   >>These are real machines with other software installed, that I 
>   > 
>   > actually use.
>   > 
>   >>Basically, anything studio drives will pack it up at random 
times, 
>   > 
>   > for some 
>   > 
>   >>random duration.
>   >>
>   >>
>   >>I've had this happen any number of times, and it always "goes 
away" 
>   > 
>   > after a 
>   > 
>   >>while, but I REALLY CAN"T AFFORD THIS SHIT ANYMORE. (anyone 
sensing 
>   > 
>   > a high 
>   > 
>   >>level of frustration here?)
>   >>
>   >>At this point, I feel like taking all my AVR tools out into 
the 
>   > 
>   > parking 
>   > 
>   >>lot, making a pile of them, and pounding them into sand with a 
>   > 
>   > splitting maul.
>   > 
>   >>I love the chips, but I really despise the tools.
> 
>   -- 
>   ---------------------------------------
>   Dennis Clark    TTT Enterprises
>   ---------------------------------------
> 
> 
> 
> 
> 
> -------------------------------------------------------------------
-----------
>   Yahoo! Groups Links
> 
>     a.. To visit your group on the web, go to:
>     http://groups.yahoo.com/group/AVR-Chat/
>       
>     b.. To unsubscribe from this group, send an email to:
>     AVR-Chat-unsubscribe@yahoogroups.com
>       
>     c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms 
of Service.