Author Topic: Arduino User looking to move to PIC  (Read 20549 times)

0 Members and 1 Guest are viewing this topic.

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 7267
  • Country: us
    • SiliconValleyGarage
Re: Arduino User looking to move to PIC
« Reply #25 on: May 11, 2012, 02:35:08 pm »
Quote
Wait until you start programming C on a pure Harvard CPU.
why would i want to use a language written for a pdp-7 with an underpinning register based compiler on a harvard machine ? You write code in pl/m !


Quote
Really? ARM7 has seperate register banks for use during interrupts.
no it doesnt . Arm7 has two interrupts.. A fast and a slow one. Everything else needs to be handled in software. There are chips out there that have added an interrupt controller to an arm7, but it is NOT standard in the core.


Quote
And even if you need to push or pop you only need one instruction to push or pop a selection of registers on the stack (the time this takes depends on the number of selected registers). Its all very efficient.
No it's not. Depending on where the cpu is in the process the pipeline needs to abort... So you waste clockcycles.... It also makes program execution non-deterministic. The arm is a 6 stage pipeline.
The end result is that interrupts on arm are jittery and slow. For a same clockspeed the interrupt system of a 8051 reacts much faster and is deterministic.

I am using these machines as microcomtrollers, not as general computing platform ( which seems to be the general approach these days.. Let's all use these things thinking they are full blown computers' and write code like there is no limit to memory.. )
My code is very low level and integrates tightly with hardware. So i do need predictability.

Quote
You are mistaken seperate code fetch, memory access and system buses for Harvard.
Having separate address and databuses for code, data and io classify as harvard

Quote
I also can't find your magic switch instruction. There is no difference between the way it is handled on ARM7 or CortexM. Both have kernel and user space stacks. OTOH CortexM cpus do much of the interrupt handling in hardware.

thats what i mean with switch instruction. There is a hardware interrupt controller in the core. The cortex has instructions that save all operating registers in one step and can restore all of them in one step. The arm does not have this.

Wait.. Am i confusing with the nios again.. I use to many different cpus's sometimes i get confused...
I need to doublecheck this..
« Last Edit: May 11, 2012, 02:49:28 pm by free_electron »
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 7267
  • Country: us
    • SiliconValleyGarage
Re: Arduino User looking to move to PIC
« Reply #26 on: May 11, 2012, 02:47:21 pm »
"Vendorless cores" like arm sound great in theory, but in reality there is nothing vendorless about them. Different IDE's, different debuggers, different libraries. It's all different and requires just as much transition time unless you just forgo all the vendor provided support.
.??  The keil compiler can work on any 8051. Same for the iar. No need to switch ide's.
Same goes for arm. Doesnt matter where the cpu comes from.

It is normal that , if the peripherals change you need to understand how they work and how you handle them. That remains the same with any microcomtroller you work with.
You need to know you machine. Treating it from a pure high level perspective is very inefficient, especially on microcomtrollers.  And as for the linraries provided... They are horrible.
I have seen code where they initialize an io port direction register. The call a function to set a bit repeatedly.

Setdirection  porta pin7 in
Setdirection porta pin6 out
Setdirection porta pin5 in
Setdirection porta pin4 in ...
All the way down to pin 0.  And they do this for every single io port.... And there are 5 of these...

If i see code like that i walk away.... Find out where the io control register sits and write it as a byte. You only need 1 instruction to do that. The above code is calling, shiting read modify write and returning.  And people complain why the machine takes so long to boot.... Wasting 40 function calls that can be done in 5 instructions...
This is the kind of thing you get if programmers no longer understand the machine they code for. It's all 'c' and 'libraries'...
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline A Hellene

  • Frequent Contributor
  • **
  • Posts: 601
  • Country: gr
Re: Arduino User looking to move to PIC
« Reply #27 on: May 11, 2012, 02:51:44 pm »
Quote
[...]
This is the kind of thing you get if programmers no longer understand the machine they code for. It's all 'c' and 'libraries'...
Indeed...


-George
Hi! This is George; and I am three and a half years old!
(This was one of my latest realisations, now in my early fifties!...)
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 18331
  • Country: nl
    • NCT Developments
Re: Arduino User looking to move to PIC
« Reply #28 on: May 11, 2012, 04:57:29 pm »
Quote
Really? ARM7 has seperate register banks for use during interrupts.
no it doesnt . Arm7 has two interrupts.. A fast and a slow one.
Forgot about the exceptions?
Quote
Quote
And even if you need to push or pop you only need one instruction to push or pop a selection of registers on the stack (the time this takes depends on the number of selected registers). Its all very efficient.
No it's not. Depending on where the cpu is in the process the pipeline needs to abort... So you waste clockcycles.... It also makes program execution non-deterministic. The arm is a 6 stage pipeline.
The end result is that interrupts on arm are jittery and slow. For a same clockspeed the interrupt system of a 8051 reacts much faster and is deterministic.
Which is not a problem in the real world. Most peripherals I encountered on ARM and other modern controllers have buffers so variable interrupt latency is never a problem. Even if the interrupts are deterministic you still have a problem when 2 interrupts occur at the same time. In other words: interrupts are never deterministic if you have more than one interrupt enabled. In real applications you'll always have more than one interrupt source. Especially if the controller has a lot of peripherals and memory. Nowadays having 'deterministic interrupts' is just a marketing buzz word.
Quote
Quote
I also can't find your magic switch instruction. There is no difference between the way it is handled on ARM7 or CortexM. Both have kernel and user space stacks. OTOH CortexM cpus do much of the interrupt handling in hardware.

thats what i mean with switch instruction. There is a hardware interrupt controller in the core. The cortex has instructions that save all operating registers in one step and can restore all of them in one step. The arm does not have this.
Well ARM7 does have those instructions. RTM!
Quote
Wait.. Am i confusing with the nios again.. I use to many different cpus's sometimes i get confused...
I need to doublecheck this..
Reading the manual first might be a good idea because a lot you wrote simply isn't correct.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline jerry507

  • Regular Contributor
  • *
  • Posts: 246
Re: Arduino User looking to move to PIC
« Reply #29 on: May 11, 2012, 06:07:55 pm »
.??  The keil compiler can work on any 8051. Same for the iar. No need to switch ide's.
Same goes for arm. Doesnt matter where the cpu comes from.

It is normal that , if the peripherals change you need to understand how they work and how you handle them. That remains the same with any microcomtroller you work with.
You need to know you machine. Treating it from a pure high level perspective is very inefficient, especially on microcomtrollers.  And as for the linraries provided... They are horrible.
I have seen code where they initialize an io port direction register. The call a function to set a bit repeatedly.

Setdirection  porta pin7 in
Setdirection porta pin6 out
Setdirection porta pin5 in
Setdirection porta pin4 in ...
All the way down to pin 0.  And they do this for every single io port.... And there are 5 of these...

If i see code like that i walk away.... Find out where the io control register sits and write it as a byte. You only need 1 instruction to do that. The above code is calling, shiting read modify write and returning.  And people complain why the machine takes so long to boot.... Wasting 40 function calls that can be done in 5 instructions...
This is the kind of thing you get if programmers no longer understand the machine they code for. It's all 'c' and 'libraries'...

We must work in very different environments. You're very lucky to have the time necessary to write your own code for every peripheral. For myself, I have a month to turn around the code and if it's a bunch of UARTs and SPI, no problem. On the otherhand there are 100 registers for USB host on a TI Stellaris part. Then you need all the code on top of that. Simply using the libraries took me a week to get a basic connection going, leaving 3 or 4 weeks for my app development. I don't have the time to write my own to save a few hundreds of bytes.

And frankly, I don't care. I almost always have plenty of ram and flash left over. This isn't 1985 where we're constrained on flash.

As for IDE's, yes a Keil ARM compiler will work for any ARM but you're still left with the project and library issues. That all assumes that you spent money on the Keil product in the first place. We're not going to buy Keil and then figure out how to amortize that cost to all our various customers who not all even want a ARM product.

It's so easy to say "oh man just go with a vendorless core" or any number of other simple statements, but reality is always more complex than that.
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 7267
  • Country: us
    • SiliconValleyGarage
Re: Arduino User looking to move to PIC
« Reply #30 on: May 11, 2012, 07:00:34 pm »
Apparently our worlds differ. i don't do usb and ethernet stuff..

Here's how i partition it :
A microcontroller could be driving one motor in a robot arm. Each motor has its own microcontroller that does the operational functions of that particular motor : acceleration, deceleration , temperature and current monitoring , positional feedback, exception handling ,end detection ( reading optical encoders and switches etc )  etc... it accepts commands : go from x to y with this accel / decel profile and this max speed. let me know when done.

An embedded processor system would be talking to the invidual motor controllers. if you start giving that controller an ethernet port , serve up a webpage with buttons to control the motors .. that's no longer a microcontroller ... at least not in my definition. That is a computer. it may still be a single chip. but it is no longer a microcontroller. it is an embedded system.

Now, here is another point of view : if you are making a system that has usb hosts and ethernet you can't really call that a microcontroller anymore... that is a computer , most likely running some form of OS. the boundaries are fuzzy.

my definition of microcontroller is a single chip containing cpu / code / data memory and a bunch of IO that performs some operation invisible to the user. There may be a communication pathway in the form of a uart or some digital io but those are to instruct the controller what to do.

If at this level you use libraries fine.
But at the motor level you NEED to know what you are doing ! the 'embedded' system needs to have a certainty that the motor controller will behave .. if the embedded systems attempts to drive the motor over its endstops the microcontroller needs to say 'no'.

My work is mechantronical in nature (harddisks)  and the firmware is bound very tightly to the hardware. The drive motors do not wait, mis a phase commutation and you just corrupted a sector on the disk. The software is profiled and timed. We need to make sure the routine terminates on all possible pathways before the next interrupt comes. Speedcontrol loops ,servoloops .. it's all timed out. Code needs to be clean , tight and is profiled the hell out of it. Superfluous constructions like calling 50 times a routine to set some io pin direction is simply not done.

We actually go through the trouble to make a BSP for the algoritmh coders. Making the BSP is my work. ( BSP : board support package ) This is in essence a mini library and a bunch of defines that is are optimized. One project has tons of 'define's in it. Memory is mapped by hand for the custom logic attached to an ARM. the gateway in and out use through double ported memory. so the real 'microcontroller' never has to wait. the system controller simply drops data and instructions on specific addresses and the microcontroller will pick those up automatically. There are no input/ouput routines.

how to explain :

target_speed is a memory location in dpram.
real_speed is a memory location that , in reality, is a block of hardware but it is mapped into ram and we have a define for it.
commutecounter is also a location in memory that is actually an interval control register for the PWM.

code for the microcontroller is simply
if (real_speed != target_speed) then
  if (real_speed < target_speed) commute ++;
  else commute --;

As for the cost of the devplatform. what is 3K for a compiler ? it's written off in one project.

right.  i double checked it.
IRQ on an arm requires you to save R0 to R12
FIQ on an arm requires you to save R0 to R7 . 8 to 16 are dedicated to FIQ so you save time during the context swap as those registers are accessible only in the FIQ.
The arm also will complete whatever instructions are in the pipeline BEFORE it vectors off...

you were right about the LDM and STM instructions in all their wonderful flavours. i forgot about those.
but these instruction still take time to complete ( i dont know exaclty how many clockticks , i'd have to look it up ) and they take space on the stack...

An 8051 has 4 register banks and you can assign an interrupt handler to a specific bank. So there is no need to save anything on the stack ,you simply switch in and out.
It's a different approach.

And the cortex IS harvard, where Arm7 is von neumann as i stated. : i quote :

"The ARM Cortex-M3 is an implementation of the ARM7v architecture, the latest evolution of ARM’s embedded cores. It is a Harvard architecture, using separate buses for instructions and data (rather than a von Neumann architecture, where data and instructions share a bus). The Harvard architecture is intrinsically significantly faster but physically more complex."

and here's the other quote :
"Another innovation on the Cortex-M3 is the Nested Vector Interrupt Controller (NVIC). Unlike external interrupt controllers, as are used in ARM7TDMI implementations, this is integrated into the Cortex M3 core and can be configured by the silicon implementer to provide from a basic 32 physical interrupts with eight levels of pre-emption priority up to 240 physical interrupts and 256 levels of priority. The design is deterministic with low latency, making it particularly applicable to automotive applications"

with an arm7 the interrupt handling is something that is 'bolted-on' afterwards and depends on the chip vendor. In a cortex it is built in.

The above quotes come from Anders Lungren of IAR.  http://www.edn.com/article/459352-Choosing_between_an_ARM7_and_a_Cortex_M3_processor.php
Which is exactly what i stated.
« Last Edit: May 11, 2012, 07:47:19 pm by free_electron »
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline yanir

  • Regular Contributor
  • *
  • Posts: 216
  • Country: us
Arduino User looking to move to PIC
« Reply #31 on: May 11, 2012, 07:57:09 pm »
An embedded processor system would be talking to the invidual motor controllers. if you start giving that controller an ethernet port , serve up a webpage with buttons to control the motors .. that's no longer a microcontroller ... at least not in my definition. That is a computer. it may still be a single chip. but it is no longer a microcontroller. it is an embedded system.

...

my definition of microcontroller is a single chip containing cpu / code / data memory and a bunch of IO that performs some operation invisible to the user. There may be a communication pathway in the form of a uart or some digital io but those are to instruct the controller what to do.


This is all just semantics now.

First off Ive used pic24f microcontrollers to make simple products that do interesting things with usb host for data output, but I would not call them "computers" because this is misleading to the layperson.

We all know as programmers and enigineers that all these devices from little 8 bit micros to a full blown server are all technically computers. But ask the average joe to show you a computer and they will point to a big gray box, not their iPhone.

The OP just wants some advice on moving from a basic platform to something more low level and perhaps powerful.

 I wonder why these posts often turn into soap boxes for people  to rant about a chip they hate or brag about knowledge they have. This should be a community where experienced people share their knowledge in a constructive way with others.
« Last Edit: May 11, 2012, 08:00:55 pm by yanir »
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 7267
  • Country: us
    • SiliconValleyGarage
Re: Arduino User looking to move to PIC
« Reply #32 on: May 11, 2012, 08:20:06 pm »
This should be a community where experienced people share their knowledge in a constructive way with others.
Well what do you think i am doing ? i am pointing out that there is more than pic and avr , and that maybe you should look at thing like ARM ..
If you don't like it don't read it !
I would not call an 8 bit microcontroller a 'computer'... same for a 32 bit microcontroller.

there is 'microcontroller' and 'system on chip'. and that is is still a big difference... although it is getting more fuzzy every day.
Now microcontrollers come with usb , ethernet and lots of advanced stuff.

Quote
The OP just wants some advice on moving from a basic platform to something more low level and perhaps powerful.
Yes, so moving from PIC to AVR only moves horizontally... if you want to move 'up' you need to look at 32 bit systems and then you inadvertently end up with ARM or MIPS ( or sometimes the 683xx series from On semi ... or an SH2 ...
ARM is by far the most pupular. With the Cortex now plowing the way on the microcontroller market , where ARM7 has traditionally been a system-on-chip core and not available as a standard component ( apart from some atmel SAM7's and an odd-one-out here and there ). The cortex core is represented in volume by lots of manufacturers and lots of different chips.

That is clearly where we are headed..

As for 16 bit .. that seems to have gone the way of the wind ...
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline jerry507

  • Regular Contributor
  • *
  • Posts: 246
Re: Arduino User looking to move to PIC
« Reply #33 on: May 11, 2012, 08:41:02 pm »
I feel bad for the OP. He wanted some help with PICs and didn't realize that he created the perfect thread to get hijacked to hell and back.
 

Offline yanir

  • Regular Contributor
  • *
  • Posts: 216
  • Country: us
Arduino User looking to move to PIC
« Reply #34 on: May 11, 2012, 08:49:00 pm »

If you don't like it don't read it !
Hey, take it easy, no need to let your buffers overrun.




 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 7267
  • Country: us
    • SiliconValleyGarage
Re: Arduino User looking to move to PIC
« Reply #35 on: May 11, 2012, 09:11:32 pm »

If you don't like it don't read it !
Hey, take it easy, no need to let your buffers overrun.

:)  buffer overflow at 0xDEADBEEF . calling emergency handler ad 0x10C0FFEE....
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 18331
  • Country: nl
    • NCT Developments
Re: Arduino User looking to move to PIC
« Reply #36 on: May 11, 2012, 09:28:07 pm »
I feel bad for the OP. He wanted some help with PICs and didn't realize that he created the perfect thread to get hijacked to hell and back.
If you ask for advice you may not get the advice you want to hear but that doesn't mean it is not the advice you need  8)
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline charliehorse55

  • Contributor
  • Posts: 12
Re: Arduino User looking to move to PIC
« Reply #37 on: May 24, 2012, 05:25:52 am »
This has exploded into something with a lot of people over thinking the question. I really like the arduino, but I don't like the processing language and the high cost. I am just looking for a way to have a cheap micro that supports C.

I think I am going to buy this (PicKit2).
http://www.microchipdirect.com/ProductSearch.aspx?Keywords=DV164120

The software package seems to be Windows only. Any idea What should be looking at for a compiler/debugger on OSX ond Linux?

 

Offline xquercus

  • Contributor
  • Posts: 47
  • Country: us
Re: Arduino User looking to move to PIC
« Reply #38 on: May 24, 2012, 06:36:41 am »
The PK2 or PK3 is the way to go then.  The PK2 should come with a LPC demo board, a PIC16F, and an assembly language tutorial.

Microchip has a netbeans based IDE called MPLAB X which is cross platform -- Windows, OSX, and Linux.  It has received some bad press but it's really coming together in version 1.10 with very few issues.  The MPLAB 8 IDE is Windows only.  There is information on MPLAB X here:http://www.microchip.com/pagehandler/en-us/family/mplabx/

MPLAB X will interface with the entire gamut of Microchip's compilers.  The compiler you use will depend on what line of PIC you are using.  If you go to the Microchip compiler page (Products -> Development Tools -> Compilers from the home page) you might find yourself overwhelmed at the options.  The short story is that the various "MPLAB C" compilers are Microchip in house products, the Hi-Tech C products were purchased by Microchip, and the XC compilers are the new line of compilers which are actually being released as we speak (XC16 is due out in days).  Any of these compilers will work with MPLAB X via a plugin system.

If you are using low end 8-bit PICs (16Fs) stick with Microchip's MPASM assembly language.  I think it comes right with MPLAB X.

If you are using the high end 8-bit PICs (18Fs) you have 3 choices if you go with a Microchip product.  You can use MPLAB C (which is what I've used), Hi-Tech C, or XC8.  Most of the example code you will find will be in MPLAB C or Hi-Tech as XC8 is new.  My understanding is that MPLAB C and Hi Tech C are going away leaving only XC8.  Further, XC8 is an improved version of Hi Tech C.

If you are going with a 16-bit PIC like a 24F you have two options:  MPLAB C30 or Hi-Tech C.  The 16-bit XC compiler is not out yet.  I use MPLAB C30, but (as I said earler) it's going away and the yet to be released XC16 compiler (which is more similar to Hi-Tech I think) will be the single available compiler.

As for the issue of Pro/Standard/Lite/and Eval, if you are a hobbyist like me go with the free option -- Lite.  The only difference between these versions is optimization.  In some cases the optimizations available in Standard or Pro ore HUGE but just go the cheap route.

It sounds like you really just want to get your feet wet.  If that's the case, get a PK2 (or even a PK3), install MPLABX, get a couple PIC18s and 24Fs -- let's say a couple PIC18F2520-I/SPs and a couple PIC24FJ64GA002-I/SPs -- Download the Lite version of MPLAB C18 and MPLAB C30 and go to town! Don't be concerned that C18 and C30 are likely going away because you want to concentrate on learning the chips architecture.  C is C -- with a few differences here and there.  There are lots of examples available in C18 and C30 to get you started.

Others will not doubt question why I suggest those particular chips or compilers -- especially considering we don't know what you have in mind application-wise.  I'm just trying to give you something specific as the array of options are ridiculously overwhelming.  If you decide you don't care for those chips, at that point you'll be in a position to make an educated decision on another.  They are cheap.  If you don't like the MPLAB compilers, you can change.  They are free.

The Microchip web site is a cluster fsck of a mess.  None the less, learn your way around.  You'll need to grab the documentation on the compilers, MPLABX, and the chip data sheets and errata.  Also, make an account in the forums.  Read the forums.

A couple books:  For PIC18s look at "Applying PIC18 Microcontrollers" by Brey.  It's no substitute for the data sheet but discusses hardware and has lots of examples in assembly and C18.  For PIC24s look at "Programming 16-Bit Microcontrollers in C: Learning to Fly the PIC 24".  It has a very brief hardware overview and then basically has a pile of code in C30 -- no assembly.

Final piece of advice.  Learn the data sheets and avoid the support libraries with the compilers for operating the peripherals like the timers, uarts, spi, etc.  Write you C code so you are actually setting registers and not relying on Microchip's support libraries.  It's much easier at first.  You have to know the gory details of the hardware anyway and avoiding the support libraries will give you one less thing to have to learn.  Even though you are using C, think like you are using assembly.  Later on, once you are familiar with the architecture, you can decide whether the support libraries are a help or hindrance.

Hope this give you some specifics to get started.  Good luck!
 

Offline xquercus

  • Contributor
  • Posts: 47
  • Country: us
Re: Arduino User looking to move to PIC
« Reply #39 on: May 24, 2012, 06:51:14 am »
One more thought...  While I had some trouble using my PK3 under MPLAB 8 I've been using it with MPLAB X for about a month now without any issues.  Considering the PK2 will not support newer chips, you might consider getting the PK3.

The PK2 does come with a demo board which can be an advantage.  The alternative is to breadboard your project.  The PK3 comes with a poster which shows the exact minimum wiring requirements and there is a detailed howto on breadboarding a PIC24 here: http://www.ece.msstate.edu/courses/ece3724/main_pic24/labs/board_walkthru_pic24.pdf

If you get your feet wet with the PIC24, this page has lots of useful and practical information: http://www.reesemicro.com/Home

Once again, good luck!
 

Offline T4P

  • Super Contributor
  • ***
  • Posts: 3706
  • Country: sg
    • T4P
Re: Arduino User looking to move to PIC
« Reply #40 on: May 24, 2012, 09:25:45 am »
And don't forget to read the sillicon errata !
 

Offline caroper

  • Regular Contributor
  • *
  • Posts: 193
  • Country: za
    • Take your PIC
Re: Arduino User looking to move to PIC
« Reply #41 on: May 24, 2012, 12:11:28 pm »
Nobody has given the obvious answer to the original question.

I have used an atmel arduino as my microcontroller of choice for a few years now and I am looking to move to using PIC micros.

Get hold of a ChipKit Uno.

It is cheaper than the Arduino.
PIC32 Based.
Uses a familiar IDE and compiler.
Will probably support any Shields you have created.
And can be used with a PICKit3 and MPLabX when you are ready to move beyond the Arduino World.

Cheers
Chris

Offline Psi

  • Super Contributor
  • ***
  • Posts: 7415
  • Country: nz
Re: Arduino User looking to move to PIC
« Reply #42 on: May 24, 2012, 12:43:57 pm »
Since the OP has already gotten to know Arduinos their next move should be a next gen chip, like an ARM micro.

Not much point going from one 8bit micro to another one.

Going to 32bits however will really help in a lot of areas, like floating point math.
And the price difference isn't much at all.
« Last Edit: May 24, 2012, 12:46:54 pm by Psi »
Greek letter 'Psi' (not Pounds per Square Inch)
 

Offline caroper

  • Regular Contributor
  • *
  • Posts: 193
  • Country: za
    • Take your PIC
Re: Arduino User looking to move to PIC
« Reply #43 on: May 24, 2012, 03:08:03 pm »
Since the OP has already gotten to know Arduinos their next move should be a next gen chip, like an ARM micro.

Not much point going from one 8bit micro to another one.

Going to 32bits however will really help in a lot of areas, like floating point math.
And the price difference isn't much at all.

I think you missed the point entirely.
The CHIPKit Uno is a 32 Bit MIPS based PIC Board.

Avoiding the whole PIC vs AVR, ARM vs MIPS, Arduino vs DIY arguments, the OP has experience with Arduino and wants to try a different family of chips. The CHIPKit avoids learning a new IDE and flavour of C, whilst providing a step into 32Bit architecture and costs less than an Arduino board, let alone a PICKit3 Programmer and the components required to breadboard a PIC circuit.

A Win Win situation, try it you may like it.

Is the ARM even available in a Hobby Friendly format?

Cheers
Chris

Offline xquercus

  • Contributor
  • Posts: 47
  • Country: us
Re: Arduino User looking to move to PIC
« Reply #44 on: May 24, 2012, 03:53:37 pm »
Quote
Since the OP has already gotten to know Arduinos their next move should be a next gen chip, like an ARM micro.
Not much point going from one 8bit micro to another one.

I get the impression that the OP would like to try his hand at some PICs.  Getting into ARM (or AVR, 8051, etc.) doesn't accomplish that goal.
 

Offline baljemmett

  • Supporter
  • ****
  • Posts: 666
  • Country: gb
Re: Arduino User looking to move to PIC
« Reply #45 on: May 24, 2012, 04:15:44 pm »
Is the ARM even available in a Hobby Friendly format?

The mbed devices are quite pleasant to mess around with.  The whole 'online compiler' thing might turn a few people off, although I understand it's perfectly feasible to use a more traditional local toolchain instead.
 


Offline xquercus

  • Contributor
  • Posts: 47
  • Country: us
Re: Arduino User looking to move to PIC
« Reply #47 on: May 24, 2012, 06:23:21 pm »
While I haven't used that chip it does strike me as a good first pick as it does not seem to use Peripheral Pin Select.  All the peripheral pins are "hardwired".  PPS is a great feature but not having to configure it before using a UART, SPI interface, etc. will make the learning curve a bit easier.

A reminder with the PICKit 2 that I think it's going to tend to default to 5V out which will fry the PIC24s.  I don't recall the exact interface for the PK2 in MPLAB but make sure you lower the output voltage to 3.3V or disable USB power entirely.  The later is generally the preferred option -- just power your breadboard with a walwart / power supply and a 3.3V voltage regulator -- and disable the power pin on the programmer.  Perhaps pick one up in the same order if you don't have one.  The LM2937 discussed in the PDF I linked earlier costs $1-$2 and is commonly available.
 

Offline charliehorse55

  • Contributor
  • Posts: 12
Re: Arduino User looking to move to PIC
« Reply #48 on: May 24, 2012, 06:49:12 pm »
That is the 24FV,

The V means 1.8V to 5.5V operation

 

Offline xquercus

  • Contributor
  • Posts: 47
  • Country: us
Re: Arduino User looking to move to PIC
« Reply #49 on: May 24, 2012, 08:06:50 pm »
Quote
The V means 1.8V to 5.5V operation

Ahh, fantastic!
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf