🚀 go-pugleaf

"David L. Jones" <altzone@gmail.com> wrote in message 
news:a7nGm.354$hJ2.98@newsfe13.iad...
> You aren't going to believe this...
>
> I recently reviewed the new Microchip PICkit3 compared to the old PICkit2 
> and pretty much hammered the people responsible on behalf of those who 
> have found the PICkit3 upgrade rather lacking:
> http://www.eevblog.com/2009/10/21/eevblog-39-pickit-3-programmerdebugger-review/
>
> At it turns out, not surprisingly the video made it's way all around the 
> Microchip offices, even to the desk of their CEO.
> As with any multi billion dollar corporation, I expected either deathly 
> silence or a nasty letter from their lawyers.
>
> But it turns out Microchip really do care about their products and 
> customers, and really do listen, so they seriously took it as constructive 
> criticism.
>
> So not only was my blog well received at Microchip, I got a lengthy call 
> from none other than the Microchip CEO Steve Sanghi, thanking me for the 
> blog and raising the issues. He pointed out a few factual errors which was 
> fair enough, but admitted they could have done the PICkit 3 better and 
> most importantly are working to fix the issues and give customers what 
> they expect.
>
> They have even posted this hillarious video response in record time:
> http://www.youtube.com/watch?v=3YUvlrVlNao
>
> I am absolutely blown away by their honesty and responsiveness, and it 
> starts from their CEO down.
> Two thumbs up to Steve Sanghi and the guys and gals at Microchip!

**Nice one Dave.


-- 
Trevor Wilson
www.rageaudio.com.au

"Trevor Wilson" <trevor@SPAMBLOCKrageaudio.com.au> wrote in message 
news:7kud90F3arfetU1@mid.individual.net...
>
> "David L. Jones" <altzone@gmail.com> wrote in message 
> news:a7nGm.354$hJ2.98@newsfe13.iad...
>> You aren't going to believe this...
>>
>> I recently reviewed the new Microchip PICkit3 compared to the old PICkit2 
>> and pretty much hammered the people responsible on behalf of those who 
>> have found the PICkit3 upgrade rather lacking:
>> http://www.eevblog.com/2009/10/21/eevblog-39-pickit-3-programmerdebugger-review/
>>
>> At it turns out, not surprisingly the video made it's way all around the 
>> Microchip offices, even to the desk of their CEO.
>> As with any multi billion dollar corporation, I expected either deathly 
>> silence or a nasty letter from their lawyers.
>>
>> But it turns out Microchip really do care about their products and 
>> customers, and really do listen, so they seriously took it as 
>> constructive criticism.
>>
>> So not only was my blog well received at Microchip, I got a lengthy call 
>> from none other than the Microchip CEO Steve Sanghi, thanking me for the 
>> blog and raising the issues. He pointed out a few factual errors which 
>> was fair enough, but admitted they could have done the PICkit 3 better 
>> and most importantly are working to fix the issues and give customers 
>> what they expect.
>>
>> They have even posted this hillarious video response in record time:
>> http://www.youtube.com/watch?v=3YUvlrVlNao
>>
>> I am absolutely blown away by their honesty and responsiveness, and it 
>> starts from their CEO down.
>> Two thumbs up to Steve Sanghi and the guys and gals at Microchip!
>
> **Nice one Dave.
>
>
> -- 
> Trevor Wilson
> www.rageaudio.com.au
>
>

The power of one person (Dave)
Well done!!

JERD 

David L. Jones wrote:
> You aren't going to believe this...
> 
> I recently reviewed the new Microchip PICkit3 compared to the old PICkit2 
> and pretty much hammered the people responsible on behalf of those who have 
> found the PICkit3 upgrade rather lacking:
> http://www.eevblog.com/2009/10/21/eevblog-39-pickit-3-programmerdebugger-review/
> 
> At it turns out, not surprisingly the video made it's way all around the 
> Microchip offices, even to the desk of their CEO.
> As with any multi billion dollar corporation, I expected either deathly 
> silence or a nasty letter from their lawyers.
> 
> But it turns out Microchip really do care about their products and 
> customers, and really do listen, so they seriously took it as constructive 
> criticism.
> 
> So not only was my blog well received at Microchip, I got a lengthy call 
> from none other than the Microchip CEO Steve Sanghi, thanking me for the 
> blog and raising the issues. He pointed out a few factual errors which was 
> fair enough, but admitted they could have done the PICkit 3 better and most 
> importantly are working to fix the issues and give customers what they 
> expect.
> 
> They have even posted this hillarious video response in record time:
> http://www.youtube.com/watch?v=3YUvlrVlNao
> 
> I am absolutely blown away by their honesty and responsiveness, and it 
> starts from their CEO down.
> Two thumbs up to Steve Sanghi and the guys and gals at Microchip!
> 
> Dave.
> 

I'll take a look at the PIC for my next project.

-- 
Dirk

http://www.transcendence.me.uk/ - Transcendence UK
http://www.theconsensus.org/ - A UK political party
http://www.blogtalkradio.com/onetribe - Occult Talk Show

"David L. Jones" <altzone@gmail.com> writes:
> http://www.youtube.com/watch?v=3YUvlrVlNao

Sigh, I've been in that type of meeting before.  Not as Mr Head, of
course.

DJ Delorie wrote:
> "David L. Jones" <altzone@gmail.com> writes:
>> http://www.youtube.com/watch?v=3YUvlrVlNao
> 
> Sigh, I've been in that type of meeting before.  Not as Mr Head, of
> course.


What's the PIC architecture like these days?, I heard it was always
pretty messy in terms of memory and a real pain to program in assembly.

   Still it can't be much worse than some of the MAXQ series.

Mark Harriss wrote:
> DJ Delorie wrote:
>> "David L. Jones" <altzone@gmail.com> writes:
>>> http://www.youtube.com/watch?v=3YUvlrVlNao
>>
>> Sigh, I've been in that type of meeting before.  Not as Mr Head, of
>> course.
>
>
> What's the PIC architecture like these days?, I heard it was always
> pretty messy in terms of memory and a real pain to program in
> assembly.

Tons better.
They have the PIC18 series which is more C friendly than the old 16 series, 
the 16 bit PIC24 series which is quite nice, and the new 32 bit PIC32 series 
based on a MIPS 4K core. Plus the dsPIC too.
And why would you want to program in assembler anyway for all but niche 
areas?

Even the old 16 series is not messy if you use a good C compiler, it takes 
care of any issues for you.

Dave.

-- 
================================================
Check out my Electronics Engineering Video Blog & Podcast:
http://www.eevblog.com

Mark Harriss wrote:
> DJ Delorie wrote:
>> "David L. Jones" <altzone@gmail.com> writes:
>>> http://www.youtube.com/watch?v=3YUvlrVlNao
>>
>> Sigh, I've been in that type of meeting before.  Not as Mr Head, of
>> course.
> 
> 
> What's the PIC architecture like these days?, I heard it was always
> pretty messy in terms of memory and a real pain to program in assembly.
> 

You order ones with enough memory internally. The ones I've used were
USB connected and the easiest programming I've ever done. The
external pins are all either built in or macros in a .h file. I
honestly never checked

>   Still it can't be much worse than some of the MAXQ series.


--
Les Cargill

"David L. Jones" <altzone@gmail.com> wrote in message 
news:a7nGm.354$hJ2.98@newsfe13.iad...
> You aren't going to believe this...
>
> I recently reviewed the new Microchip PICkit3 compared to the old 
> PICkit2 and pretty much hammered the people responsible on behalf of 
> those who have found the PICkit3 upgrade rather lacking:
> http://www.eevblog.com/2009/10/21/eevblog-39-pickit-3-programmerdebugger-review/
>
> At it turns out, not surprisingly the video made it's way all around 
> the Microchip offices, even to the desk of their CEO.
> As with any multi billion dollar corporation, I expected either 
> deathly silence or a nasty letter from their lawyers.
>
> But it turns out Microchip really do care about their products and 
> customers, and really do listen, so they seriously took it as 
> constructive criticism.
>
> So not only was my blog well received at Microchip, I got a lengthy 
> call from none other than the Microchip CEO Steve Sanghi, thanking me 
> for the blog and raising the issues. He pointed out a few factual 
> errors which was fair enough, but admitted they could have done the 
> PICkit 3 better and most importantly are working to fix the issues and 
> give customers what they expect.
>
> They have even posted this hillarious video response in record time:
> http://www.youtube.com/watch?v=3YUvlrVlNao
>
> I am absolutely blown away by their honesty and responsiveness, and it 
> starts from their CEO down.
> Two thumbs up to Steve Sanghi and the guys and gals at Microchip!
>
> Dave.
>
> -- 
> ---------------------------------------------
> Check out my Electronics Engineering Video Blog & Podcast:
> http://www.eevblog.com
>
You can add Altera to the list, I received an email from them about some 
issues I had with their website.
Many people lurk here.

Cheers
 

"DJ Delorie" <dj@delorie.com> wrote in message 
news:xny6mt26zu.fsf@delorie.com...
>
> "David L. Jones" <altzone@gmail.com> writes:
>> http://www.youtube.com/watch?v=3YUvlrVlNao
>
> Sigh, I've been in that type of meeting before.  Not as Mr Head, of
> course.

That�s because you don�t have a MBA ;D

Cheers
 

Refurbished LEDs? LOL!
Microchip's always been a cool company, but a shite MCU architecture.
Sorry, Microchip. I'll use your DACs though!

"Martin Riddle" <martin_rid@verizon.net> writes:
> That's because you don't have a MBA ;D

And *that* is why I refuse to get an MBA :-)

a7yvm109gf5d1@netzero.com wrote:
> Refurbished LEDs? LOL!
> Microchip's always been a cool company, but a shite MCU architecture.
> Sorry, Microchip. I'll use your DACs though!

Maybe you don't understand the benfits of MH architecture.

"Swanny" <swanny@nospam.org> wrote in message 
news:72uGm.50908$ze1.32966@news-server.bigpond.net.au...
> a7yvm109gf5d1@netzero.com wrote:
>> Refurbished LEDs? LOL!
>> Microchip's always been a cool company, but a shite MCU architecture.
>> Sorry, Microchip. I'll use your DACs though!
>
> Maybe you don't understand the benfits of MH architecture.


Tell me what they are. (Genuine question)
thanks

On Oct 29, 11:35 pm, Swanny <swa...@nospam.org> wrote:
> a7yvm109gf...@netzero.com wrote:
> > Refurbished LEDs? LOL!
> > Microchip's always been a cool company, but a shite MCU architecture.
> > Sorry, Microchip. I'll use your DACs though!
>
> Maybe you don't understand the benfits of MH architecture.

Yawn.

Nik Rim wrote:
> "Swanny" <swanny@nospam.org> wrote in message 
> news:72uGm.50908$ze1.32966@news-server.bigpond.net.au...
>> a7yvm109gf5d1@netzero.com wrote:
>>> Refurbished LEDs? LOL!
>>> Microchip's always been a cool company, but a shite MCU architecture.
>>> Sorry, Microchip. I'll use your DACs though!
>> Maybe you don't understand the benfits of MH architecture.
> 
> 
> Tell me what they are. (Genuine question)
> thanks
> 
> 

Briefly, the Modified-Harvard architecture used in the PIC devices
separates the program memory from the data memory, in other words
separates the ROM/FLASH program memory from the RAM. In the case of the
PIC, the program memory bus width is larger than the data memory bus
width, allowing transfer of the complete instruction op code in fewer
cycles (many instructions take only 1 cycle).

The PIC peripheral bus (ie that accessible through external pins) uses
the same bus as the data memory and hence is also isolated from the
program memory. From a security perspective this allows sensitive data
(such as encryption keys etc) to be stored in program memory and be
completely inaccessible from the outside (provided the fuses are blown
after programming). The Microchip devices are particularly good in this
respect.

"Swanny" <swanny@nospam.org> wrote in message 
news:G1vGm.50913$ze1.9795@news-server.bigpond.net.au...
> Nik Rim wrote:
>> "Swanny" <swanny@nospam.org> wrote in message
>> news:72uGm.50908$ze1.32966@news-server.bigpond.net.au...
>>> a7yvm109gf5d1@netzero.com wrote:
>>>> Refurbished LEDs? LOL!
>>>> Microchip's always been a cool company, but a shite MCU architecture.
>>>> Sorry, Microchip. I'll use your DACs though!
>>> Maybe you don't understand the benfits of MH architecture.
>>
>>
>> Tell me what they are. (Genuine question)
>> thanks
>>
>>
>
> Briefly, the Modified-Harvard architecture used in the PIC devices
> separates the program memory from the data memory, in other words
> separates the ROM/FLASH program memory from the RAM. In the case of the
> PIC, the program memory bus width is larger than the data memory bus
> width, allowing transfer of the complete instruction op code in fewer
> cycles (many instructions take only 1 cycle).
>
> The PIC peripheral bus (ie that accessible through external pins) uses
> the same bus as the data memory and hence is also isolated from the
> program memory. From a security perspective this allows sensitive data
> (such as encryption keys etc) to be stored in program memory and be
> completely inaccessible from the outside (provided the fuses are blown
> after programming). The Microchip devices are particularly good in this
> respect.

thanks Swanny, that makes sense. 

> Briefly, the Modified-Harvard architecture used in the PIC devices
> separates the program memory from the data memory, in other words
> separates the ROM/FLASH program memory from the RAM.

[...]

Yes, but there's more to to a uC core then choosing between Harvard or
Von Neumann. I think most of the PICs quirks come from the other
decisions made.

The PIC (up to 16 bit cores anyway) is an accumulator architecture -
you have to funnel everything through the W register. AVRs for
instance have 32 registers which is nowhere near as clunky. The PIC
has dedicated memory for the Stack and is a PITA to save/restore local
variables. PICs have fun issues with banking and paging (not so much
in the 16 bit core thankfully). Personally, I think the most annoying
thing about programming PICs in assembly are the btfsc (test a bit in
'file', skip the next instruction if it's clear) and btfss (same thing
but skip if set) instructions. Why they couldn't just call these ifbit
and ifnbit, I don't know :-)

Back to the OP, great job Microchip on the video. It's a nice contrast
to TI, who recently sent misleading DMCA notices to people who tried
installing after-market OSs on their graphics calculators (
http://news.cnet.com/8301-30685_3-10374284-264.html )

Cheers,

A;

On Fri, 30 Oct 2009 10:23:51 +1100, the renowned "David L. Jones"
<altzone@gmail.com> wrote:

>Mark Harriss wrote:
>> DJ Delorie wrote:
>>> "David L. Jones" <altzone@gmail.com> writes:
>>>> http://www.youtube.com/watch?v=3YUvlrVlNao
>>>
>>> Sigh, I've been in that type of meeting before.  Not as Mr Head, of
>>> course.
>>
>>
>> What's the PIC architecture like these days?, I heard it was always
>> pretty messy in terms of memory and a real pain to program in
>> assembly.

There are really several PIC architectures.. the 12-bit instruction,
(PIC16F54, PIC12F509 etc.) the 14-bit instruction (most other PIC16F,
16 bit instructions (PIC18) (PIC17 is a dead end), the PIC24/DSPIC,
and the PIC32. They've also extended the instruction sets in a couple
of families. The 12-bit type is the most limiting, but also the most
parsimonious with resources. Even C can't hide the ugliness there, but
in most cases you won't notice or care because the tasks are
relatively simple. For example, IIRC constant arrays can't exceed a
page in size (256 bytes).  

>Tons better.
>They have the PIC18 series which is more C friendly than the old 16 series, 
>the 16 bit PIC24 series which is quite nice, and the new 32 bit PIC32 series 
>based on a MIPS 4K core. Plus the dsPIC too.
>And why would you want to program in assembler anyway for all but niche 
>areas?

IThe PIC18 is quite pleasant to program in assembler... just use
access ram for everything you can, and you don't have to think much
about banking. About the only thing I miss is an indexed plus offset
addressing mode, and I think they have that in the extended
instruction set mode, but I have not played with that (there are some
trade-offs or it would not have to be another mode). 

As to the C vs. asm question.. well, if you have to have a USB or
Ethernet (or Bluetooth) stack then you're in C territory. For less
than 16 k bytes of program memory, assembler probably deserves a look,
especially if you're not doing C-like things. And it depends on the
skill set and prior experience the programmer has, as well as whether
it's worth wringing out what is usually a << 2:1 improvement in
program memory size and performance. 

>Even the old 16 series is not messy if you use a good C compiler, it takes 
>care of any issues for you.
>
>Dave.

The Hitech C compiler (even the free 'lite' one) works pretty well,
though I've found some irritating bugs. It will even generate useful
code for the 12-bit instruction chips. 


Best regards, 
Spehro Pefhany
-- 
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

On Oct 30, 4:57 am, Al Borowski <al.borow...@gmail.com> wrote:
> > Briefly, the Modified-Harvard architecture used in the PIC devices
> > separates the program memory from the data memory, in other words
> > separates the ROM/FLASH program memory from the RAM.
>
> [...]
>
> Yes, but there's more to to a uC core then choosing between Harvard or
> Von Neumann. I think most of the PICs quirks come from the other
> decisions made.
>
> The PIC (up to 16 bit cores anyway) is an accumulator architecture -
> you have to funnel everything through the W register.

Going with accumulator model allowed Microchip to make the processor
with fewer transistors. It is a trade off that can break either way.
If you have a limit on the chip size you can make a higher performance
processor that is harder to program.


[....]
> in the 16 bit core thankfully). Personally, I think the most annoying
> thing about programming PICs in assembly are the btfsc (test a bit in
> 'file', skip the next instruction if it's clear) and btfss (same thing
> but skip if set) instructions. Why they couldn't just call these ifbit
> and ifnbit, I don't know :-)

Does ifbit mean skip if the bit is set or do the instruction if the
bit is set?

>
> Back to the OP, great job Microchip on the video. It's a nice contrast
> to TI, who recently sent misleading DMCA notices to people who tried
> installing after-market OSs on their graphics calculators (http://news.cnet.com/8301-30685_3-10374284-264.html)
>
> Cheers,
>
> A;

I still prefer the 8051.  It is way better.
[ducks]

"Swanny" <swanny@nospam.org> wrote in message news:G1vGm.50913$ze1.9795@news-server.bigpond.net.au...
> Nik Rim wrote:
>> "Swanny" <swanny@nospam.org> wrote in message
>> news:72uGm.50908$ze1.32966@news-server.bigpond.net.au...
>>> a7yvm109gf5d1@netzero.com wrote:
>>>> Refurbished LEDs? LOL!
>>>> Microchip's always been a cool company, but a shite MCU architecture.
>>>> Sorry, Microchip. I'll use your DACs though!
>>> Maybe you don't understand the benfits of MH architecture.
>>
>>
>> Tell me what they are. (Genuine question)
>> thanks
>>
>>
>
> Briefly, the Modified-Harvard architecture used in the PIC devices
> separates the program memory from the data memory, in other words
> separates the ROM/FLASH program memory from the RAM. In the case of the
> PIC, the program memory bus width is larger than the data memory bus
> width, allowing transfer of the complete instruction op code in fewer
> cycles (many instructions take only 1 cycle).

Just like with AVR, practically everything 1 cycle except branches.

M 

David L. Jones Inscribed thus:

> You aren't going to believe this...
> 
> I recently reviewed the new Microchip PICkit3 compared to the old
> PICkit2 and pretty much hammered the people responsible on behalf of
> those who have found the PICkit3 upgrade rather lacking:
>
http://www.eevblog.com/2009/10/21/eevblog-39-pickit-3-programmerdebugger-review/
> 
> At it turns out, not surprisingly the video made it's way all around
> the Microchip offices, even to the desk of their CEO.
> As with any multi billion dollar corporation, I expected either
> deathly silence or a nasty letter from their lawyers.
> 
> But it turns out Microchip really do care about their products and
> customers, and really do listen, so they seriously took it as
> constructive criticism.
> 
> So not only was my blog well received at Microchip, I got a lengthy
> call from none other than the Microchip CEO Steve Sanghi, thanking me
> for the blog and raising the issues. He pointed out a few factual
> errors which was fair enough, but admitted they could have done the
> PICkit 3 better and most importantly are working to fix the issues and
> give customers what they expect.
> 
> They have even posted this hillarious video response in record time:
> http://www.youtube.com/watch?v=3YUvlrVlNao
> 
> I am absolutely blown away by their honesty and responsiveness, and it
> starts from their CEO down.
> Two thumbs up to Steve Sanghi and the guys and gals at Microchip!
> 
> Dave.

Absolutely hilarious ! :-)
I enjoyed both videos.
Good on ya Dave.

-- 
Best Regards:
                Baron.

On Fri, 30 Oct 2009 06:52:49 -0700 (PDT), MooseFET
<kensmith@rahul.net> wrote:

>On Oct 30, 4:57�am, Al Borowski <al.borow...@gmail.com> wrote:
>> > Briefly, the Modified-Harvard architecture used in the PIC devices
>> > separates the program memory from the data memory, in other words
>> > separates the ROM/FLASH program memory from the RAM.
>>
>> [...]
>>
>> Yes, but there's more to to a uC core then choosing between Harvard or
>> Von Neumann. I think most of the PICs quirks come from the other
>> decisions made.
>>
>> The PIC (up to 16 bit cores anyway) is an accumulator architecture -
>> you have to funnel everything through the W register.
>
>Going with accumulator model allowed Microchip to make the processor
>with fewer transistors. It is a trade off that can break either way.
>If you have a limit on the chip size you can make a higher performance
>processor that is harder to program.
>
>
>[....]
>> in the 16 bit core thankfully). Personally, I think the most annoying
>> thing about programming PICs in assembly are the btfsc (test a bit in
>> 'file', skip the next instruction if it's clear) and btfss (same thing
>> but skip if set) instructions. Why they couldn't just call these ifbit
>> and ifnbit, I don't know :-)
>
>Does ifbit mean skip if the bit is set or do the instruction if the
>bit is set?
>
>>
>> Back to the OP, great job Microchip on the video. It's a nice contrast
>> to TI, who recently sent misleading DMCA notices to people who tried
>> installing after-market OSs on their graphics calculators (http://news.cnet.com/8301-30685_3-10374284-264.html)
>>
>> Cheers,
>>
>> A;
>
>I still prefer the 8051.  It is way better.
>[ducks]

So do I. The 8051 family was/is great. 

But I found the varients of 8051 I used were obsolete on more than one
occassion causing problems. I'm still sourcing SAB80C517 at silly
prices for example.

I first used the PIC for very low cost apps around 1990 and found that
there was always an upgrade path which didn't obsolete my designs.

Secondly Microchip always have product available.  I recall one rep
trying to convert me to the ST6. Then he said ST are behind on
production and delivery was 4-6 months.

There are better micros than the PIC from an engineering perspective
but they are hard to beat from a production view point.

On Fri, 30 Oct 2009 15:43:58 +0000, Raveninghorde
<raveninghorde@invalid> wrote:

>On Fri, 30 Oct 2009 06:52:49 -0700 (PDT), MooseFET
><kensmith@rahul.net> wrote:
>
>>On Oct 30, 4:57�am, Al Borowski <al.borow...@gmail.com> wrote:
>>> > Briefly, the Modified-Harvard architecture used in the PIC devices
>>> > separates the program memory from the data memory, in other words
>>> > separates the ROM/FLASH program memory from the RAM.
>>>
>>> [...]
>>>
>>> Yes, but there's more to to a uC core then choosing between Harvard or
>>> Von Neumann. I think most of the PICs quirks come from the other
>>> decisions made.
>>>
>>> The PIC (up to 16 bit cores anyway) is an accumulator architecture -
>>> you have to funnel everything through the W register.
>>
>>Going with accumulator model allowed Microchip to make the processor
>>with fewer transistors. It is a trade off that can break either way.
>>If you have a limit on the chip size you can make a higher performance
>>processor that is harder to program.
>>
>>
>>[....]
>>> in the 16 bit core thankfully). Personally, I think the most annoying
>>> thing about programming PICs in assembly are the btfsc (test a bit in
>>> 'file', skip the next instruction if it's clear) and btfss (same thing
>>> but skip if set) instructions. Why they couldn't just call these ifbit
>>> and ifnbit, I don't know :-)
>>
>>Does ifbit mean skip if the bit is set or do the instruction if the
>>bit is set?
>>
>>>
>>> Back to the OP, great job Microchip on the video. It's a nice contrast
>>> to TI, who recently sent misleading DMCA notices to people who tried
>>> installing after-market OSs on their graphics calculators (http://news.cnet.com/8301-30685_3-10374284-264.html)
>>>
>>> Cheers,
>>>
>>> A;
>>
>>I still prefer the 8051.  It is way better.
>>[ducks]
>
>So do I. The 8051 family was/is great.

I'm using one from SiLabs, right now.  Last 8051 project I did was
back in the early 1980's.  (Still have a box of about 100 80C32 chips
in perfect shape.)  For this app, I needed a much faster floating
point ln(x) function (achieved under 18 microseconds) and found myself
spending some time coding assembly on it.  No question in my mind that
this processor was designed with hand-coded assembly in mind, though.
Very easy to use efficiently for a human coder, though I do have to
check the book often to see if a particular instruction supports a
particular mode of access, yet just the kind of thing to seriously
complicate a compiler's life.

>But I found the varients of 8051 I used were obsolete on more than one
>occassion causing problems. I'm still sourcing SAB80C517 at silly
>prices for example.

I gather that Atmel has an AT89 line that includes an external bus and
so does SiLabs.  Not sure how either of these would score on not
obsoleting designs, though.

>I first used the PIC for very low cost apps around 1990 and found that
>there was always an upgrade path which didn't obsolete my designs.

Yes.  I've been using PICs since the late 1980's.. just around the
very month that Parallax entered the public fray.  Nobody likes the
bare-bones ALU design for the smaller-width instruction families --
it's design guts lay out on the floor, plain to see.  But Microchip
has maintained a very serious commitment to upgrade pathways over the
entire time I've been involved (just after they decided to move beyond
the "million unit rice cooker customer" days and place them into a
broader marketplace.  I couldn't have guessed then how strong that
commitment would be.  But they seem to well know what is important and
they have clearly (to me) worked very hard to _earn_ the respect they
have gained.  And it's been so on almost every good business front.

One begins to realize after experiencing such a company's commitment
to their customers, if that realization isn't already at hand, just
how relatively unimportant an instruction set is to all these other
business factors.

>Secondly Microchip always have product available.  I recall one rep
>trying to convert me to the ST6. Then he said ST are behind on
>production and delivery was 4-6 months.

Well, Microchip has had their days with delays (the wait for the
18F252 from using the 18C252 comes to mind) but they have tended to be
shorter than longer delays.

>There are better micros than the PIC from an engineering perspective
>but they are hard to beat from a production view point.

In all the time I've used them, they have consistently maintained a
solid professional use pathway that simply doesn't break.  I have old
tools that they no longer make (ProMate II) and yet they still support
it without question or quibble.  If I have so much as a flaky power
switch they want me to send it in and fire off a replacement with
shipping included for the "bad" one, so that I don't even miss a
single second of use.  Same for the modules that plug into it.  Their
tools are supported, decades it seems after they don't sell them
anymore.  That takes commitment on their part.

I find wringing of hands over the instruction set to be relatively
badly placed.  There are a lot more important things to focus on and
on those areas Microchip has done a yeoman's service across the board.

Obviously, I use other manufacturers too.  It's _very_ hard to find a
1MHz 16-bit SAR ADC anywhere in Microchip's monolithic cpu fold, for
example.  But none of have compared quite as well on the business
issues over the years.

Jon

Jon Kirwan wrote:
> On Fri, 30 Oct 2009 15:43:58 +0000, Raveninghorde
> <raveninghorde@invalid> wrote:
>
>> On Fri, 30 Oct 2009 06:52:49 -0700 (PDT), MooseFET
>> <kensmith@rahul.net> wrote:
>>
>>> On Oct 30, 4:57 am, Al Borowski <al.borow...@gmail.com> wrote:
>>>>> Briefly, the Modified-Harvard architecture used in the PIC devices
>>>>> separates the program memory from the data memory, in other words
>>>>> separates the ROM/FLASH program memory from the RAM.
>>>>
>>>> [...]
>>>>
>>>> Yes, but there's more to to a uC core then choosing between
>>>> Harvard or
>>>> Von Neumann. I think most of the PICs quirks come from the other
>>>> decisions made.
>>>>
>>>> The PIC (up to 16 bit cores anyway) is an accumulator architecture
>>>> -
>>>> you have to funnel everything through the W register.
>>>
>>> Going with accumulator model allowed Microchip to make the processor
>>> with fewer transistors. It is a trade off that can break either way.
>>> If you have a limit on the chip size you can make a higher
>>> performance processor that is harder to program.
>>>
>>>
>>> [....]
>>>> in the 16 bit core thankfully). Personally, I think the most
>>>> annoying
>>>> thing about programming PICs in assembly are the btfsc (test a bit
>>>> in 'file', skip the next instruction if it's clear) and btfss
>>>> (same thing
>>>> but skip if set) instructions. Why they couldn't just call these
>>>> ifbit
>>>> and ifnbit, I don't know :-)
>>>
>>> Does ifbit mean skip if the bit is set or do the instruction if the
>>> bit is set?
>>>
>>>>
>>>> Back to the OP, great job Microchip on the video. It's a nice
>>>> contrast
>>>> to TI, who recently sent misleading DMCA notices to people who
>>>> tried
>>>> installing after-market OSs on their graphics calculators
>>>> (http://news.cnet.com/8301-30685_3-10374284-264.html)
>>>>
>>>> Cheers,
>>>>
>>>> A;
>>>
>>> I still prefer the 8051.  It is way better.
>>> [ducks]
>>
>> So do I. The 8051 family was/is great.
>
> I'm using one from SiLabs, right now.  Last 8051 project I did was
> back in the early 1980's.  (Still have a box of about 100 80C32 chips
> in perfect shape.)  For this app, I needed a much faster floating
> point ln(x) function (achieved under 18 microseconds) and found myself
> spending some time coding assembly on it.  No question in my mind that
> this processor was designed with hand-coded assembly in mind, though.
> Very easy to use efficiently for a human coder, though I do have to
> check the book often to see if a particular instruction supports a
> particular mode of access, yet just the kind of thing to seriously
> complicate a compiler's life.
>
>> But I found the varients of 8051 I used were obsolete on more than
>> one occassion causing problems. I'm still sourcing SAB80C517 at silly
>> prices for example.
>
> I gather that Atmel has an AT89 line that includes an external bus and
> so does SiLabs.  Not sure how either of these would score on not
> obsoleting designs, though.
>
>> I first used the PIC for very low cost apps around 1990 and found
>> that there was always an upgrade path which didn't obsolete my
>> designs.
>
> Yes.  I've been using PICs since the late 1980's.. just around the
> very month that Parallax entered the public fray.  Nobody likes the
> bare-bones ALU design for the smaller-width instruction families --
> it's design guts lay out on the floor, plain to see.  But Microchip
> has maintained a very serious commitment to upgrade pathways over the
> entire time I've been involved (just after they decided to move beyond
> the "million unit rice cooker customer" days and place them into a
> broader marketplace.  I couldn't have guessed then how strong that
> commitment would be.  But they seem to well know what is important and
> they have clearly (to me) worked very hard to _earn_ the respect they
> have gained.  And it's been so on almost every good business front.
>
> One begins to realize after experiencing such a company's commitment
> to their customers, if that realization isn't already at hand, just
> how relatively unimportant an instruction set is to all these other
> business factors.
>
>> Secondly Microchip always have product available.  I recall one rep
>> trying to convert me to the ST6. Then he said ST are behind on
>> production and delivery was 4-6 months.
>
> Well, Microchip has had their days with delays (the wait for the
> 18F252 from using the 18C252 comes to mind) but they have tended to be
> shorter than longer delays.
>
>> There are better micros than the PIC from an engineering perspective
>> but they are hard to beat from a production view point.
>
> In all the time I've used them, they have consistently maintained a
> solid professional use pathway that simply doesn't break.  I have old
> tools that they no longer make (ProMate II) and yet they still support
> it without question or quibble.  If I have so much as a flaky power
> switch they want me to send it in and fire off a replacement with
> shipping included for the "bad" one, so that I don't even miss a
> single second of use.  Same for the modules that plug into it.  Their
> tools are supported, decades it seems after they don't sell them
> anymore.  That takes commitment on their part.
>
> I find wringing of hands over the instruction set to be relatively
> badly placed.  There are a lot more important things to focus on and
> on those areas Microchip has done a yeoman's service across the board.
>
> Obviously, I use other manufacturers too.  It's _very_ hard to find a
> 1MHz 16-bit SAR ADC anywhere in Microchip's monolithic cpu fold, for
> example.  But none of have compared quite as well on the business
> issues over the years.
>
> Jon

Also when looking for a long term investment in micros you may have to 
consider the companies viability.
Microchip are essentially the only micro manufacturer actually making monay 
and doing quite well at present. All the others are losing money 
hand-over-first and some are in a very bad state. All the fanboys scream 
Atmel, but they haven't made a cent since they started, and are probably the 
most unstable in terms of long term viability.

Dave.

-- 
---------------------------------------------
Check out my Electronics Engineering Video Blog & Podcast:
http://www.eevblog.com 

On Fri, 30 Oct 2009 15:43:58 +0000, Raveninghorde
<raveninghorde@invalid> wrote:

>On Fri, 30 Oct 2009 06:52:49 -0700 (PDT), MooseFET
><kensmith@rahul.net> wrote:
>
>>On Oct 30, 4:57�am, Al Borowski <al.borow...@gmail.com> wrote:
>>> > Briefly, the Modified-Harvard architecture used in the PIC devices
>>> > separates the program memory from the data memory, in other words
>>> > separates the ROM/FLASH program memory from the RAM.
>>>
>>> [...]
>>>
>>> Yes, but there's more to to a uC core then choosing between Harvard or
>>> Von Neumann. I think most of the PICs quirks come from the other
>>> decisions made.
>>>
>>> The PIC (up to 16 bit cores anyway) is an accumulator architecture -
>>> you have to funnel everything through the W register.
>>
>>Going with accumulator model allowed Microchip to make the processor
>>with fewer transistors. It is a trade off that can break either way.
>>If you have a limit on the chip size you can make a higher performance
>>processor that is harder to program.
>>
>>
>>[....]
>>> in the 16 bit core thankfully). Personally, I think the most annoying
>>> thing about programming PICs in assembly are the btfsc (test a bit in
>>> 'file', skip the next instruction if it's clear) and btfss (same thing
>>> but skip if set) instructions. Why they couldn't just call these ifbit
>>> and ifnbit, I don't know :-)
>>
>>Does ifbit mean skip if the bit is set or do the instruction if the
>>bit is set?
>>
>>>
>>> Back to the OP, great job Microchip on the video. It's a nice contrast
>>> to TI, who recently sent misleading DMCA notices to people who tried
>>> installing after-market OSs on their graphics calculators (http://news.cnet.com/8301-30685_3-10374284-264.html)
>>>
>>> Cheers,
>>>
>>> A;
>>
>>I still prefer the 8051.  It is way better.
>>[ducks]
>
>So do I. The 8051 family was/is great. 
>
>But I found the varients of 8051 I used were obsolete on more than one
>occassion causing problems. I'm still sourcing SAB80C517 at silly
>prices for example.

8051s, in several performance varieties (parallel one-clock to the
original serial 12-clock ALU), are now available as FPGA soft cores.
Obsolete chip?  Just synthesize. Haven't quite figured out why I want
to buy FPGA fabric to do an 8051, though.  ;-)

>I first used the PIC for very low cost apps around 1990 and found that
>there was always an upgrade path which didn't obsolete my designs.
>
>Secondly Microchip always have product available.  I recall one rep
>trying to convert me to the ST6. Then he said ST are behind on
>production and delivery was 4-6 months.
>
>There are better micros than the PIC from an engineering perspective
>but they are hard to beat from a production view point.

I don't see much use for the larger PICs.  We're using a PIC-24 but
it's more than overkill and just too weird.  

David L. Jones wrote:
> They have even posted this hillarious video response in record time:
> http://www.youtube.com/watch?v=3YUvlrVlNao
> 
> I am absolutely blown away by their honesty and responsiveness, and it 
> starts from their CEO down.
> Two thumbs up to Steve Sanghi and the guys and gals at Microchip!

Very cool, Dave.
BTW, I loved your #40 blog[0], but I'm worried that it could get you in 
trouble. Have your bosses discovered your blog yet?

[0] I've worked on several Doomed Projects myself.

-- 
    W
  . | ,. w ,   "Some people are alive only because
   \|/  \|/     it is illegal to kill them."    Perna condita delenda est
---^----^---------------------------------------------------------------

On Oct 30, 2:09 pm, Jon Kirwan <j...@infinitefactors.org> wrote:
[.. was PIC now 8051s ..]
>
> I'm using one from SiLabs, right now.

Just one?  One of my designs is about to go into production with two
F120s
clocked at nearly 90MHz.  One of them is just about fully busy.  The
other
has many microseconds to spare.


> in perfect shape.)  For this app, I needed a much faster floating
> point ln(x) function (achieved under 18 microseconds) and found myself
> spending some time coding assembly on it.

Do you really need true floating point?  do you really need ln() or
would log2() do?  18 microseconds seems a little slow.

Doing log2() of a 32 bit floater can be fairly quick if you don't
care
much about how much code space you use.

>  No question in my mind that
> this processor was designed with hand-coded assembly in mind, though.
> Very easy to use efficiently for a human coder, though I do have to
> check the book often to see if a particular instruction supports a
> particular mode of access, yet just the kind of thing to seriously
> complicate a compiler's life.

Real men code in assembly anyway.

>
> >But I found the varients of 8051 I used were obsolete on more than one
> >occassion causing problems. I'm still sourcing SAB80C517 at silly
> >prices for example.
>
> I gather that Atmel has an AT89 line that includes an external bus and
> so does SiLabs.  Not sure how either of these would score on not
> obsoleting designs, though.
>
> >I first used the PIC for very low cost apps around 1990 and found that
> >there was always an upgrade path which didn't obsolete my designs.
>
> Yes.  I've been using PICs since the late 1980's.. just around the
> very month that Parallax entered the public fray.  Nobody likes the
> bare-bones ALU design for the smaller-width instruction families --
> it's design guts lay out on the floor, plain to see.  But Microchip
> has maintained a very serious commitment to upgrade pathways over the
> entire time I've been involved (just after they decided to move beyond
> the "million unit rice cooker customer" days and place them into a
> broader marketplace.  I couldn't have guessed then how strong that
> commitment would be.  But they seem to well know what is important and
> they have clearly (to me) worked very hard to _earn_ the respect they
> have gained.  And it's been so on almost every good business front.
>
> One begins to realize after experiencing such a company's commitment
> to their customers, if that realization isn't already at hand, just
> how relatively unimportant an instruction set is to all these other
> business factors.
>
> >Secondly Microchip always have product available.  I recall one rep
> >trying to convert me to the ST6. Then he said ST are behind on
> >production and delivery was 4-6 months.
>
> Well, Microchip has had their days with delays (the wait for the
> 18F252 from using the 18C252 comes to mind) but they have tended to be
> shorter than longer delays.
>
> >There are better micros than the PIC from an engineering perspective
> >but they are hard to beat from a production view point.
>
> In all the time I've used them, they have consistently maintained a
> solid professional use pathway that simply doesn't break.  I have old
> tools that they no longer make (ProMate II) and yet they still support
> it without question or quibble.  If I have so much as a flaky power
> switch they want me to send it in and fire off a replacement with
> shipping included for the "bad" one, so that I don't even miss a
> single second of use.  Same for the modules that plug into it.  Their
> tools are supported, decades it seems after they don't sell them
> anymore.  That takes commitment on their part.
>
> I find wringing of hands over the instruction set to be relatively
> badly placed.  There are a lot more important things to focus on and
> on those areas Microchip has done a yeoman's service across the board.
>
> Obviously, I use other manufacturers too.  It's _very_ hard to find a
> 1MHz 16-bit SAR ADC anywhere in Microchip's monolithic cpu fold, for
> example.  But none of have compared quite as well on the business
> issues over the years.
>
> Jon

Bob Larter wrote:
> David L. Jones wrote:
>> They have even posted this hillarious video response in record time:
>> http://www.youtube.com/watch?v=3YUvlrVlNao
>>
>> I am absolutely blown away by their honesty and responsiveness, and
>> it starts from their CEO down.
>> Two thumbs up to Steve Sanghi and the guys and gals at Microchip!
>
> Very cool, Dave.
> BTW, I loved your #40 blog[0], but I'm worried that it could get you
> in trouble. Have your bosses discovered your blog yet?

Yes, my company is fully aware I do it, and I work within their blogging 
guidelines (yes, they actually encourage us to do this sort of thing).
But all of those projects are from previous companies (now mostly folded), 
so no problem!

Dave.

-- 
---------------------------------------------
Check out my Electronics Engineering Video Blog & Podcast:
http://www.eevblog.com 

David L. Jones wrote:
> You aren't going to believe this...
> 
> I recently reviewed the new Microchip PICkit3 compared to the old PICkit2 
> and pretty much hammered the people responsible on behalf of those who have 
> found the PICkit3 upgrade rather lacking:

Dave, compliments of Spehro Pefhany, the MC PICkit3 story made it to the 
Piclist also:

http://old.nabble.com/Microchip%27s-customer-relations..-excellent-response-td26128622.html
Hope you can read it there without going through the login hoops

Cheers Don...



-- 
Don McKenzie

Site Map:            http://www.dontronics.com/sitemap
E-Mail Contact Page: http://www.dontronics.com/email
Web Camera Page:     http://www.dontronics.com/webcam
No More Damn Spam:   http://www.dontronics.com/spam

Breakout, Prototype, Development, & Robotics Boards:
http://www.dontronics-shop.com/sparkfun-electronics.html

"David L. Jones" <altzone@gmail.com> wrote:

>
>Also when looking for a long term investment in micros you may have to 
>consider the companies viability.

Not really. Most of the cost for designing a product goes into the
firmware. If you use PIC and want to switch to another platform you'll
quickly learn that porting C code from or to PIC is almost impossible
for any real piece of firmware*. If you start out with say Renesas H8,
TI's MSP430 or any ARM flavor you'll find exchanging C code between
those is very easy.

* I know the pheripherals are different. Hardware drivers are least of
the problem though.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------

On Oct 30, 9:01 am, "TheM" wrote:
> "Swanny" wrote:

> > Briefly, the Modified-Harvard architecture used in the PIC devices
> > separates the program memory from the data memory, in other words
> > separates the ROM/FLASH program memory from the RAM. In the case of the
> > PIC, the program memory bus width is larger than the data memory bus
> > width, allowing transfer of the complete instruction op code in fewer
> > cycles (many instructions take only 1 cycle).
>
> Just like with AVR, practically everything 1 cycle except branches.
>
> M

But don't the 10xx, 12xx, and 16xx PICs take 4 clocks per instruction
cycle?  AVRs only take 1 clock per instruction (with the usual
exceptions).

--
James Arthur

Nico Coesel wrote:
> "David L. Jones" <altzone@gmail.com> wrote:
> 
>> Also when looking for a long term investment in micros you may have to 
>> consider the companies viability.
> 
> Not really. Most of the cost for designing a product goes into the
> firmware. If you use PIC and want to switch to another platform you'll
> quickly learn that porting C code from or to PIC is almost impossible
> for any real piece of firmware*. If you start out with say Renesas H8,
> TI's MSP430 or any ARM flavor you'll find exchanging C code between
> those is very easy.
> 
> * I know the pheripherals are different. Hardware drivers are least of
> the problem though.
> 


This is the kind of gotcha you need to know about in advance when
deciding what architecture to use.

"David L. Jones" <altzone@gmail.com> schrieb im Newsbeitrag 
news:a7nGm.354$hJ2.98@newsfe13.iad...
> You aren't going to believe this...
>
> I recently reviewed the new Microchip PICkit3 compared to the old PICkit2 
> and pretty much hammered the people responsible on behalf of those who 
> have found the PICkit3 upgrade rather lacking:
> http://www.eevblog.com/2009/10/21/eevblog-39-pickit-3-programmerdebugger-review/
>
> At it turns out, not surprisingly the video made it's way all around the 
> Microchip offices, even to the desk of their CEO.
> As with any multi billion dollar corporation, I expected either deathly 
> silence or a nasty letter from their lawyers.
>
> But it turns out Microchip really do care about their products and 
> customers, and really do listen, so they seriously took it as constructive 
> criticism.
>
> So not only was my blog well received at Microchip, I got a lengthy call 
> from none other than the Microchip CEO Steve Sanghi, thanking me for the 
> blog and raising the issues. He pointed out a few factual errors which was 
> fair enough, but admitted they could have done the PICkit 3 better and 
> most importantly are working to fix the issues and give customers what 
> they expect.
>
> They have even posted this hillarious video response in record time:
> http://www.youtube.com/watch?v=3YUvlrVlNao
>
> I am absolutely blown away by their honesty and responsiveness, and it 
> starts from their CEO down.
> Two thumbs up to Steve Sanghi and the guys and gals at Microchip!
>
> Dave.
>
> -- 
> ---------------------------------------------
> Check out my Electronics Engineering Video Blog & Podcast:
> http://www.eevblog.com
>

Sadly also the Microchip Serial Memory Programmer now is supported by MPLAB 
only, the former standalone software SEEVAL32 (on the former programmer with 
a COM port) was handy and easier to use.
see:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535259
http://search.digikey.com/scripts/DkSearch/dksus.dll?lang=en&site=US&WT.z_homepage_link=hp_go_button&KeyWords=DV243003&x=16&y=14

Anyhow the new product works fine and is cheap, and the Microchip response 
is funny, and lets hope for an SW upgrade for the PICKIT3 and maybe also for 
the serial memory programmer.

Does anybody use the pickit serial analyzer ?
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en028600

By the way Dave, your video blog is excellent !

MIKE

-- 
www.oho-elektronik.de
OHO-Elektronik
Michael Randelzhofer
FPGA und CPLD Mini Module
Klein aber oho !
Kontakt:
Tel: 08131 339230
mr@oho-elektronik.de
Usst.ID: DE130097310

David L. Jones wrote:
> Bob Larter wrote:
>> David L. Jones wrote:
>>> They have even posted this hillarious video response in record time:
>>> http://www.youtube.com/watch?v=3YUvlrVlNao
>>>
>>> I am absolutely blown away by their honesty and responsiveness, and
>>> it starts from their CEO down.
>>> Two thumbs up to Steve Sanghi and the guys and gals at Microchip!
>> Very cool, Dave.
>> BTW, I loved your #40 blog[0], but I'm worried that it could get you
>> in trouble. Have your bosses discovered your blog yet?
> 
> Yes, my company is fully aware I do it, and I work within their blogging 
> guidelines (yes, they actually encourage us to do this sort of thing).
> But all of those projects are from previous companies (now mostly folded), 
> so no problem!

Ah, good.

-- 
    W
  . | ,. w ,   "Some people are alive only because
   \|/  \|/     it is illegal to kill them."    Perna condita delenda est
---^----^---------------------------------------------------------------