View unanswered posts | View active topics It is currently Sat Dec 07, 2019 1:51 am



Reply to topic  [ 29 posts ]  Go to page 1, 2  Next
 moving to another microcontroller family: experiences? 
Author Message

Joined: Tue Dec 11, 2012 8:03 am
Posts: 272
Location: California
I have been using PIC16 µCs for 18 years. They were a suitable fit for early work projects, but the last one has had me taking PIC16 far beyond what it was designed to do, and future projects may go further. I have a lot invested in PIC16, in terms of learning its traps, its I/O, having a lot of code I can re-use (including my structure macros and other macros), knowing the MPASM assembler really well, having my own home-made, production-worthy programmer, etc.; so I do not take lightly the idea of switching families.

However, I'd like to look into a new µC family for the next 20 years' work. I've studied the PIC18, but although it fixes some of the PIC16 problems, it still has too many of them left. I understand the PIC24, 30, and 32 processors have entirely different architectures. I don't know yet if at least the peripherals on them are compatible. In the kind of work I do with constant I/O bit-twiddling, 8-bit is enough, even for A/D and D/A (or PWM), but I especially need to get away from the banking and paging problems. The very little I've heard about Atmel's AVRs sounds good, but according to Dave Jones in his EEVBlog, Atmel is not in as good of a financial situation to survive in the long term. I don't want this to be a self-fulfilling prophecy though. Daryl Rictor on the 6502.org forum has spoken well of AVRs, and many there have cursed PICs.

I'd like to hear about observations, experiences, research, and maybe even hearsay to look into, comparing microcontroller families, in areas including (but not limited to):
  1. relative performance for different types of work (in terms of time to get a job done, regardless of MHz)
  2. interrupt performance
  3. whether there's a non-Windows support (assembler, programmer). Since my DOS-based PIC assembler won't do PIC18's, I downloaded Microchip's MPLAB X toolchain for Linux, and it would not install on one computer, and promptly crashed on the other; so since I don't have problems with any other Linux software, I'd have to say Microchip is not committed to Linux. This was last summer, so perhaps things have improved since then.
  4. relative ease in learning
  5. traps (I can list a huge pile of them for PIC16!)
  6. quality of documentation
  7. bugs in the assembler?
  8. quality of technical support (I probably shouldn't bother with TI)
  9. price and availability of the actual ICs in small production volumes
  10. projected long-term availability

I suppose they nearly all come with a wide array of onboard I/O, timers, µP support like power-up timer, watchdog timer, onboard oscillators with different modes, etc., so this might not a point of concern (although maybe I should still be careful).

I will probably do mosty assembly-language programming, to keep tight control of timings for my hard realtime applications, and convert my structure macros and other macros to the new µC to get some of the benefits of higher-level languages without losing any of the benefits of assembly.

I'm only starting this journey. I'm not really in a hurry. I have time to collect info and look into candidates. (Knock on wood-- That situation could change unpredictably.)

_________________
http://WilsonMinesCo.com/ lots of 6502 resources


Last edited by Garth on Sat Jan 28, 2017 1:14 am, edited 1 time in total.



Sat May 24, 2014 5:29 am
Profile WWW

Joined: Fri Jan 10, 2014 11:19 pm
Posts: 25
A few years ago I set out to write three Forths for New Micros boards: MSP430, ARM (LPC2138), and AVR. So far I have done one -- the MSP430, which has occupied a lot of my time, for various reasons. Capsule summary:

I really like the MSP430 family. One thing TI gets right is hardware. The I/O is very versatile, and you often don't need external logic. (Another manufacturer that seems to get that right is Freescale.) I also love the instruction set. The downside is, I don't think it gives you much of an edge over the PIC16. (Even the MSP430X devices are 16-bit devices with address extension hacks.)

I think the AVR is the least powerful of the three. It's essentially an 8-bit MCU, and its addressing capabilities are pitiful. That's probably why it's the last of the three to get my attention for a Forth implementation. That said, I'm working on a new project now that will use an AVR chip because of the specialized hardware requirements.

Lately I've been working with an older ARM7 chip, the Philips/NXP LPC2138. The chip is easy to design with, though I find its I/O to be more simplistic than other chips I've used. (Note, that's an NXP design decision, not an ARM consideration. Other manufacturers' ARM chips might be better.) I like the instruction set, and it's easy to write assembly code for it (though some old habits will have to change -- e.g. you have to explicitly request that an instruction set the status bits). The downside of the ARM is that you'll get about half the code density. Perhaps the Thumb instruction set would help this, but I've been tinkering with a Forth implementation and I find that often I need twice as many Thumb instructions, so no help there. Of the chips I'm using, it's the fastest.

If you're looking to grow beyond 16 bits, and looking for widespread (e.g. Linux) tool availability, I'd suggest one of the embedded ARM devices.

_________________
1802, 6809, 8051, 8086, MSP430, Z80 -- there's a Forth for that: http://www.camelforth.com


Sun May 25, 2014 7:45 pm
Profile WWW

Joined: Tue Dec 11, 2012 8:03 am
Posts: 272
Location: California
Thanks, Brad. Keep it coming, addressing, where possible, the 10 points in my listing, which should have also included quality of the assembler.

I've been using Forth for almost 25 years, yet I am challenged again by a pair of articles Ed linked to on the 6502.org forum:
Low Fat Computing: A politically incorrect essay by Jeff Fox 12/6/98, and, in spite of the seemingly unrelated article title,
ANSI Forth is ANTI Forth (Another politically incorrect essay)
Although I don't need an F21 for my work which is apparently the simple one he's talking about that can do 27 Forth primitives in 2ns each, the articles challenge me again to make better use of computing power. Working with Chuck Moore, the inventor of Forth, they used Forth hardware and (non-ANSI) Forth software to improve the compactness and speed of code by factors of anywhere from 100 to 1000 times. That's not to say a PIC16 is suitable for Forth. Knowing PIC16 quite well, I don't think it's even possible to run Forth on a PIC16. The concept in the articles may still apply though. Obviously the other µCs you mention are able to run Forth—not that they can run it as fast as they can run their assembly language, but at least some very Forth-like strategies can be taken advantage of in them.

The last project had me multitasking, switching tasks 50,000+ times per second [Edit: it ended up being about 10,000 to 15,000 times per second when I was done], while doing audio sampling at 39kSPS and 78kSPS, and I maxed out the return stack (which isn't hard to do on a PIC16) and I had to make adjustments to stop overflowing it, used 5,500 lines of code with my structure macros and other macros, and I used up all the RAM and all the program ROM, and used every pin, every I/O module, and ran at maximum clock speed to get the needed performance. (Actually I'm not quite done, and I have to fit the last piece of code (with its subroutines) in about 100 14-bit words. Edit: I'm done, and there are 7 program words left. How's that for cutting it close!) I could be feeling pretty good, yet these articles tell me I might still be a novice.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources


Last edited by Garth on Sat Jan 28, 2017 1:25 am, edited 5 times in total.



Mon May 26, 2014 8:59 am
Profile WWW

Joined: Fri Jan 10, 2014 11:19 pm
Posts: 25
Sorry, I just gave a quick overview of my impressions of three MCUs, without addressing your ten points. I'll do that next. But first, a reply to your last post.

I'm not familiar with the capabilities of the PIC16, but if you're switching tasks 50,000 times a second, doing audio sampling at 39 and 78 kSPS, then I think you've left the "novice" category.

In my experience, when you get a 100x or 1000x speedup, it's because you've been able to re-engineer the code, or because Forth has given you a technique that other languages lack. E.g., I did the former when I moved a simulation program from a VAX (in Fortran) to an IBM PC/AT (in Forth) -- in the process I found a lot of redundant computation which I was able to factor out. Phil Koopman did the latter when he devised his combinator graph processor, by converting a data structure into an executable program (a technique I've used myself a few times).

I did some interesting work for the New Micros IsoPod, squeezing performance out of the Freescale 56800 family DSP. (Nice chip for fast computation, by the way, but only a 16-bit address space.) We had one task running the IsoMax state machine, at 100 Hz if I recall correctly; a second task doing real-time servo control, running at 1000 Hz; and "software UARTs" running at 9600 baud on several I/O pins. Roughly comparable, I'd say, to what you're doing on the PIC16. (I really need to learn more about the PICs.)

All of which is my way of saying, I don't think you're missing some Chuck Moore-like insight that will make better use of your hardware. Eventually you reach the point where you realize, you need faster hardware.

_________________
1802, 6809, 8051, 8086, MSP430, Z80 -- there's a Forth for that: http://www.camelforth.com


Mon May 26, 2014 9:43 am
Profile WWW

Joined: Fri Jan 10, 2014 11:19 pm
Posts: 25
Now, as to your ten points: I'm afraid I can't be as informative as I'd like. But there's a question I would ask: what do you need? I get the impression that you need a larger memory space -- but is the PIC deficient in on-chip RAM and ROM, or do you need a larger address space? Your last post also suggests that you need more processing speed.

My ARM experience is still limited, but the chips I've examined have unusually large RAM and ROM for their price point (they need the big ROM, because of code density). They also seem to be quite fast -- e.g. I'm using a 16 MHz MSP430, but a 60 MHz ARM (the NXP LPC2138, an older part).

1. relative performance for different types of work (in terms of time to get a job done, regardless of MHz)
Pretty good. Many instructions execute in one cycle. There's a variety of useful addressing modes, and some special capabilities (like conditional execution) that can offer some speedup.

2. interrupt performance
Sorry, I don't know yet.

3. whether there's a non-Windows support (assembler, programmer).
Yes, excellent. GCC is the common platform for the ARM. Mike Kohn is also making ARM available on his cross-assembler. Programming tools vary by manufacturer and chip and might be Windows-specific. (I use NXP's Windows-based flash downloader, in Virtualbox, for the LPC2138. I also am using a Windows-based IDE for one specific client.)

4. relative ease in learning
Quite good. It's a simple and regular instruction set.

5. traps (I can list a huge pile of them for PIC16!)
Few. The gotcha that keeps tripping me up, when writing in assembler, is that you have to explicitly specify the instruction opcode that sets the status bits. (E.g. ADCS sets the carry bit, ADC does not.)

6. quality of documentation
Good, but overwhelming. The ARM7 Architecture Reference Manual (programmer's manual) is over 1000 pages, and newer ARM cores are probably even larger.

7. bugs in the assembler?
None that I know of. The GCC tool chain in particular is quite mature. Mike Kohn's naken_asm for the ARM is still in beta.

8. quality of technical support (I probably shouldn't bother with TI)
I really can't say; I haven't needed manufacturer support yet (other than documentation).

9. price and availability of the actual ICs in small production volumes
Reasonable. Varies widely depending on memory size and peripherals. The LPC2138 I'm using is about $14 in single quantity. Not as cheap as an MSP430 or PIC, but not outrageous. (Bear in mind the '2138 has 512 KB of ROM, and 32 KB of RAM, plus the usual assortment of I/O.)

10. projected long-term availability
For the ARM family, excellent. For any given chip, hard to say. I think the LPC21xx chips that I've been using are getting a bit old, and might be candidates for retirement. One bonus is that the ARM is multiply sourced, so if Philips/NXP lets me down, I can find ARM chips from TI or Freescale or others.

I see that you have an antipathy towards TI, but you might be interested in their Tiva C (ARM Cortex M4) Launchpad, for a mere $13. I'm planning to buy one of these myself.

_________________
1802, 6809, 8051, 8086, MSP430, Z80 -- there's a Forth for that: http://www.camelforth.com


Mon May 26, 2014 10:18 am
Profile WWW

Joined: Fri Jan 10, 2014 11:19 pm
Posts: 25
Garth, you finally prompted me to look at the PIC. And judging from the Wikipedia description of the PIC16, I'm twice as amazed that you can do so much with it. According to the Microchip web site, the biggest PIC16 has 14K ROM and 1K RAM, and it looks like addressing extended RAM is downright ugly. So perhaps you'd be interested in the MSP430, even though it comes from TI.

relative performance for different types of work (in terms of time to get a job done, regardless of MHz)
Pretty good. It's a 16-bit processor with a 16-bit address space, 16 registers, and some very powerful addressing modes. You can do a lot of work in a single instruction, such as clearing a bit in a memory location. Register-register instructions typically execute in 1 cycle; as a rough guide, add one cycle per memory reference (either RAM access or addressing parameters).

interrupt performance
Pretty good. Interrupt latency is 6 clock cycles, and return-from-interrupt is 5 clock cycles. On a 16 MHz part that's less than 1 usec.

whether there's a non-Windows support (assembler, programmer).
Very good. On Linux, there is MSP GCC. There is also mspdebug which allows you to program most MSP430 chips, and debug (halt, single step, examine registers, etc.) from the Linux command line. Mike Kohn's assembler also supports the MSP430.

relative ease in learning
Very good. I was able to summarize the instruction set in two pages. The User's Guide is more detailed -- it takes 16 pages to describe the CPU architecture, addressing modes, and complete instruction set. The instruction set is very regular.

traps (I can list a huge pile of them for PIC16!)
Nothing with regard to the CPU. Most of the peripherals on various parts are well designed. The power management hardware can be a bit challenging on some models.

quality of documentation
Pretty good for the CPU. The device-specific documentation can be a bit challenging -- the data is often not presented in an easy to use format. E.g., I messed up one design because I thought a particular function was available on a particular pin, and on reading a second section of the manual, I found out it wasn't.

bugs in the assembler?
None that I know of.

quality of technical support (I probably shouldn't bother with TI)
Iffy. I had some questions about peripheral operation in low power modes, and finally took to the TI users' forum for answers. I found some answers there; others I had to discover for myself.

price and availability of the actual ICs in small production volumes
Very good. The MSP430G2553 that I've been using is $2.79 Q1 (Digi-Key), and I've had no problem getting samples from TI. You might also like the fact that several family members (including the '2553) are available in DIP packages.

projected long-term availability
I think good for the MSP430 family, but any particular device is an open question. TI is actively pushing this as their low-end microcontroller, positioned against PIC and AVR and Freescale 9S08 (all of which it outperforms). The low end parts are as cheap as $0.80 in quantity. They are releasing new family members on a regular basis.

_________________
1802, 6809, 8051, 8086, MSP430, Z80 -- there's a Forth for that: http://www.camelforth.com


Tue May 27, 2014 9:41 pm
Profile WWW

Joined: Tue Dec 11, 2012 8:03 am
Posts: 272
Location: California
It does sound good in many respects, incuding pricing. For the things I've done since 1994, if I were to tell them that a microcontroller was going to be $10-15 our cost, they'd choke. I can get away with $3 just fine though. :D We don't use DIPs in production units, but they're valuable for prototyping. PLCCs wouldn't be bad except that PLCC wire-wrap sockets are very rare now.

My problem with TI started in the 1980's, when it was hard to get data books (the web didn't exist yet), or samples, and they did not have helpful FAEs. National Semiconductor won my heart back then for analog parts, as they did everything right-- lots of free data books, samples given out freely, and the FAEs visited the shop regularly without our even asking them to. Now unfortunately TI has taken over National, and where they had equivalent parts, they replaced the online National data sheets which had more helpful applications info with TI's own which were deficient in that area. I'm glad I kept my three shelf-feet of National books! OTOH, National had their COP800 line of microcontrollers which was one I considered for a product in 1993, but they told us we weren't big enough for them to be interested in our business and they didn't want us. Anyway, a few years ago, I told the other engineer in our company (located 1200 miles from me) what I thought of TI, and he didn't believe it. Then he tried to design a TI DSP into something, and had trouble to no end with TI. Later he designed a class-D TI audio amp into something, and got this low-level but irritating drunken-mosquito background noise, and they wouldn't give him any of the info he needed to find out how it might be interacting with other parts of the curcuit, because apparently they were afraid that he would steal the design and compete. The problems kept both of the things he was working on from making it to market. Now he hates TI too.

The PIC has more mickeymousities than I can take the time to list and describe right now, although I might do it later partly to publish my macros which help with the programming part (although I can't do anything about the performance part). The one I'm using is available in another version with more RAM and program memory, but it gets extremely inefficient to use the extra because of the overhead of dealing with the paging and banking. They say "single-cycle execution," but what they mean is instruction cycles, not clock cycles, and most instructions take four clock cycles (a few take 8), and you get slightly under 5MIPS @ 20MHz. The poor instruction set however means that it takes it about twice as many instructions and twice as many clock cycles to do a job as it takes the 6502, if the PIC can do it at all—and that's if the job is small enough to avoid having to switch RAM banks or program pages much. To switch tasks 50,000 times a second means you're averaging about 100 instructions per task, including interrupts which take the majority of the time and continue on schedule regardless of what the non-interrupt part of the program is doing; but most tasks have little or nothing to do at any given instant, so after they've checked for whatever event or time they're watching for and find out it has not arrived yet, they exit quickly, so you can make the rounds pretty quickly.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources


Tue May 27, 2014 10:40 pm
Profile WWW

Joined: Fri Jan 10, 2014 11:19 pm
Posts: 25
Ah. Well, had I known that pricing was an issue, I probably wouldn't have suggested the ARM (although I think the ARM is the best value in its more-powerful class).

I have not had your experience with TI, but I know what you mean. I simply will not design with Intel parts because I've been burned by them twice. On the flip side, I still think well of Zilog because of the excellent support they provided the small (and low-volume) firm I was working for years ago. I also fondly remember AMD being generous with data books when other firms weren't -- though these days I have little occasion to design with anything AMD makes.

I haven't dealt with TI FAEs, but I think they TI is trying to improve their reputation -- they're trying to get more design "wins". Thus the profusion of Launchpads and other inexpensive development kits. I have a client who designed a wireless transmitter with the TI CC1150, and their reference design was extremely useful. I think they're focusing on putting enough information on the web so that you don't have to speak to an FAE...essentially "out-sourcing" tech support to their customers. As I mentioned, I had some MSP430 questions, and I never got an answer from TI; I posted the question to the users' support forum (where some TI engineers do appear) and got some helpful info from another TI user. (I get my Linux support the same way.)

So yeah, if you need FAE support, you might be disappointed. On the other hand, they're really good about product availability, and their documentation is pretty good (except as I noted before).

Re. the MSP430 itself, here's an example interrupt routine from one project, a 1-millisecond timer interrupt:

Code:
TA1IFG_IRPT:          ; 6 clks for interrupt response
    BIC   #1,&TA1CTL  ; 4 clks - clear the TAIFG interrupt
    ADD   #1,&MSECS   ; 4 clks - increment MSECS counter
    RETI              ; 5 clks


This enjoys the benefit of one of the MSP430's clever design features -- certain constant values (-1, 0, 1, 2, 4, 8) are encoded as register accesses, so they run at full speed without the added memory access for an immediate value. So that interrupt service takes 19 clocks, or 1.2 usec on the 16 MHz part. "&" is absolute addressing mode. Because so much can be done directly to memory, there's no need to save and restore any registers in that routine.

Thinking about it, you probably wouldn't want to use the MSP430G2553 -- it's a bit light in the RAM department (512 bytes). But there's quite an assortment to choose from. One downside used to be that they didn't make a part with a USB peripheral, but they've just introduced one (I have the development kit but haven't tried it out yet).

_________________
1802, 6809, 8051, 8086, MSP430, Z80 -- there's a Forth for that: http://www.camelforth.com


Wed May 28, 2014 12:40 am
Profile WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1316
Thanks for the all the details Brad!

Garth: don't think for a minute that an ARM chip need cost $15. It all depends on what on-board peripherals and memory you want, and what package you want, and so on. If you're getting lots of on-chip ROM and RAM and also USB, SPI, I2C, UART interfaces, as well as the usual counters and timers, you're getting rather more value than just an MPU. The cheapest ARM SoC from NXP seems to be about $1.50 with the first price break at quantity 10. Other manufacturers should also be considered - the difficulty here is navigating all the choices! Atmel's cheapest seems to be $2.50

One particular ST ARM for $1.29: http://uk.farnell.com/stmicroelectronic ... dp/2393635
Architecture:ARM Cortex-M0; Program Memory Size:16KB; RAM Memory Size:4KB; CPU Speed:48MHz; No. of I/O's:15;
I2C, SPI, USART
Timers, PWM, ADC, RTC, CRC

One particular NXP ARM for $1.50: http://uk.farnell.com/nxp/lpc1111fhn33- ... dp/2072184
Architecture:ARM Cortex-M0; Program Memory Size:8KB; RAM Memory Size:4KB; CPU Speed:50MHz; No. of I/O's:28;
I2C, SPI, UART
ADC, Timer

One particular Atmel ARM for $2.50: http://uk.farnell.com/atmel/atsamd20e14 ... dp/2363629
Architecture:ARM Cortex-M0; Program Memory Size:16KB; RAM Memory Size:2KB; CPU Speed:48MHz; No. of I/O's:26;
I2C, SPI, UART, USART
ADC, Comparator, DAC, PWM, RTC, Temp Sensor, Timer

One particular TI ARM for $3.45: http://uk.farnell.com/texas-instruments ... dp/1854440
Architecture:ARM Cortex-M3; Program Memory Size:32KB; RAM Memory Size:8KB; CPU Speed:50MHz; No. of I/O's:32;
I2C, SPI, SSI, UART
ADC, ACMP, LCD, POR, RTC

Cheers
Ed


Wed May 28, 2014 5:59 am
Profile

Joined: Tue Dec 11, 2012 8:03 am
Posts: 272
Location: California
Thanks, Ed! Those look really good too. I won't have time to do the research justice before I'm totally done with the current project, but I'm glad to have the above material for ideas of things to look into. I feel a lot more comfortable hearing from people with experience with them, rather than just blindly going into it by myself and wondering if I'm missing some major considerations that may not come through in the marketing. At some point I should probably see if I can get into seminars that the manufacturers put on for free in hopes that the attendees would then design the µCs into their products and buy a bazillion of them. That's how I started with PICs, to get some guidance heading into the family. ARM truly is single-cycle execution, such that 48MHz means nearly 48MIPs, right?

_________________
http://WilsonMinesCo.com/ lots of 6502 resources


Wed May 28, 2014 6:30 am
Profile WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1316
Not purely single cycle, but mostly, yes(*). Generally these MPUs have more ROM than RAM, but some of them allow for an external memory to be hooked up (using up a lot of I/Os of course)
You should be able to pick up a dev board for $20 to $50 - I think that's the usual way to get started. I went for a high-performance one with a 168MHz CPU, where the CPU runs faster than the Flash, so you only get full performance if the caching works out well for you. At lower clock speeds you don't have or need a cache.

(*) On the Cortex M0 which is the lowest end ARM CPU, Load/Store seem to be 2-cycle, branch is 1 for not taken and 3 for taken. See section 3.3 of
http://infocenter.arm.com/help/topic/co ... p0_trm.pdf
Bear in mind that load/store is a bit less frequent than for a 6502 because you have many more registers.


Wed May 28, 2014 6:47 am
Profile

Joined: Fri Jan 10, 2014 11:19 pm
Posts: 25
Thanks, Ed! I'm new to the ARM family, and probably should have researched more than the one device I'm currently using. (I did glance at the TM4C123GH6PM, used on that TI Launchpad, and it's $12 in Q1 at Digi-Key. But Launchpads are typically "loss leaders" for TI.)

Garth, as a rough rule of thumb: for comparison with other architectures, double the ROM requirement for the ARM. Each ARM instruction is 32 bits, so an ARM program will often be twice the size of an equivalent program on another CPU. Because of this, they introduced the Thumb instruction set -- a subset of ARM instructions, encoded in 16 bits. (Coming from the PIC, you might want to learn the Thumb instruction set first.)

Anyhow, when you have a program that requires 16K of ROM, figure you'll need 32K of ROM on an ARM chip. This estimate is crude, because a single ARM instruction might do the work of two "other CPU" instructions (or even two Thumb instructions, as I've been discovering with CamelForth).

_________________
1802, 6809, 8051, 8086, MSP430, Z80 -- there's a Forth for that: http://www.camelforth.com


Wed May 28, 2014 2:04 pm
Profile WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1316
There's a diagram and a link to a PDF about code density at
http://forum.6502.org/viewtopic.php?f=1 ... 526#p15526
(Which omits Thumb2, perhaps because it's too old, but ARM claim that Thumb2 is a better tradeoff, being slightly less dense than Thumb but almost as performant as the original ARM instruction set. My https://github.com/BigEd/a6502 project uses Thumb2 - I think it was a forced choice - fortunately it turns out not to be problematic to write in assembly for Thumb2.)
"A stated aim for Thumb-2 was to achieve code density similar to Thumb with performance similar to the ARM instruction set on 32-bit memory."


Wed May 28, 2014 2:17 pm
Profile

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1316
BTW, I am a fan of ARM by default really - because of the relationship to Acorn and the 6502, and I'm not familiar with the other choices being discussed. I do have a supercheap TI MSP430 dev board but I've never yet tried to do anything with it.

So, I may speak up for ARM, but I'm not able to help with a comparison!

Edit: Here's a thumb2 reference card: http://infocenter.arm.com/help/topic/co ... 01_UAL.pdf

Cheers
Ed


Wed May 28, 2014 2:19 pm
Profile

Joined: Fri Jan 10, 2014 11:19 pm
Posts: 25
I wouldn't say I'm a "fan" yet, but I became interested in the ARM because of (a) the New Micros SBC, and (b) a client who is switching from Renesas H8S to ARM, because the ARM offers a lot more power at a lot lower cost. So far I really like the "classic" ARM instruction set, even if it is a bit fat (in code density) -- it is clean and elegant. I'm not as enthusiastic about the endless parade of "Cortex" improvements, which I think are mostly for the handheld-device market, but I can safely ignore them.

(Incidentally, I do not recommend the H8S, even though it has some nifty features -- the hardware is not as easy to design around, and Renesas is phasing it out anyway. Renesas also has a nasty habit of hiking their prices after the design "win".)

While I really like the MSP430, it doesn't meet all my needs (yet) in the 16-bit realm. (For one thing, there is no such thing as an MSP430 with an external address/data bus.) For projects requiring a 32-bit ALU or a 32-bit address space, I think the ARM is the clear winner.

_________________
1802, 6809, 8051, 8086, MSP430, Z80 -- there's a Forth for that: http://www.camelforth.com


Wed May 28, 2014 3:16 pm
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 29 posts ]  Go to page 1, 2  Next

Who is online

Users browsing this forum: No registered users and 4 guests


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 post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software