4
\$\begingroup\$

I am about to develop a portable device to be interfaced with a computer (so, consumer electronics). I only have experiences with Microchip and Texas Instruments and I would like to have some hint to choose the right MCU.

Key requirements should be:

  • low power (it's a portable device);
  • 16 bit;
  • RAM>10 kB;
  • Hardware multiplier;
  • large program memory (128 kB), and;
  • available in development kit form or something.

Is there any with the possibility of interfacing a on-chip Flash memory (such as the ones in USB keys)? Otherwise, I'll just use an SD card.

Very important, is there any chance I could find one with 3 Mbps (3250000 bps) UART? I need to interface with a Bluetooth module for high speed communication.

What kind of MCU do you think would be a nice compromise?

\$\endgroup\$
6
  • \$\begingroup\$ Why do you spec 16-bit? This is going to be a rather high spec 16-bit processor to handle an I/O byte every 3 microseconds. \$\endgroup\$
    – markrages
    Jan 25, 2011 at 21:20
  • \$\begingroup\$ The MCU has to do some math on inertial data (gyros and accel), so a 16 bit solution is required \$\endgroup\$
    – stef
    Jan 25, 2011 at 22:54
  • \$\begingroup\$ Why not 32-bit? \$\endgroup\$
    – markrages
    Jan 26, 2011 at 2:29
  • \$\begingroup\$ 3 M = 3 250 000? \$\endgroup\$
    – Nick T
    Jan 26, 2011 at 2:30
  • \$\begingroup\$ @markrages 32 would be perfect as well \$\endgroup\$
    – stef
    Jan 26, 2011 at 13:00

7 Answers 7

Reset to default
3
\$\begingroup\$

Take a look at the Atmel SAM3S. It is not a 16 bit device but I'm not sure why that is a key requirement. I'm also not sure what "low" power means to you. This will be in direct conflict with the requirement for the fast baud rate. To hit the 3.25 MBps you have to run this part at 52 MHz (It runs at 64 MHz max). Another nice feature it has is DMA to help move the high speed serial data. It also meets your memory requirements.

\$\endgroup\$
1
  • \$\begingroup\$ As I said to Mike, any Cortex-M3 will have similar functionality to the SAM3S. There's no need to hawk specific vendors unless yours provides a compelling additional feature (like a faster UART). \$\endgroup\$
    – Kevin Vermeer
    Jan 26, 2011 at 20:36
2
\$\begingroup\$

NXP ARM7 and Cortex parts should be able to do it - you may need to run at 48MHz to get exactly 3Mbaud

\$\endgroup\$
1
  • 1
    \$\begingroup\$ Why must it be an NXP branded chip? Other vendors sell equally capable ARM7 and Cortex parts. \$\endgroup\$
    – Kevin Vermeer
    Jan 26, 2011 at 20:26
2
\$\begingroup\$

I think that the ARM7 or Cortex-M3 parts already recommended should fulfill your need if clocked sufficiently quickly, but wanted to add another alternative.

The Atmel AVR32 has an external bus interface that would allow you plug into a very large external SDRAM/SRAM or Flash chip. The Mizar32 is an open-source board which has an example of this kind of interface; they use it to connect to a 32MB SDRAM chip.

Your key requirements were:

  • Low power: This is relative; everyone claims their parts are low power. The AVR32 draws about .5mA/MHz, and can be clocked at up to 150MHz. At 60MHz (a common top speed for other parts), that's 30mA.
  • 16 bit: It's 32-bit, which means it exceeds this spec.
  • RAM > 10kB (ftfy), Flash > 128kB: Yes, most of the options have 128-512kB Flash and more than half have >64kB of RAM. It also has the aforementioned memory bus that allows you to increase this to many MB or even 1GB, but that's not single-cycle anymore.
  • HW multiplier: Check.
  • Available in development kit form or something: Check? It's in production, if that's what you mean, and there are dev kits for it. However, Atmel hasn't always been the best at keeping parts in stock, so an ARM part would give you more flexibility in switching vendors if such a need would appear. PICs and MSP430s will also have the same problem of a single vendor.
  • SD card/Flash memory: Yes, again, it has this. There's also an SD card DMA peripheral.
  • 3Mbps (3250000bps) UART? (need to interface with a Bluetooth module for high speed communication). Eh, I guess so? Assuming you have Bluetooth hardware that can handle this task, you may be better off using an external UART transceiver that implements its own FIFO (Bluetooth is a packet based transmission channel), and has a parallel interface so you're not so transmitting. Exar is a company that has some options; you'll want to look for an Intel 16C550 interface (since you don't have PCI). Better yet, get a Bluetooth module with a parallel or synchronous interface.

So, add the AVR32 to the lineup of mid-power parts we've presented you with. (That would be ARM7, ARM Cortex-M3, dsPIC, and PIC32)

\$\endgroup\$
3
  • \$\begingroup\$ There are built-in USARTs in a lot of the devices (UC3B is the only one I'm halfway familiar with). You'll have to clock it at 26MHz (top baudrate clock/8 for asynchronous mode). Should be no problem with the built in PLLs. \$\endgroup\$
    – Yann Vernier
    Jan 26, 2011 at 21:36
  • \$\begingroup\$ @Yann - The OP specified UART (Asynchronous), which requires multiple clocks per bit. They may have meant USART. Yes, this is also available in hardware. However, it means you have to have multiple samples per clock cycle, because the incoming data isn't synchronized with your clock. That's why I suggested an external transceiver. \$\endgroup\$
    – Kevin Vermeer
    Jan 26, 2011 at 22:10
  • \$\begingroup\$ 8 cycles per bit is multiple clocks. The USART has both Synchronous and Asynchronous modes, and does multisampling in asynchronous mode. \$\endgroup\$
    – Yann Vernier
    Jan 26, 2011 at 23:30
1
\$\begingroup\$

The XMOS XS1-L1 can easily handle 3.25 Mbit/s serial in software:

http://www.xmos.com/

\$\endgroup\$
3
  • \$\begingroup\$ It doesn't need to do it entirely in software, because of the bit shifters in the IO ports. That's going to matter since power is a factor. I like the XS1, but there's no particular reason to choose it for this case, and lack of on-chip flash is a point against. \$\endgroup\$
    – Yann Vernier
    Jan 25, 2011 at 23:18
  • \$\begingroup\$ How is XMOS at low-power applications? \$\endgroup\$
    – markrages
    Jan 26, 2011 at 2:31
  • \$\begingroup\$ Not all that good. They are very high-performance devices. \$\endgroup\$
    – Leon Heller
    Jan 26, 2011 at 3:07
1
\$\begingroup\$

I'm using a PIC24F and it's possible to reach 1/4th the Fcy with UART. So with a 16 MHz Fcy you can easily hit 4 Mbit/s. With the dsPIC33F series 10 Mbit/s is doable at 40 MHz Fcy. PIC32 can do almost 20 Mbit/s at 80 MHz Fcy. At higher rates than 10 Mbit/s you will really be pushing UART as it was never intended for high speed transmission and has very poor noise immunity and is single ended (not differential, like USB or CAN.)

PIC24F and dsPIC33F are 16-bit, while the PIC32 is 32-bit.

dsPIC33F comes in versions up to 30 KB RAM. 16 KB RAM is available in SO28 and SPDIP28. Program memory is available up to 256 KB, up to 128 KB on smaller 28 pin versions. PIC32 has up to 128 KB RAM and 512 KB flash, which is wayyy overkill for your application, but Microchip make smaller ones too. All have hardware multipliers. For a dev kit consider the Explorer 16 board.

\$\endgroup\$
12
  • \$\begingroup\$ So you are proposing one bit clock == one instruction. That means you have ten instructions to deal with each incoming byte when they are arriving back-to-back. This is not impossible, but requires very tight coding and a deeper FIFO than the one-byte one common on small micros or a DMA engine like the high-end MSP430s have. \$\endgroup\$
    – markrages
    Jan 25, 2011 at 22:24
  • \$\begingroup\$ @markrages. Investigate the dsPIC33F and PIC32, which have 8 channel DMA controllers and can do 1KB block transfers. I am currently using 1.8432 Mbaud between a PIC24F and a dsPIC33F and it has almost zero latency between each byte. You have 8x the baud clock to load each byte which is plenty. PIC24F/dsPIC33F have 4-deep FIFOs. \$\endgroup\$
    – Thomas O
    Jan 25, 2011 at 22:27
  • \$\begingroup\$ Sending is not such a problem, you can send the bytes when you get around to it. You feel the pinch on incoming bytes. Assuming start, 8 bits, stop, the baudrate is 10x the byte rate. So your system needs to handle receiving 184320 bytes/sec. And you have (14.7456/4)/18430 cycles (about 20) per byte to handle it. \$\endgroup\$
    – markrages
    Jan 25, 2011 at 22:34
  • \$\begingroup\$ @markrages, That's what DMA is for on the 33F's. And with the 4-deep receive FIFO, it gives you almost 80 cycles per byte. Interrupt latency is maybe 5 cycles and you can interrupt on each FIFO 3/4 full event (giving you time to empty it before it overflows.) \$\endgroup\$
    – Thomas O
    Jan 25, 2011 at 23:01
  • \$\begingroup\$ @Thomas, you are missing my point. If I send you a stream of bytes at 184320 bytes/sec, and you are executing 14.75M/4 instructions per second, you only have 20 instructions per byte to do something with the data. Buffering helps lose some interrupt overhead, but with zero overhead you are still stuck at 20 instructions per byte. You can fix this with a faster processor clock or slowing down the data with flow control. But if you are slowing down the data, what is the point of choosing such a baudrate in the first place? \$\endgroup\$
    – markrages
    Jan 26, 2011 at 2:25
0
\$\begingroup\$

Without researching it too much, my internal buzz-word hash-map says TI MSP430 because

  • 16-bit
  • low-power
  • hardware multiplier
  • you evidently have experience with TI

Honestly, when I read your post, I thought the requirements were pulled of an MSP430 marketing brochure. I'm not sure their UARTs support 3Mbit/s - but they have an internal digitally controlled oscillator (DCO) that lets them run at up to 25MHz, so you might be able to keep up... the UART on the 5xx can source an external clock source as well

They have a pretty good product selector tool you should check out.

\$\endgroup\$
5
  • \$\begingroup\$ From the datasheets I sampled, the USCI supports up to 1Mbaud. \$\endgroup\$
    – Yann Vernier
    Jan 25, 2011 at 23:38
  • \$\begingroup\$ They don't run at anything like 40 Mhz. \$\endgroup\$
    – Leon Heller
    Jan 26, 2011 at 3:13
  • \$\begingroup\$ @Leon, my mistake - it looks like 25MHz is about the high end, thanks for the correction I updated my answer accordingly \$\endgroup\$
    – vicatcu
    Jan 26, 2011 at 4:06
  • \$\begingroup\$ TI was my original choice as well, no way I could increase the freq with an embedded PLL? \$\endgroup\$
    – stef
    Jan 26, 2011 at 13:02
  • \$\begingroup\$ @stef it seems like the 5xx series of MSP430's is capable of sourcing the baud rate clock from an external clock source. See ti.com/lit/pdf/slau208, section 26.3.9: "The baud-rate is generate using the BRCLK that can be sourced by the external clock UCAxCLK, or the internal clocks ACLK or SMCLK depending on the UCSSELx settings." I haven't ever tried this or researched the limitations on the external clock, but at face value it seems viable. \$\endgroup\$
    – vicatcu
    Jan 26, 2011 at 20:12
-1
\$\begingroup\$

As always these discussions get into lots and lots of different parts. What I like to do is to go to mouser or digikey and search for microcontrollers. Then you'll be presented with a laundry list of options, Memory, speed, price, etc. From there you can narrow down to what you need.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.