 |
 |
| View previous topic :: View next topic |
| Author |
Message |
bkamen
Joined: 07 Jan 2004
Posts: 1619
Location: Central Illinois, USA
|
|
 Posted: Mon Feb 09, 2015 9:13 am |
 |
|
| ELCouz wrote: |
How hard is the transition from 8-bit to 32-bit platform?
I know we can only compare to MPLAB (because CCS don't offer any PIC32 support yet)... |
The hard part is not switching from 8-32bits. C takes care of that for you.
The hard part(s) is(are):
Learning C32/XC32 and the way those compilers do things.
(and if you have both like me, dealing with the differences between C32 and XC32. And there are some noticeable differences.)
Learning all the ways the new CPU does things -- which is no harder than learning PIC24 or ARM or 8051 or..... it's learning a new Microcontroller.
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
 |
asmallri
Joined: 12 Aug 2004
Posts: 1663
Location: Perth, Australia
|
|
| Posted: Mon Feb 09, 2015 12:03 pm |
|
|
| bkamen wrote: |
The hard part(s) is(are):
Learning C32/XC32 and the way those compilers do things.
(and if you have both like me, dealing with the differences between C32 and XC32. And there are some noticeable differences.) |
Yes. How to ensure the slow adoption of a new PIC, deliver incompatible tool chains that run under different IDEs with the newer IDE being seriously broken.
| Quote: | | Learning all the ways the new CPU does things -- which is no harder than learning PIC24 or ARM or 8051 or..... it's learning a new Microcontroller |
Wow. I must be getting old. I found the fixed (yet fundamentally broken and therefore unnecessary) memory mapping system, broken linker memory allocation model, the need to configure the core before it does anything, and truck loads of silicon bugs, much more challenging than learning the 8051.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1619
Location: Central Illinois, USA
|
|
| Posted: Mon Feb 09, 2015 12:07 pm |
|
|
| asmallri wrote: | | bkamen wrote: |
The hard part(s) is(are):
Learning C32/XC32 and the way those compilers do things.
(and if you have both like me, dealing with the differences between C32 and XC32. And there are some noticeable differences.) |
Yes. How to ensure the slow adoption of a new PIC, deliver incompatible tool chains that run under different IDEs with the newer IDE being seriously broken.
| Quote: | | Learning all the ways the new CPU does things -- which is no harder than learning PIC24 or ARM or 8051 or..... it's learning a new Microcontroller |
Wow. I must be getting old. I found the fixed (yet fundamentally broken and therefore unnecessary) memory mapping system, broken linker memory allocation model, the need to configure the core before it does anything, and truck loads of silicon bugs, much more challenging than learning the 8051. |
Hahahahha.. You're cracking me up.
But you know what I mean -- an 8051 is different .. if you've never used one before -- there's some learning.
BUT DEFINITELY less/easier learning than the mucked up models of todays more complex system. (which can be a real headache, I agree.)
Hahaha.... so funny..
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1411
|
|
| Posted: Mon Feb 09, 2015 2:14 pm |
|
|
| bkamen wrote: |
But you know what I mean -- an 8051 is different .. if you've never used one before -- there's some learning.
|
You're definitely right on that. I've just started learning the 8051 and while it isn't difficult, it takes a bit to get real feel for what the processor needs to do. I'm used to the PIC24 so I find myself going "oh, all I need to do is this, this, and this" and then I remember it works differently on the 8051. Years of habit and experience can be a double edged sword as I find myself having to unlearn some things while I work with this new chip.
Even the development tools takes some getting used to. I forgot how spoiled I was having a delay_ms() function in CCS. I had to write my own. Sure I could have just used a for loop with an arbitrary number measured out to get the value I wanted, but something in me yearned for a method that generated 50ms when I put in 50 as an input parameter. If my environment allowed direct inline assembly, that would have been nice, but it took me a bit to realize I needed to do a separate file for the ASM, compile it as an ASM source, then link that in.
Still learning new things is fun. |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Tue Feb 10, 2015 2:52 pm |
|
|
I like both PIC16/18 and the ARM. They are intended for different markets and complement each other:
The PIC are great for low-latency I/O, bit manipulation and high volumes where every cent counts.
The ARM are great for maths intensive tasks, graphic displays and anything with an Ethernet connector.
Driving a VGA screen or web server with a PIC18 is (almost) impossible. But on the other hand is an ARM processor not efficient when you want to control a few RGB LEDs over an RS485 line.
In my work/hobby almost every device has an Ethernet connector so in the last few years I've stepped away from PIC and am using ARM now. |
|
|
ELCouz
Joined: 18 Jul 2007
Posts: 427
Location: Montreal,Quebec
|
|
| Posted: Tue Feb 10, 2015 3:32 pm |
|
|
| ckielstra wrote: | I like both PIC16/18 and the ARM. They are intended for different markets and complement each other:
The PIC are great for low-latency I/O, bit manipulation and high volumes where every cent counts.
The ARM are great for maths intensive tasks, graphic displays and anything with an Ethernet connector.
Driving a VGA screen or web server with a PIC18 is (almost) impossible. But on the other hand is an ARM processor not efficient when you want to control a few RGB LEDs over an RS485 line.
In my work/hobby almost every device has an Ethernet connector so in the last few years I've stepped away from PIC and am using ARM now. |
Exactly this...
Using an RaspberryPi/Edison/BeagleBoard to do digital I/O or ADC stuff is overkill...
That's why I use the PIC...simple, effective, low power and low cost vs ARM!
When power is not a restriction, I prefer using x86 than the ARM since the compilers/gui/toolkit are there!
Why reinvent the wheel with ARM when you can do it in old school x86???!!
I like the MinnowBoard but there's plenty of board with x86...
_________________
Regards,
Laurent
-----------
Here's my first visual theme for the CCS C Compiler. Enjoy! |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1619
Location: Central Illinois, USA
|
|
| Posted: Tue Feb 10, 2015 3:45 pm |
|
|
| ELCouz wrote: |
That's why I use the PIC...simple, effective, low power and low cost vs ARM!
|
Not really.
The ARM-M0s are very cost competitive against comparable PIC32s.
-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
ELCouz
Joined: 18 Jul 2007
Posts: 427
Location: Montreal,Quebec
|
|
| Posted: Tue Feb 10, 2015 3:49 pm |
|
|
| bkamen wrote: | | ELCouz wrote: |
That's why I use the PIC...simple, effective, low power and low cost vs ARM!
|
Not really.
The ARM-M0s are very cost competitive against comparable PIC32s.
-Ben |
I didn't say PIC32.... I meant the whole pic10,12,16,17,18,24,30,33 series....
I was saying about overkill projects... many people use ARM (see RPi) even for simple tasks...
PIC32 is inferior by design and late entry...that's why I asked how is it to learn vs other ARM core....
_________________
Regards,
Laurent
-----------
Here's my first visual theme for the CCS C Compiler. Enjoy! |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
