Arduino User looking to move to PIC - Page 1
Forum section: electronics / general

author: charliehorse55
author_rank: Contributor
timestamp: May 05, 2012, 04:08:09 am
content: 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. For my first project I am trying to make a bridge between DMX512 and three PWM signals. I want three PWM channels with at least 12 bits of resolution at 200 Hz (I know it might not exactly be 200 Hz because of prescaler values). Which PIC should I use for this? There are so many to choose from.I will be developing on OSX and linux, is there an IDE to use or will I just be stuck with a command line compiler/debugger?Can you program a PIC in C? Everyone seems to talk assembler for PIC.

author: mariush
author_rank: Super Contributor
timestamp: May 05, 2012, 04:20:48 am
content: I'm using MPLAB-X on Windows :http://www.microchip.com/pagehandler/en-us/family/mplabx/As it's based on netbeans ide code, it runs on Linux and Mac.. in fact you can select the distro from the download page (left corner).It can work with several compilers, they can be added like plugins... and I'm using Hi-Tech C compiler. So I guess that answers your question about programming in C.They have some new batch of compilers called XC ... not sure what they are as i didn't test them yet, but I suspect it's just a rebranding of the hi-tech c compiler with maybe some different compiler for what hi-tech didn't support.Not sure what micro to recommend for 3 pwm signals, so far I had no use for so many. Maybe others can chip in.

author: xquercus
author_rank: Contributor
timestamp: May 05, 2012, 04:56:49 am
content: I'm not familiar with your specific application though the microchip web site has a product selection tool. That might help you narrow things down. The only PWM I've done has been in software. At most, I've used a timer to generate an interrupt. If the 16F and 18Fs have any additional on chip PWM hardware to assist with the task I've not used it, though I'm just a hobbyist.If you are looking at the PIC18F family, there are two main C compiler options. The first is Microchip's C18 compiler. This is what I've used and it's going away. The second option is HI-Tech. My understanding from reading the MC forums is that the upcoming XC compiler is based on Hi-Tech.In either case, both compilers have free unoptimized compilers available. The MPLAB IDE interfaces well with both of them. Just this week I upgraded to MPLAB X and it works well on Windows. I've heard a number of minor complaints about using it on Linux (mandatory reboot after install/root required for install), but in general, it seems to be functional.I'm not personally familiar with anything other than the 16F and 18F families so I can't comment further. If you are moving over from an Arduino, take a look at the 18F line and see if that meets you needs in terms of general capabilities and performance.Though (my understanding is that) C18 is going away, see if you can get a copy of "Applying PIC18 Microcontrollers" by Barry B. Brey. It has a great deal of example code dealing specifically with C18 and the PIC18F family. Of course, if you delve into Hi-Tec C, another book might be more appropriate.Good luck!

author: Jon Chandler
author_rank: Frequent Contributor
timestamp: May 05, 2012, 05:19:29 am
content: Quite a bit of DMX work has been done in Swordfish Basic on PIC18F-series controllers.You can see the details here:PIC based DMX Dimmer

author: Rufus
author_rank: Super Contributor
timestamp: May 05, 2012, 05:28:28 am
content: Quote from: charliehorse55 on May 05, 2012, 04:08:09 amI would likely go for one of the PIC24Fshttp://www.microchip.com/ParamChartSearch/chart.aspx?branchID=8181&mid=14&lang=en&pageId=75They have up to 9 16bit output compare/PWM generators.I can't recommend PIC18s, klunky architecture and hard to find applications where they have an advantage over the 16 bit parts. PIC10/12/16s are useful for smaller applications. PIC32 if you want 32 bits but they are not hugely faster or have much more memory than the 16 bit parts.MPLABX is the new cross platform IDE but being new it is not without issues.There are C compilers for all parts. They are free to use with optimisation restrictions. The 16 and 32 bit compilers (C30 and C32) are GCC based and generate quite respectable code with the optimization limits. Generated code from the free 8 bit compilers (previously Hi-Tech) is pretty bad.They are in the process of rationalizing the compiler range down XC8, XC16, and XC32. The free version of XC16 and XC32 might be a bit more crippled than the free versions of the current C30 and C32.

author: nctnico
author_rank: Super Contributor
timestamp: May 05, 2012, 10:51:35 am
content: I agree. I'd stay away from the 8 bit PICs (those are a step back from the position the TS is in). Programming C for 8 bit PICs can be done but it is seriously crippled. For instance: using pointers gets you a severe speed penalty. IMHO a PIC32 or ARM Cortex controller would be a much better choice. None of the professional designers I've been talking to uses 8 bit PICs.If you want to use Linux or OSX there is Eclipse which can be used as an IDE. For programming and debugging you can use OpenOCD in combination with a simple parallel port JTAG programmer. A cross-compiler can be downloaded from:http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition/(formerly Codesourcery).

author: free_electron
author_rank: Super Contributor
timestamp: May 05, 2012, 11:52:25 am
content: Why would you want to move from AVR to PIC ?That is like a step backwards, unless you go for pic32.Pic 18f is sort of ok. The problem with pic is the hardware stacks and the banking. They are kludges to extend a broken architecture.Pic32 is a real core (actually a MIPS based machine )But, why not bite the bullet and switch to a Cortex based machine ? This is very fast becoming the new standard.Problem with pic and avr is that you are stuck to 1 manufacturer... Only microschip makes pic, only atmel makes avr.As for cortex based machines , ti , st , nxp , and many others have chips with that core. And every day new devices are released.

author: A Hellene
author_rank: Frequent Contributor
timestamp: May 05, 2012, 12:12:35 pm
content: Charliehorse55, I will absolutely agree with Free_electron.If you need to know the reasons why not to move from AVR to PIC, please take the time to read the quoted passage atthis message.Quotingsomeone competent in both architectures:- The AVR has thirty-two target registers, sixteen of which can be an 'accumulator'; the PIC has one.- The AVR can perform conditional jumps; the PIC can only skip one instruction conditionally.- The AVR has individual vectors for each interrupt; the PIC has a single interrupt for all.- The AVR has a contiguous RAM memory space; the RAM on the PIC is accessed either by setting one or two bits in the status register to select the required bank or by using an indirection register (and potentially another selector bit).- AVR registers are accessible through specialised instructions or as direct memory addressing; PIC registers are available only through the paged memory system.- AVR completes one instruction per clock cycle; the PIC requires four cycles.- The AVR has a stack available to the program and potentially as large as the internal RAM; the PIC has eight levels, with no user stack.- The PIC peripherals are generally not as useful as those of the AVR, in particular the timers (though the PIC can offer interrupts on more pins (I think) than the AVR).In general, on the AVR you generate code which targets the 'accumulator' registers; on the PIC most operations target memory directly.-George

author: T4P
author_rank: Super Contributor
timestamp: May 05, 2012, 12:16:09 pm
content: Go with STM32F1 or STM32F4 you can also go for NXP's cortex M3/M4 or TI's Stellaris Cortex M3 but the highest clock belongs to STM32F4God i love the STM32F4 so much i am a sucker for ST's micros now.One thing very big about ARM is once you learn ARM you can do nearly all ARM without difficulties because device to device only change in terms of device specific.In AVR/PIC it's about assembly and the C is a little bit different so if you can, make the move to ARM although ARM is only available in LQFP.OR you can use the MSP430, low power high performance for a 16bit chip.AVR is a hell lot more advanced than a PIC, even calculating in the extra cost

author: Psi
author_rank: Super Contributor
timestamp: May 05, 2012, 01:15:29 pm
content: Quote from: Dave.S on May 05, 2012, 12:16:09 pmThat's mainly because the AVR instruction set was designed to be used by a C compiler efficiently.Where as the PIC instruction set was designed for writing programs in ASM.

author: Unknown
author_rank: Unknown
timestamp: May 05, 2012, 01:42:20 pm
content: I don't think that it's useful to have another PIC vs. AVR debate here. The point remains that moving from AVR to another 8/16-bit architecture like PIC or MSP430 is mostly a horizontal move: you gain some improvements, and lose some other things. If moving to another MCU family represents a significant investment in time and equipment for you, than it may make more sense to either stick to AVR (you can use an Arduino to program any AVR, and you can program them in C), or move up to some 32-bit architecture (eg. PIC32, ARM Cortex) if you need more performance/peripherals.

author: nctnico
author_rank: Super Contributor
timestamp: May 05, 2012, 03:29:33 pm
content: Googling a bit for 'arduino arm' came up with this website:http://www.xduino.com/hardware/

author: bxs
author_rank: Regular Contributor
timestamp: May 06, 2012, 08:47:33 pm
content: So people already started a PIC vs AVR, why?I also think that for 99% of the jobs doesn't matter, the 2 will do the job and if you know well one brand, the only reason for change is because you want to simple taste other things, witch is good thing if you have time for it.About PIC on OSX and Linux, the way to go is MPLAB X, and yes, you have C compilers

author: Galenbo
author_rank: Super Contributor
timestamp: May 06, 2012, 09:17:05 pm
content: @charlieHorse:I use a Mikroelektronica board with Pic 18F4520, language MikroC.Some will (for their reasons and background) not think this is the optimal choice.For me, it is. I'm a newbie in microcontrollers, with a large expierience in PLC, LabView and Drives.MikroC gives me a big jumpstart, with more predevelopment and examples than something else.So I can only advise to take a look at it, and determine if it's any good for your situation.Customer service is excellent and the quality of the boards is very fine..

author: ColinB
author_rank: Contributor
timestamp: May 10, 2012, 01:52:38 pm
content: Quote from: nctnico on May 05, 2012, 03:29:33 pmIf you're looking for an Arduino-like platform with a more powerful ARM Cortex micro, look at theLeafLabs Maple. There is even a Maple clone from Olimex now, calledOLIMEXINO-STM32.

author: EEVblog
author_rank: Unknown
timestamp: May 10, 2012, 02:05:54 pm
content: Quote from: bxs on May 06, 2012, 08:47:33 pmI chop and change between PIC and AVR based on the project requirements. Usually features vs package vs price vs availability. Whichever is the most suitable gets the job.All the arguments about which is best is pretty pointless unless you have direct requirements context.Dave.

author: nctnico
author_rank: Super Contributor
timestamp: May 10, 2012, 07:49:24 pm
content: A controller may look good price and feature wise but you'll need to look at a much bigger picture to make the best choice. Unless you are running >50k quantities of each product the biggest cost of a product is software. Using multiple incompatible platforms means you'll need to write and maintain more software than strictly necessary which means wasting money.The most succesfull and profitable companies I've worked for didn't care much about cost of a controller as long as it was easy to write software for the platform (series), could be used in every product and had an upgrade path into the future. Nowadays controllers can run more and more software so the choice for a future proof platform becomes even more important. NXP's ARM controllers are a good example of such a path. Most software written for their LPC2000 ARM7 controllers can be reused on their Cortex controllers because the peripherals are (almost) identical.I vividly recall a meeting I attended many years ago. My employer at that time was interested in purchasing some DSP algorithms so they invited some peope over who already created cards with DSPs and software. It quickly turned out they wrote everything in assembly language and the DSPs they where using where about to become obsolete. They had to rewrite c.q. sift through many human years worth of code to get it working on different DSPs. This basically means putting a company on hold regarding new products and/or adapting to a changing market. In the end my employer opted for doing the processing on PCs and use C as the programming language because that solution would never have problems with getting obsolete while providing lots of processing power.

author: xquercus
author_rank: Contributor
timestamp: May 10, 2012, 08:18:17 pm
content: The OP commented about having a background with the Arduino and an interest in PICs. My assumption, which may be incorrect, is that the OP is interested int PICs for hobby use. His post seemed to allude to this. I'm an electronics hobbyist and have no professional experience. Are some of the comments in this thread a bit less critical for us part timers to consider?

author: Unknown
author_rank: Unknown
timestamp: May 10, 2012, 08:42:27 pm
content: I would say the issue of learning and tools cost is far more important for the hobbyist than even small business. If you don't mind the costs and time investment, then I see no harm in switching. Just don't expect huge advantages for any of the popular 8/16-bit micros. As Dave has stated repeatedly, it's pretty much a wash, all have some advantages and issues.

author: nctnico
author_rank: Super Contributor
timestamp: May 10, 2012, 09:08:12 pm
content: Quote from: xquercus on May 10, 2012, 08:18:17 pmThat depends on what you want to do. Get to know as many microcontrollers or just build cool stuff. If you choose one very versatile platform which you get to know inside out over time and collect a big library of routines you can build the most amazing stuff in one evening.I started with 8051 controllers. At one point I found myself spending more time armwrestling with the controller than getting actual work done for a project. That made me move to TI's MSP430 and from there to ARM.

author: free_electron
author_rank: Super Contributor
timestamp: May 10, 2012, 09:43:46 pm
content: I typically don't care about the core used. I am after the built in peripherals. i'll select a chip in functions of the on board stuff...I do try to stick as much as possible to vendorless cores like 8051 , cortex et al ...i don't like processor cores that can only be gotten from one vendor .. ( like PIC , AVR ) they are not bad and sometimes i do use them , but the advantage of a vendorless core is that you have a bigger pond to fish in ... there are at least 50 companies making chips with a 8051 core. and there are at least 10 companies making chips with cortex cores...Heck , even analog devices has an 8051 based cpu with a 24 bit a/d converter !Zilog just release an 8051 base machine.And as for silabs ... they have the 8051F120... that beast screams at 100 mips ... has hardware mulitply and devide.silabs also has 8051 that can run off 0.9 volts ...I personally like harvard machines over von neumann , simply becasue memory is partitioned. no problems with 'data' overwriting 'code' because of a pointer problem...The 8051 has long been my favorite although now i am rolling bit by bit into the cortex machines.i like the 8051 because of the 4 register banks. it is extremely easy to make code that runs in threads. you can assign a routine to one bank and don't need to do 'contect swaps' , something that on other architectures takes time because you need to push and pop stuff on the stack to get in and out... it also allows very very fast interrupt response. you don't need to save anything or restore anything , just switch bank. On an Arm7 context swap is horrible... you waste sometimes 50 instructions just popping in and out ....cortex fixes that by having special switch instructions. ( cortex is also a harvard machine where a regular arm is a flat von neumann machine )

author: nctnico
author_rank: Super Contributor
timestamp: May 10, 2012, 10:59:55 pm
content: Quote from: free_electron on May 10, 2012, 09:43:46 pmWait until you start programming C on a pure Harvard CPU. Because of 2 or more seperate memories pointers need an extra 'tag' to tell which memory they are pointing to. This needs to be handled at runtime and makes the code extremely slow. There is a good reason you don't see new pure Harvard CPUs anymore...QuoteReally? ARM7 has seperate register banks for use during interrupts. If you are carefull with the registers you can write IRQ handlers without the need for pushing and popping. 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.QuoteYou are mistaken seperate code fetch, memory access and system buses for Harvard. Those have nothing to do with a Harvard architecture! The Cortex devices have (simply put) multiple busses in parallel to gain performance. The larger LPC2000 ARM7 devices from NXP also have a similar bus matrix which allows to have multiple devices access memory devices in parallel as long as there are no conflicts. For example: at the same time the CPU can fetch the next instruction from flash while the DMA controller is transferring data from the ethernet MAC into SRAM.Actually the CortexM cpus are much simpler than the ARM7 cpus. No more register banks and many seperate stacks for different IRQ levels. 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. Which is nice because it allows interrupt handlers to be plain C functions. Even better: you don't need a single line of assembly code to get a CortexM controller going.

author: yanir
author_rank: Regular Contributor
timestamp: May 11, 2012, 02:58:55 am
content: Quote from: Rufus on May 05, 2012, 05:28:28 amI agree, I've been using the pic24f series for a few years and although they are not perfect they are a good balance between power and ease of use. I've made a few products with them and theMain problems they have are usually compiler / IDE bugs (which are infuriating). But the chip is a solid micro. I code in C and there are plenty of app notes and sample projects to get you going.

author: jerry507
author_rank: Regular Contributor
timestamp: May 11, 2012, 04:48:57 am
content: "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.I use many different processors, but I LIKE PICs so I try to use them. I recently used a TI cortex for it's USB host capability. Having gone through that experience, I'll go with Microchip next time, likely a pic24. Peripherals do largely guide my choices, but a huge area for me is documentation. TI documentation sucks and there aren't a lot of people on their forums, but Microchip has considerably better app notes, better technical support and though their forum sucks mechanically it's got users.That ranting aside, I would recommend the same as other posts, go with a pic24. It's newer, there are better packages of peripherals IMO and the prices aren't even that bad. 18 series pics are generally left to the serious penny pinchers now, though when they came out they were much better than the 16 and 17 series. I don't go for the 32 bit MIPS ones, but that's purely because they are always too big for my requirements.

author: Rufus
author_rank: Super Contributor
timestamp: May 11, 2012, 09:31:09 am
content: Quote from: jerry507 on May 11, 2012, 04:48:57 amPeople (including me) complain that Microchip documentation sucks but I haven't recently needed to look at other vendor parts to establish the current industry standard level of sucking.Also good to see some people understanding that there are at least 4 families of processor called PIC and statements like PICs suck or PICs are worse than x are just ignorant.

author: free_electron
author_rank: Super Contributor
timestamp: May 11, 2012, 02:35:08 pm
content: Quotewhy 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 !Quoteno 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.QuoteNo 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.QuoteHaving separate address and databuses for code, data and io classify as harvardQuotethats 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..

author: free_electron
author_rank: Super Contributor
timestamp: May 11, 2012, 02:47:21 pm
content: Quote from: jerry507 on May 11, 2012, 04:48:57 am.?? 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 inSetdirection porta pin6 outSetdirection porta pin5 inSetdirection 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'...

author: A Hellene
author_rank: Frequent Contributor
timestamp: May 11, 2012, 02:51:44 pm
content: QuoteIndeed...-George

author: nctnico
author_rank: Super Contributor
timestamp: May 11, 2012, 04:57:29 pm
content: Quote from: free_electron on May 11, 2012, 02:35:08 pmForgot about the exceptions?QuoteWhich 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.QuoteWell ARM7 does have those instructions. RTM!QuoteReading the manual first might be a good idea because a lot you wrote simply isn't correct.

author: jerry507
author_rank: Regular Contributor
timestamp: May 11, 2012, 06:07:55 pm
content: Quote from: free_electron on May 11, 2012, 02:47:21 pmWe 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.

author: free_electron
author_rank: Super Contributor
timestamp: May 11, 2012, 07:00:34 pm
content: 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 simplyif (real_speed != target_speed) thenif (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 R12FIQ 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.phpWhich is exactly what i stated.

author: yanir
author_rank: Regular Contributor
timestamp: May 11, 2012, 07:57:09 pm
content: Quote from: free_electron on May 11, 2012, 07:00:34 pmThis 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.

author: free_electron
author_rank: Super Contributor
timestamp: May 11, 2012, 08:20:06 pm
content: Quote from: yanir on May 11, 2012, 07:57:09 pmWell 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.QuoteYes, 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 ...

author: jerry507
author_rank: Regular Contributor
timestamp: May 11, 2012, 08:41:02 pm
content: 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.

author: yanir
author_rank: Regular Contributor
timestamp: May 11, 2012, 08:49:00 pm
content: Quote from: free_electron on May 11, 2012, 08:20:06 pmHey, take it easy, no need to let your buffers overrun.

author: free_electron
author_rank: Super Contributor
timestamp: May 11, 2012, 09:11:32 pm
content: Quote from: yanir on May 11, 2012, 08:49:00 pmbuffer overflow at 0xDEADBEEF . calling emergency handler ad 0x10C0FFEE....

author: nctnico
author_rank: Super Contributor
timestamp: May 11, 2012, 09:28:07 pm
content: Quote from: jerry507 on May 11, 2012, 08:41:02 pmIf 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

author: charliehorse55
author_rank: Contributor
timestamp: May 24, 2012, 05:25:52 am
content: 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=DV164120The software package seems to be Windows only. Any idea What should be looking at for a compiler/debugger on OSX ond Linux?

author: xquercus
author_rank: Contributor
timestamp: May 24, 2012, 06:36:41 am
content: 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!

author: xquercus
author_rank: Contributor
timestamp: May 24, 2012, 06:51:14 am
content: 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.pdfIf you get your feet wet with the PIC24, this page has lots of useful and practical information:http://www.reesemicro.com/HomeOnce again, good luck!

author: T4P
author_rank: Super Contributor
timestamp: May 24, 2012, 09:25:45 am
content: And don't forget to read the sillicon errata !

author: caroper
author_rank: Regular Contributor
timestamp: May 24, 2012, 12:11:28 pm
content: Nobody has given the obvious answer to the original question.Quote from: charliehorse55 on May 05, 2012, 04:08:09 amGet 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.CheersChris

author: Psi
author_rank: Super Contributor
timestamp: May 24, 2012, 12:43:57 pm
content: 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.

author: caroper
author_rank: Regular Contributor
timestamp: May 24, 2012, 03:08:03 pm
content: Quote from: Psi on May 24, 2012, 12:43:57 pmI 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?CheersChris

author: xquercus
author_rank: Contributor
timestamp: May 24, 2012, 03:53:37 pm
content: QuoteI 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.

author: baljemmett
author_rank: Unknown
timestamp: May 24, 2012, 04:15:44 pm
content: Quote from: caroper on May 24, 2012, 03:08:03 pmThe 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.

author: charliehorse55
author_rank: Contributor
timestamp: May 24, 2012, 04:26:10 pm
content: Okay, I am going to get this:http://canada.newark.com/microchip/pic24fv32ka301-i-p/ic-16bit-mcu-pic24f-32-mhz-20-dip/dp/13T4808?in_merch=Popular%20Productshttp://canada.newark.com/microchip/dv164121/development-tools-pickit-2-debug/dp/16M6058I'll be using the MPLABX IDE for C development.

author: xquercus
author_rank: Contributor
timestamp: May 24, 2012, 06:23:21 pm
content: 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.

author: charliehorse55
author_rank: Contributor
timestamp: May 24, 2012, 06:49:12 pm
content: That is the 24FV,The V means 1.8V to 5.5V operation

author: xquercus
author_rank: Contributor
timestamp: May 24, 2012, 08:06:50 pm
content: QuoteAhh, fantastic!

author: nctnico
author_rank: Super Contributor
timestamp: May 24, 2012, 08:08:56 pm
content: Quote from: caroper on May 24, 2012, 03:08:03 pmI have no problem soldering a 0.5mm TQFP on a board I etched myself. Soldering QFN on a fabricated PCB is also not difficult at all. So yes, a lot of ARM devices are available in hobby friendly formats. Sometimes I rework BGA as well with a simple heat gun intended for stripping paint. Fear is what is keeping people from achieving great things.

author: jerry507
author_rank: Regular Contributor
timestamp: May 24, 2012, 10:08:06 pm
content: Quote from: nctnico on May 24, 2012, 08:08:56 pmHopefully one day my brass balls will hang as low as yours.

author: Rufus
author_rank: Super Contributor
timestamp: May 24, 2012, 11:05:49 pm
content: Quote from: charliehorse55 on May 24, 2012, 04:26:10 pmThe PICKit 2 is obsolete (sadly). The PIC24FV32KA is a new chip and is not supported by the PICKit 2.You will need to look a the PICKit 3. The PICKit 2 was loved, the PICKit 3 less so although I have never used one to know what the problems are.

author: xquercus
author_rank: Contributor
timestamp: May 25, 2012, 12:30:03 am
content: QuoteGood catch if the FV32KA isn't on the supported devices list. Hopefully the OP can adjust his order to a PK3.I had some trouble with my PK3 under MPLAB 8. It would not properly update the firmware. The solution was to simply unplug and reinsert the device (part way through the upgrade) and the firmware updated. That was actually the Microchip provided solution. I don't know if it would be a continuing problem with MPLAB 8 as I've been using it with MPLAB X for the past month. There haven't been any issues which come mind. Pretty rock solid as a programmer/debugger. I haven't used it for anything other than as a programmer/debugger (no programmer on the go experience) but it's worked well in those two roles.

author: charliehorse55
author_rank: Contributor
timestamp: May 25, 2012, 04:29:54 am
content: Quote from: Rufus on May 24, 2012, 11:05:49 pmI hadn't ordered yet, thanks for the heads up. Microchip claimed the PK2 was compatible with all 16, 18 and 20 pin microcontrollers.

author: LuckyJaker
author_rank: Contributor
timestamp: May 25, 2012, 01:57:29 pm
content: I am usign PK3 with PIC32MX custom board and MPLABX and had no problems so far !

author: jerry507
author_rank: Regular Contributor
timestamp: May 25, 2012, 07:00:10 pm
content: The pickit 2 supports everything up to the point when the pickit3 came out, or thereabouts. There is no "continuing support" for the device. The 3 is the same price as the 2 was IIRC, and it's read. That's my favorite color. Anyway, I've had no issues with it either in MPLABX.

author: caroper
author_rank: Regular Contributor
timestamp: May 25, 2012, 10:31:05 pm
content: Quote from: jerry507 on May 25, 2012, 07:00:10 pmActually the PICKit2 is still supported and already supports several of the PIC32 Devices. The latest update is PICkit 2 v2.61 and the latest Firmware is PICkit 2 Firmware V2.32. However, the latest Chips are only supported in the Standalone PICKit application, not via MPLab, and there is no guarantee that it will support the new devices in the future.To be honest, despite its faults, I do recommend the PICKit3 if you are working with any devices released in the past couple of years, just because they have so much more memory and the PICKit3 can program them much faster than the PICKit2. (If you really want speed get the ICD3, I love that tool, but it is a bit expensive for the casual user).CheersChris

author: calin
author_rank: Regular Contributor
timestamp: May 26, 2012, 04:43:55 am
content: If yoou were used to arduino here is a project that looks interesting -http://www.pinguino.cc/Looks pretty interesting .. I never worked with PIC's but the project looks like a tempting intro to PIC's

author: charliehorse55
author_rank: Contributor
timestamp: July 16, 2012, 02:21:12 am
content: I'm bumping an old thread here, but I still haven't ordered anything. A few things got away from me, work was crazy.Anyways, I'm looking at getting the PicKit 3 along with a basic dev board and two different PIC micros to play around with. I'd just like to confirm that everything here is compatible, and that it's all I need to get started with PIC development.PicKit3 Debugger -http://canada.newark.com/jsp/search/productdetail.jsp?sku=25R831140 pin DIP Development Dev Board:http://canada.newark.com/jsp/search/productdetail.jsp?sku=25R492740 Pin DIP 8 Bit PIC 18F -http://canada.newark.com/jsp/search/productdetail.jsp?sku=05K202828 Pin DIP 16 bit PIC 24J -http://canada.newark.com/jsp/search/productdetail.jsp?sku=07P9729Also, I would to make sure that it is possible to implement USB communications (device only) without any external chips on both of the microcontrollers that I linked.

author: David_AVD
author_rank: Super Contributor
timestamp: July 16, 2012, 02:59:52 am
content: I assume you're making a RGB DC dimmer with DMX input? Was the 12-bit requirement for gamma correction or are you planning to use pairs of DMX slots as 16-bit channels?