AVR-Chat

At 07:58 AM 3/07/2007, you wrote:
>What I'm wrestling with at the moment, is what the SONAR wants though.

It MUST be that darned PIC messing with your mind :-)

>but you CANNOT read the data using the broadcast address..

That makes sense otherwise all units would try and respond at the same
time and...crash...

Must admit it is getting interesting though, I tried to compile the test
code on Brian Dean's website but unfortunately it must have been written
with an earlier version of WinAVR and the new one does not want to compile.

I tried updating the files but it would take me too long and don't have
the time right now. Of course for a GCC guru it may only take a few minutes
:-) (yes this is a hint for the C gurus)



Regards

John Samperi

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


-- 
No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.476 / Virus Database: 269.9.14/883 - Release Date: 1/07/2007 12:19 PM

On 7/2/07, John Samperi <samperi@ampertronics.com.au> wrote:
> At 07:58 AM 3/07/2007, you wrote:
> >What I'm wrestling with at the moment, is what the SONAR wants though.
>
> It MUST be that darned PIC messing with your mind :-)

Yup.. Pic rays..

> >but you CANNOT read the data using the broadcast address..
>
> That makes sense otherwise all units would try and respond at the same
> time and...crash...

True, but if you have only one device on the bus, then why not let it respond.
The thing that bugs me is that this isn't a documented behaviour, and
their support guys said that what I was doing (including the broadcast
address) ought to be working.


> Must admit it is getting interesting though, I tried to compile the test
> code on Brian Dean's website but unfortunately it must have been written
> with an earlier version of WinAVR and the new one does not want to compile.

The second write of the address seems broken, unless I'm reading it
wrong, he's setting up to not get an ack but testing for the ack in
the result code.

Minimum 4 times a day scrub with lye soap and a scrub brush or a 
scouring pad, rinse with clorox water.  Do this for a week after each 
PIC project and you should be okay.  A saturated solution of NaCl in 
water will also do as a substitute for the clorox water and should do 
the trick.  With time, after a couple of projects, you'll decide a PIC 
isn't worth the pain.

I met one of the guys on this list several years ago on another...and he 
decided to start with PICs.  I noticed he listed all of his PIC tools 
for sale soon after he tried an AVR project.


REB



David VanHorn wrote:

>On 7/2/07, John Samperi <samperi@ampertronics.com.au> wrote:
>  
>
>>At 07:58 AM 3/07/2007, you wrote:
>>    
>>
>>>What I'm wrestling with at the moment, is what the SONAR wants though.
>>>      
>>>
>>It MUST be that darned PIC messing with your mind :-)
>>    
>>
>
>Yup.. Pic rays..
>
>  
>
>>>but you CANNOT read the data using the broadcast address..
>>>      
>>>
>>That makes sense otherwise all units would try and respond at the same
>>time and...crash...
>>    
>>
>
>True, but if you have only one device on the bus, then why not let it respond.
>The thing that bugs me is that this isn't a documented behaviour, and
>their support guys said that what I was doing (including the broadcast
>address) ought to be working.
>
>
>  
>
>>Must admit it is getting interesting though, I tried to compile the test
>>code on Brian Dean's website but unfortunately it must have been written
>>with an earlier version of WinAVR and the new one does not want to compile.
>>    
>>
>
>The second write of the address seems broken, unless I'm reading it
>wrong, he's setting up to not get an ack but testing for the ack in
>the result code.
>  
>

I'm getting sonar data now.  On top of everything else, the one sonar
unit I was working with, out of the four I have, was bad!

On 7/2/07, Roy E. Burrage <RBurrage@bellsouth.net> wrote:
> Minimum 4 times a day scrub with lye soap and a scrub brush or a
> scouring pad, rinse with clorox water.  Do this for a week after each
> PIC project and you should be okay.  A saturated solution of NaCl in
> water will also do as a substitute for the clorox water and should do
> the trick.  With time, after a couple of projects, you'll decide a PIC
> isn't worth the pain.
>
> I met one of the guys on this list several years ago on another...and he
> decided to start with PICs.  I noticed he listed all of his PIC tools
> for sale soon after he tried an AVR project.
>
>
> REB
>
>
>
> David VanHorn wrote:
>
> >On 7/2/07, John Samperi <samperi@ampertronics.com.au> wrote:
> >
> >
> >>At 07:58 AM 3/07/2007, you wrote:
> >>
> >>
> >>>What I'm wrestling with at the moment, is what the SONAR wants though.
> >>>
> >>>
> >>It MUST be that darned PIC messing with your mind :-)
> >>
> >>
> >
> >Yup.. Pic rays..
> >
> >
> >
> >>>but you CANNOT read the data using the broadcast address..
> >>>
> >>>
> >>That makes sense otherwise all units would try and respond at the same
> >>time and...crash...
> >>
> >>
> >
> >True, but if you have only one device on the bus, then why not let it respond.
> >The thing that bugs me is that this isn't a documented behaviour, and
> >their support guys said that what I was doing (including the broadcast
> >address) ought to be working.
> >
> >
> >
> >
> >>Must admit it is getting interesting though, I tried to compile the test
> >>code on Brian Dean's website but unfortunately it must have been written
> >>with an earlier version of WinAVR and the new one does not want to compile.
> >>
> >>
> >
> >The second write of the address seems broken, unless I'm reading it
> >wrong, he's setting up to not get an ack but testing for the ack in
> >the result code.
> >
> >
>
>
>
> Yahoo! Groups Links
>
>
>
>

Bah humbug.  Another religious war.  I love the AVR, but I hate Atmel. 
Their tools are weak, they replace parts (with parts that aren't pin 
compatable) at whim and sometimes are difficult to even get in the US. 
However, they are the only choice of cheap micros for Mac or Linux 
developers, so, I endure.  On the other hand, I hate the PIC 
architecture but in general love the support that I get from Microchip. 
  So, as usual, pick your poison.

DLC

Roy E. Burrage wrote:
> Minimum 4 times a day scrub with lye soap and a scrub brush or a 
> scouring pad, rinse with clorox water.  Do this for a week after each 
> PIC project and you should be okay.  A saturated solution of NaCl in 
> water will also do as a substitute for the clorox water and should do 
> the trick.  With time, after a couple of projects, you'll decide a PIC 
> isn't worth the pain.
> 
> I met one of the guys on this list several years ago on another...and he 
> decided to start with PICs.  I noticed he listed all of his PIC tools 
> for sale soon after he tried an AVR project.
> 
> 
> REB
> 
> 
> 
> David VanHorn wrote:
> 
> 
>>On 7/2/07, John Samperi <samperi@ampertronics.com.au> wrote:
>> 
>>
>>
>>>At 07:58 AM 3/07/2007, you wrote:
>>>   
>>>
>>>
>>>>What I'm wrestling with at the moment, is what the SONAR wants though.
>>>>     
>>>>
>>>
>>>It MUST be that darned PIC messing with your mind :-)
>>>   
>>>
>>
>>Yup.. Pic rays..
>>
>> 
>>
>>
>>>>but you CANNOT read the data using the broadcast address..
>>>>     
>>>>
>>>
>>>That makes sense otherwise all units would try and respond at the same
>>>time and...crash...
>>>   
>>>
>>
>>True, but if you have only one device on the bus, then why not let it respond.
>>The thing that bugs me is that this isn't a documented behaviour, and
>>their support guys said that what I was doing (including the broadcast
>>address) ought to be working.
>>
>>
>> 
>>
>>
>>>Must admit it is getting interesting though, I tried to compile the test
>>>code on Brian Dean's website but unfortunately it must have been written
>>>with an earlier version of WinAVR and the new one does not want to compile.
>>>   
>>>
>>
>>The second write of the address seems broken, unless I'm reading it
>>wrong, he's setting up to not get an ack but testing for the ack in
>>the result code.
>> 
>>
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 

-- 
-------------------------------------------------
Dennis Clark          TTT Enterprises
www.techtoystoday.com
-------------------------------------------------

At 02:14 PM 3/07/2007, you wrote:
>they replace parts (with parts that aren't pin
>compatable)

Can you please give an example of the above? As far as I can
tell they have made pin AND pretty much code compatible upgrades
for all of their chips, at least since 1999.

Regards

John Samperi

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


-- 
No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.476 / Virus Database: 269.9.14/884 - Release Date: 2/07/2007 3:35 PM

No religious war, just a statement of fact.

If you can cite an example of replacing a chip without the replacement 
being both pin and code compatible I'd like to see it.  That hasn't been 
my experience in the past 10 years or so.  Not only do they replace with 
pin and code computability, but they give more functionality for a lower 
price.

Availability...show me one manufacturer who didn't have delivery 
problems over the past 10 years.  I can remember LM7805, LM78xx chips in 
general, being on allocation several years ago.  Is there a more common 
chip on the face of this planet?  The only time I've had a problem with 
AVR availability has been when I had to go to someone other than 
Digi-Key or Mouser for stock and had to order larger quantities than I 
wanted.  The rep was generally able to help there, though.

Tools?  Are we going to complain about free software tools?  Their 
hardware tools are also much more reasonably priced.

Support?  Admittedly, the local manufacturers' rep firm leaves a bit to 
be desired in technical expertise, but the factory guy has been very 
supportive and the local rep has been very willing to bring what ever 
other resources might have been necessary.  Several of them have been, 
for that matter.  I'll state right here and now that DuRant Lewis in the 
Raleigh, NC, office has been nothing but supportive.  He has gone so far 
as to FedEx a replacement ISP to me when I got stupid one night and blew 
mine up...at no charge.

Atmel might be a bit less free with their samples.  However, a real 
company isn't going to balk at paying a couple of bucks for their 
parts.  I've not had a problem getting samples but have had to ask for 
them and explain the application rather than being able to order on-line 
as with Brand X.

The bottom line seems to be that Atmel has focused their products and 
support toward real industrial and commercial applications rather than 
hobby applications.  To be sure, both have a place.  We just have to 
decide where we, as developers, are going to focus our efforts too.


REB



dlc wrote:

>Bah humbug.  Another religious war.  I love the AVR, but I hate Atmel. 
>Their tools are weak, they replace parts (with parts that aren't pin 
>compatable) at whim and sometimes are difficult to even get in the US. 
>However, they are the only choice of cheap micros for Mac or Linux 
>developers, so, I endure.  On the other hand, I hate the PIC 
>architecture but in general love the support that I get from Microchip. 
>  So, as usual, pick your poison.
>
>DLC
>
>Roy E. Burrage wrote:
>  
>
>>Minimum 4 times a day scrub with lye soap and a scrub brush or a 
>>scouring pad, rinse with clorox water.  Do this for a week after each 
>>PIC project and you should be okay.  A saturated solution of NaCl in 
>>water will also do as a substitute for the clorox water and should do 
>>the trick.  With time, after a couple of projects, you'll decide a PIC 
>>isn't worth the pain.
>>
>>I met one of the guys on this list several years ago on another...and he 
>>decided to start with PICs.  I noticed he listed all of his PIC tools 
>>for sale soon after he tried an AVR project.
>>
>>
>>REB
>>
>>
>>
>>David VanHorn wrote:
>>
>>
>>    
>>
>>>On 7/2/07, John Samperi <samperi@ampertronics.com.au> wrote:
>>>
>>>
>>>
>>>      
>>>
>>>>At 07:58 AM 3/07/2007, you wrote:
>>>>  
>>>>
>>>>
>>>>        
>>>>
>>>>>What I'm wrestling with at the moment, is what the SONAR wants though.
>>>>>    
>>>>>
>>>>>          
>>>>>
>>>>It MUST be that darned PIC messing with your mind :-)
>>>>  
>>>>
>>>>        
>>>>
>>>Yup.. Pic rays..
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>>but you CANNOT read the data using the broadcast address..
>>>>>    
>>>>>
>>>>>          
>>>>>
>>>>That makes sense otherwise all units would try and respond at the same
>>>>time and...crash...
>>>>  
>>>>
>>>>        
>>>>
>>>True, but if you have only one device on the bus, then why not let it respond.
>>>The thing that bugs me is that this isn't a documented behaviour, and
>>>their support guys said that what I was doing (including the broadcast
>>>address) ought to be working.
>>>
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>Must admit it is getting interesting though, I tried to compile the test
>>>>code on Brian Dean's website but unfortunately it must have been written
>>>>with an earlier version of WinAVR and the new one does not want to compile.
>>>>  
>>>>
>>>>        
>>>>
>>>The second write of the address seems broken, unless I'm reading it
>>>wrong, he's setting up to not get an ack but testing for the ack in
>>>the result code.
>>>
>>>
>>>      
>>>
>>
>> 
>>Yahoo! Groups Links
>>
>>
>>
>>    
>>
>
>  
>

To be fair, this didn't happen recently but a few years ago.  It was one
of their lower pin count ones, 20 pins or so.  I forget which one, but one
I was using got obsoleted and the rep said to use a part that was not pin
compatable.  The details are vague to me now but they made an impression
then.  THose first impressions, especially negative ones can be hard to
shake.

As I said, I love the AVR chip, but my experiences (others may bave
different ones) with support have been spotty here in the US.  THAT said,
unlike the PIC, I can work on my chosen platform, the Macintosh which is a
big plus to me.  The OS folks working with AVRDude for instance are very
responsive.  Now if there was just a nice IDE to use with the GCC toolset
I'd ditch my PIC investment entirely.

DLC

> At 02:14 PM 3/07/2007, you wrote:
>>they replace parts (with parts that aren't pin
>>compatable)
>
> Can you please give an example of the above? As far as I can
> tell they have made pin AND pretty much code compatible upgrades
> for all of their chips, at least since 1999.
>
> Regards
>
> John Samperi
>
> ********************************************************
> Ampertronics Pty. Ltd.
> 11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
> Tel. (02) 9674-6495       Fax (02) 9674-8745
> Email: john@ampertronics.com.au
> Website  http://www.ampertronics.com.au
> *Electronic Design * Custom Products * Contract Assembly
> ********************************************************
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.476 / Virus Database: 269.9.14/884 - Release Date: 2/07/2007
> 3:35 PM
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>