I’m looking to migrate a product from Microchip (due to many bugs with them I have found when getting to large 20kb+ size code with many different PICs).
It took a good while to figure out what ARM products are what, 8bit, 16bit, 32bit, what is top spec and low spec, and generally finding out any difference between any of them was not very clear.
I have finally come to the conclusion the ARM7 and 9 are more legacy so they are out, the R are for applications IIRC so too high up for embedded projects, and the Cortex are the most popular range. Within the Cortex the M0 are the basic embedded starting point, and the 3 and 4 just get more involved and aimed at running OSs etc… which again is more than my needs. Is that about right?
So with the Cortex M0 and M0+ as the choice, I found another issue of finding out which one to buy as unlike Microchip there isn’t just a range of M0 and M0+ chips for example, but many different companies making spin-offs based on the Cortex. Cutting through all the crap I found NXP seem to be a good choice. Anyone recommend them or others?
Anyway, back to my question - the biggest issue I have found is the ADC channels on any range. My current product I want to migrate needs at least 10 but ideally 14 channels, but any Cortex even top spec I can only find 8 channels.
Are the channels remappable to different pins so I can switch to difference sources or are they fixed? I only need to read one channel at a time although reading multiple would be good, so if the channels could be swapped to any pin in code that would work. Otherwise I don’t have a solution.
I could just use an analog switch to change sources but that has many more issues down the line in code and effeciency for me, so would really like to keep it on one chip like it already is.
I have not stumbled across any ARM processors with more than 8 channels regardless of the number of ADC engines, but that does not mean they do not exist. Regardless of the pain, an analog mux may be in your future. With an 8 to 1 mux, you only need three GPIO pins to drive it. From a SW standpoint it would be hardly more difficult than writing to the channel select register or as you suggested the pin map registers.
ST Micro makes a good line of processors. Using STM32 (M3) at work with good results.
Cool thanks that STM32 looks pretty sweet - so much more power and features than the PICs I’m using… exciting. Is there a good dev board with one on save me making up a proto PCB or breadboard just to get used to the new coding and what not?
NXP probably has largest market share, or maybe ST.
the STM32F4DISCOVERY is really sophisticated… and daunting. I have one.
Without so many ADCs, the graduate from 8 bitters can go to the mbed.org things. Lots of collaboration/contributed code. Novel on-line compiler and downloader.
angelsix:
I’m looking to migrate a product from Microchip (due to many bugs with them I have found when getting to large 20kb+ size code with many different PICs).
(long time AVR user… wondering about what kind of bugs. I’m not surprised though, as so many PICs are so crude; lacking a real stack, bank-switched RAM, and other 1970’s era stuff.
ST is the largest with just over 50% share of the Cortex-Mx market.
MCHP/PIC is the smallest (in terms of revenues) of the mainstream MCU manufacturers - even Atmel (AVR) is bigger. Freescale, NXP and ST are 4-5x bigger, TI is almost 10x as big.
stevech:
NXP probably has largest market share, or maybe ST.
the STM32F4DISCOVERY is really sophisticated… and daunting. I have one.
Without so many ADCs, the graduate from 8 bitters can go to the mbed.org things. Lots of collaboration/contributed code. Novel on-line compiler and downloader.
I agree. I started with pics, then avrs, then tried a M3. Very steep learning curve, open source tools are there, but takes real work to get setup.
Libs and code are ‘harder’ to find (not much shar’n going on ya know - probably more activity in the closed commercial world). The M4 is even newer and more expansive. Commercial tools of course cost lots more than open source but get you running much faster.
rmteo1:
ST is the largest with just over 50% share of the Cortex-Mx market.
MCHP/PIC is the smallest (in terms of revenues) of the mainstream MCU manufacturers - even Atmel (AVR) is bigger. Freescale, NXP and ST are 4-5x bigger, TI is almost 10x as big.
Not what I'd use for comparison... TI, Freescale .. Microprocessors are probably a small portion of their revenue. Both scramble to compete with MCUs and state of the art SoCs and SoMs - and do willy-nilly acquisitions (such as Luminary Micros). For some reason, NXP and ST don't fall into that chasm.
PIC’s are amazing: Brilliance in marketing overcomes absolute crap and antiquated architecture.
A smoother path from 8 bitters to M3’s (or M0) is embed.org - as a learning platform. Decent collection of libraries, both from mbed.org (NXP backed) and user contributed.
@stevech - bugs, well I’ve worked with PICs for a good while from assembly coding them up to about 4kb programs until it just got too time consuming (I really like sticking to ASM as know exactly what goes on, unlike leaving it to a compiler and linker) and didn’t really have any bugs just the odd silicon error. Once moved to 16bit and using C30 I got dozens of issues.
All seems to be related around larger code. Once I got 95% full on a PIC24F16KA301 and another 16kb one (can’t remember which) I got random errors where the code would sometimes not work at all, or the chip would constantly reset at a random line of code (changed if you added any more lines), or it would seem to work but all ADC readings at a certain point in time would consistently be wrong. Enabling compression and the likes sometimes fixed it and sometimes made things worse.
Moved to PIC24F32KA302’s with twice the memory, and low and behold at 49% full (so almost identical code size) similar issues.
That on top of many other things is just something I cannot tolerate for upcoming projects, as they are basically unresolvable. The code is fine, but the compiler or chip obviously have issues as like I say you can remove one line of any part of the code and it all works, add one more and it constantly resets itself etc… I need something more stable.
Onto the STM32’s - man they are a little more expensive than I thought, but worth it for the specs on them. I’ve got a touchscreen dev board with an F4, an F0 with some sensors, and just some ICs of the L1s which I think are the ones I will plan to use. They are M3 cores and ultra low power, with a good price of £1.90 once in volume.
My main question now is what software (free and commercial) do you use on these things to program them. Do they get programmed over ICSP, JTAG or other? I could find all this out with enough reading and time but any quick start advice to get me going on these things is great.
I presume like most ICs all Vcc/Vdd pins are best coupled with 0.1uF caps?
Ok I’ve got CrossWorks and Keil installed now and can connect the L discovery up to it and program it no problem so I am good to go starting on that.
Any good resource sites for sample codes and basic tutorials to get me started on porting over from Microchip?
The next question is basically how do you program the chips yourself? The dev board is obviously using another STM32 and I believe its basically an ST Link V2 setup? That’s all good for now but I plan to make my own boards pretty soon and want a good top quality programmer/debugger.
From what I have gathered reading so far you can program the Cortex series using any of the interface pins (SPI, I2C, USART etc…) is that right? So I would get a programmer and it offers certain interface outputs I can wire to the chips? Or is that not quite right.
And on that note - any recommended programmers? The only one I have found from searching is a Segger J-Link.