Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.
G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676
Posted: 01:39pm 27 Jul 2014
Copy link to clipboard
Print this post
Hi
I've just placed an order for 4 x PIC32MX170F256B-50I/SP at Microchip Direct with an estimated delivery date of 01-Aug-2014 and the unit price was only GBP 2.87 each including Tax (VAT at 20% here in the UK).
The price brings to mind a key question.
The 8 bit and 16 bit MCUs from Microchip are not much different in price from this PIC32MX1XX, even in the 1,000 off quantity bracket.
So, why would anybody choose to use an 8/16 bit MCU when one can use a 32 bit MCU with 256K Flash and 64K RAM for almost no premium ?
Am I missing something here ?
Peter
The only Konstant is Change
Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9488
Posted: 02:56pm 27 Jul 2014
Copy link to clipboard
Print this post
I am only guessing here, but probably depends on exactly what the project NEEDS.
You are on the right track, though, as far as I am concerned - I would not considder an 8-bit MCU over the 32's these days, especially with the likes of MMBASIC as the "Engine under the hood" so to speak.
It's like a V8 vs a straight 4.
But again, it also depends on what is needed. 32's suck more current(unless you throttle them back) then the 8's, and there are most likely millions of products that still need the 8's, cos that was what was designed-in in the first place - so they are still about, to satify old designs or product lines.
With any NEW product, it would be wise to use the 32's, and I am in fact porting one of my PICAXE products over the MMBASIC and the MicroMite. To save current, I will throttle-back the speed to 5MHz, which brings the current back down to about the same as the PICAXE chip.Smoke makes things work. When the smoke gets out, it stops!
BobD Guru Joined: 07/12/2011 Location: AustraliaPosts: 935
Posted: 02:58pm 27 Jul 2014
Copy link to clipboard
Print this post
Familiarity, low power, program in assembler, small package, DIP instead of SMT, ....
Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9488
Posted: 03:01pm 27 Jul 2014
Copy link to clipboard
Print this post
Good points there, Bob...Smoke makes things work. When the smoke gets out, it stops!
kiiid Guru Joined: 11/05/2013 Location: United KingdomPosts: 671
Posted: 03:08pm 27 Jul 2014
Copy link to clipboard
Print this post
Have you noticed the power consumption of PIC32 compared to the other PICs?
Also, there are 8-bit micros in SOT23 and SSOP8 packages. Can't beat that with a PIC32...
http://rittle.org
--------------
G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676
Posted: 03:14pm 27 Jul 2014
Copy link to clipboard
Print this post
So, it looks like it's not cost then, but a host of other things, and it seems that PCB real estate is a predominant factor ?
Peter
PS I started off life as an EE with 6800/6802/6502/6809/68000 and I am amazed at the amount of CPU/ROM/RAM/IO one gets these days. Back when I started out a 6800 was over US$300, and I remember blowing up the first ever 6809 in the UK - 'cos I did it by reversing the VCC and VDD - luckily I wasn't fired, but we had to wait 2 weeks to get another one to be sent from Austin.Edited by G8JCF 2014-07-29The only Konstant is Change
BobD Guru Joined: 07/12/2011 Location: AustraliaPosts: 935
Posted: 03:26pm 27 Jul 2014
Copy link to clipboard
Print this post
Ahh, the good old days. Good memories but would you really want to go back to them? Not me.
Lou Senior Member Joined: 01/02/2014 Location: United StatesPosts: 229
Posted: 04:10pm 27 Jul 2014
Copy link to clipboard
Print this post
Peter Wrote
So, why would anybody choose to use an 8/16 bit MCU when one can use a 32 bit MCU with 256K Flash and 64K RAM for almost no premium ?
BobD Wrote:
Familiarity, low power, program in assembler, small package, DIP instead of SMT, ....
All the above plus 1/3 the cost, 1/10 the power useage for some of the small 8 or 14 pin PIC's, less complexity.
LouMicrocontrollers - the other white meat
G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676
Posted: 04:34pm 27 Jul 2014
Copy link to clipboard
Print this post
@BobD
I would !
Life seemed so simple then. I didn't forget things back then ! I knew the entire op-codes for the 6800/02/09 !
G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676
Posted: 01:27am 28 Jul 2014
Copy link to clipboard
Print this post
The only Konstant is Change
JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3998
Posted: 01:53am 28 Jul 2014
Copy link to clipboard
Print this post
Over more years than I like to think about I wrote a lot (a heck of a lot) of assembler, for various CPU chips.
It's all obsolete.
A lot of the C I wrote is still useful and will continue so to be. It's generally easy to tweak (if needed) going from 8-bit to 16-bit to 32-bit to 64-bit CPUs.
I try not to write any more assembler......
I'd pay the small premium for a 32-bit chip every time, and do. If I had a hugely profitable project that needed me to go for assembler, that's the only time I'd consider it.
John
G8JCF Guru Joined: 15/05/2014 Location: United KingdomPosts: 676
Posted: 12:33pm 28 Jul 2014
Copy link to clipboard
Print this post
I tend to agree with John. I really, really enjoyed writing 6800/09/000 assembler, but when I see what one person can achieve with C/Basic/Pascal and the time it takes compared to Assembler programming, IMHO Assembler is only for those performance driven situations where one is forced to use processor power insufficient to execute high level code quickly enough, and in the very innermost core of an OS (I don't think its possible to write a bare metal OS without some assembler even if it's just for the core stack manipulation for task switching - might be doable in C if there is a hypervisor between the OS and the bare metal)
Still, I do miss those days of opcodes, and hex editors.