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

  1. 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

  2. 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.

  3. @UltraMagnus

    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.

  4. Great little project!

    @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.

  5. The STM32 is a GREAT chip, with a lot of potential. Combine it with something like this :

    http://www.futurlec.com/ET-STM32_Stamp.shtml

    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 :)

  6. @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.

  7. 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!

  8. AVR’s are fine if you want a quick-and-dirty solution to a “light lifting” problem. They’re not appropriate for everything, any more than anything else is appropriate for everything.

  9. Great project!!

    I have a STM32 Olimex board sitting around and this project will help me a lot to re-start my own project. Started it about a year ago, but abandoned it due to lack of time…

    One thing that I found difficult with the STM32 was setting up the development environment. I started using Codesourcery Lite, but I’m not comfortable using a propietary compiler…

    Recently thanks to the Open-BLDC project (http://open-bldc.org/wiki/Open-BLDC) I learned how to compile GCC to make it work with Cortex-M3

    Other thing that I found very difficult was to make a USB serial terminal…

    And the SkeletonProject will be also very helpful!

    Thanks!!

  10. 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.

  11. Big fan of AVR here.

    Two reasons not to throw away your AVR stuff:

    Directly interfacing with 5V hardware.

    Cost sensitive applications (cheaper cost per MCU, and DIP packages allow single sided PCBs).

    But terms of performance/cost ratio, nothing touches the ARM. I’ve been eying the NXP stuff and I think I am going to try out some of their offerings.

  12. 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.

  13. @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).

  14. 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!

    Hackaday seems to be on a roll here.

  15. @bob: look at xvsmfbg in the github repo!

    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.

    it’s not much of a jump to bring it back and do it right……

  16. 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.

  17. Hey guys, anyone who says “never X again” is trolling.

    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…

  18. @David

    I’m guessing the project owner will read this again… but seriously, an 800×600 frame buffer, bluetooth/USB keyboard/mouse and ethernet board would be cool as cool can be.

    But it’s a bit more work than an x-window picture frame. Still, good job on this one!

  19. Anyone else have the schematic not render properly? I’m using eagle 5.10, but it nothing is aligned for me.

    Also, looking at the code, where is the timing for the front/back porch actually done? I see the frame buffer being updated, but where is the actual ntsc output?

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.