Thinner client using STM32 and NTSC monitor

[David Cranor], along with [Max Lobovsky’s] help, managed to build a thin client that uses an NTSC television as a monitor for only $6. This is his first foray into the world of ARM architecture and he has vowed to never use an AVR again. The powerful little chip uses timers to manage sync and DMA to transfer the full 480×240 frame buffer to the screen. Overclocked at 80 MHz there’s a lot of potential in this little board and he plans to take on the challenge of a full-color display for his next trick.

30 thoughts on “Thinner client using STM32 and NTSC monitor”

Yeah, I’ve been buzzing a bit about this in the comments myself lately, but I feel like it doesn’t hurt to say it a bit more.

I’ve been looking at ARM too lately (Atmel SAM7 and SAM3… if the SAM3 ever comes out!) and really, I just see no reason to use an AVR ever again.

I’m building my first ARM board now, and as you can see from the article’s picture, they make some pretty easy to manage packages. The sam7 comes in as little as a 48 pin package, and requires just about the same number of external components as an ATMEGA. For that you get a 32 bit databus, peripherals that can be assigned to a few different pins, interrupts on every pin, a 55MHz clockspeed, and built-in USB, all for the same cost as an AVR.

Go to the Eagle website, grab some Atmel ARM footprints from their footprints section, look up an Olimex schematic to copy, and go whip up a board!

The code is pretty similar to an AVR, and there are some good examples online. With true USB you can have it show up as a COM port to start (there are examples for that online) and then move to USB bulk transfer or whatever else when you’re comfortable.

The more I look at them, there just isn’t any sense in using an AVR anymore, unless you need something smaller than this.

As soon as I finish my eagle schematic, I’ll put the files up here for people to grab, since I wasn’t able to find any open source hardware designs with those chips, yet. Though I just realized I think some MAKE controller might use an ARM.
-Taylor

This is a great project, showcasing the ARM chip’s strengths. As an ARM7 user (NXP LPC2000-series), I agree with the author that it’s superior to the AVR MCU’s.

Of course, the DIP package of the AVR chips does still leave it with a place as a quick-cheap-and-dirty processor for projects where that’s what you need. It’s just nice to see someone not using the Arduino for everything.

There’s a full gnu toolchain for the ARM chips, for linux, and for windows. I don’t use mac, but I wouldn’t count it out. You can code in vi or notepad, if you’re hard-core, or you can set up the Eclipse IDE to work with C code, as well.

@UltraMagnus: I’m pretty sure ARM development is very well supported under Linux. I tinkered with an ARM MCU some time ago, and used the GNU ARM Toolchain for Windows; but it’s available for Linux too.

and you’ll have an extremely powerful prototyping platform for only $25. And remember, it already has a serial (RS232) bootloader in an internal ROM, so it doesn’t need any special hardware for programming. Also, ST provides a very complete support libray for their STM32 chips. That’s a very hard to break deal. Yes, AVRs can wait :)

@UltraMagnus: Several flavors of ARM are supported natively by gcc. Just Google @UltraMagnus: instructions for building a cross compiler. GCC and Linux itself (even full distros like Ubuntu) will happily run on an ARM, albeit you need one with external RAM and some sort of storage medium.

Beagle, WRT, Pandora, Dingoo, Chumby are all examples of ARM computers well supported by cross compilers.

If you still have a parallel port, then Wiggler in conjunction with GDB gets you a totally free hardware debugger too.

arm-eabi toolchain is a part of devkitpro.org, if I’m not mistaken. I use same compiler for GBA and for LPC2100. I didn’t swear to never look back at AVR, but Atmel did its best to kill itself. After my little stash of ATmegas runs out, there’s nothing to look back at anymore!

IMHO for someone familiar with AVR, the best way to get into ARM programming is the LeafLabs Maple (http://leaflabs.com). It has an 80MHz STM32 CPU. I just started playing with them a month ago, and I don’t think I’ll ever go back to AVR (except for very specific circumstances).

The Maple is in the Arduino form-factor and all their development tools make it easy to convert your Arduino code and libraries to it. The thing is a powerhouse in a really awesome package.

Vowing to never use “such and such” part ever again… is a sign of bad Engineering. All options should be on the table at all times. This isn’t to say using a point-contact transistor in-place of a 2N2222 is a good idea. But keeping an open mind is very important.

@Ken, you can do direct interfacing with 5V hardware using the STM32, most of its I/O lines are 5V tolerant. In some very rare situations you’ll need a buffer to go from 3.3V to 5V.
And yes, I completely agree that there is a very good place in this world for AVRs, but I think that right now this only applies to DIP AVRs (and tinys). If you go to some sort of QFP variant, there are less and less reasons to choose an AVR (or other similar 8 bit MCU) over an ARM (especially a Cortex-M3, which managed to make things easier for the programmer when compared to the old ARM7/ARM9 series).

As much as I hate ARM for going after open source clones of their cores (which this project doesn’t really use anyway, most of the tricks are done with the STM32 peripherals), this is a very cool little project.

As the token “that guy” on hackaday, I have to say that he built was just a serial terminal.

Calling this a thin[ner] client is a stretch – running links or lynx or any other terminal based web browser does not a thin client make. Make it into an xterm, and you’ll have something. Process VNC or RDP data streams… but ascii text is ascii text, and this makes it a simple terminal.

Having said that, this work is nothing short of absolutely wonderful and I applaud it. Very, very good!

reading full x framebuffers was actually the first functionality that we had working, but it was kind of a hack and got optimized out of the code as we built the text display on top of the device’s framebuffer.

What’s up with all these “vows” to never use AVR again? Ken started to hit the point and Drone is also on the right track, but I think this is a point that really hits home: “oh avr’s still have their places, if your looking for power they are not it” Exactly! Concern over power consumption is one of the primary reasons to use and AVR over an ARM. Battery or solar powered designs will usually be much better served with the ultra low power capabilities of the AVRs or PICs for that matter. Hey, if you’re always plugging it into the wall then who care, but if you really don’t need all those clock cycles sucking the juice, why do it? I think I’ll keep all those 24, 16 and 8 bit micros in my back pocket for the applications that they would best serve.

Anyway! Does anyone know a good Diopsis dev boards? For me the only thing that matters is floating-point performance at this point, and the market is very divided. I don’t like highly-integrated dev boards with lots of crazy peripherals, like wired ethernet.

ARM is great, but is older than AVRs in reality. STM32 is a rather mature CPU architecture with a few big-boy peripherals on it. I worked with David on this and his previous microcontroller terminal project. The reason this hack could happen is because of the DMA controller in the STM32. Getting all the timing right using the AVR in the previous version was super-obnoxious.

So the DMA controller in the STM32 is nice but also very convoluted. I’ve used other DMA controllers in the Amiga, PC, PowerPPC, etc., but this one has an accumulation of cruft. It’s very far from modular… You really have to follow quite a few bus diagrams to figure out if you can move data from one location to another.

If Atmel can integrate DMA and other technology into its line as well as its flash memory and other peripherals, they’ll have a solid product. Me, I want floating-point in a micro-controller… and I think the next-best thing is the FPU core at opencores…