Smart Reflow Oven is Over-Engineered


[Linas] reverse engineered an AMOLED HTC 800×480 screen and interfaced it with an STM32 micro-controller, along with some other components, to make a gorgeously over engineered reflow oven.

Under the hood there is a PSoC5LP PID controller to control the 800W IR heating coil and two K-type thermocouples for sensing.

The real beauty is in the relatively small STM32 chip powering the HTC AMOLED screen. The AMOLED screen is high contrast and has a wide viewing angle, giving it a clear crisp view from all front facing viewpoints. Though pushing the limits of what the STM32F429i can do, [Linas] managed to make a very nice “home-grown” user interface, complete with user configurable settings and current temperature graphs.

The user interface looks very responsive and using some clever programming, [Linas] was able to make use of the potential of the screen to provide beautiful plots and interface widgets.

[Linas] goes into quite a bit of detail about the programming involved with rendering to the screen, so be sure to check out the video after the jump.


  1. Don says:

    Would love to see more info on the screen and its interface to the STM32, software.

  2. lloyd says:

    Impressive, something wrong with the camera though both the picture and the video makes the screen look very out of focus.

  3. Matt says:

    +1 impressive job.
    It’s nice to see something with such a high degree of finish on hackaday,
    I would be interested in seeing more technical details about communication with the screen as well as fabrication of what appears to be a very nice mount for the screen as well.

    • pelrun says:

      [Linas] went to some trouble to delete the technical details from the web (boo hiss). Too bad there isn’t an organisation dedicated to recording the history of websites…

      • megahercas says:

        lets be realistic, how many people would use that ? in my country i guess none. Only beaglebone users could use that, and not that many people would be able to connect this amoled screen to sitara processor. also i have code for capacitive touchscreen via I2C, it could be mated to make nice cape, but i am no good at linux programming

        • rue_mohr says:

          I beleive thats a reference to the waybackmachine (

        • pelrun says:

          I’m personally extremely interested in playing with the screen+stm32 configuration, and it’s also possible to use a chip like the TFP401 to give the screen HDMI input. I was just a little frustrated that both this time and the last time your project was featured on HaD that there was just no information. Enough so that I dug out HTC’s android driver code and was going to reimplement your work from scratch :)

          • megahercas says:

            Well, this screen is near the limit of STM32F429 LTDC controller, Beaglebone has LIDD controller so if you want good performance. If you try to display some motion or something, it will show up that screen refresh rate is low.

          • pelrun says:

            Really? I’m surprised. The panel is 800×480 with a 24ishMHz dotclock, and the F4’s LTDC can handle up to 800×600 with a max dotclock of 42Mhz. It should be trivially easy to meet the panel requirements with that spec. I did see a thread on where some idiot told you it couldn’t – ignore what he said, because he’s either a moron or a troll. Either way, he’s an asshole, and he’s incorrect.

          • megahercas says:

            yes, you can do 60FPS, problem is when you try to change data to SRAM. Since at the same time you must access SRAM to change data, and at the same (OTHER) time LTDC controller wants next chunk of data to paint of screen. and since LTDC Controller has higher priority, you will note slowdown. my painting cycle is less than 100ms , but i limit it with RTC interrupt at 125ms. if you try to move bmp, you will note tearing. So it is like computer running game, panel VSYNC is 60Hz, but you graphics card can only do 5fps

          • Alan says:

            Sounds like a job for… dual port RAM

          • megahercas says:

            yes, that could make huge difference in theory, but remember, you have only single 16b bus, and memory is multiplexed with different CS pins. But it is possible to use GPIO for second Data and address bus. But again, i can’t find any dual port memory that could do 384k x16b, i can find only 64k x16b, so no luck here.
            Also when i was running panel in 60FPS VSYNC mode, i noted i have very slow refresh rate, by lowering VSYNC ( and pclk as well ) i get better visual performance and faster overall loop execution rate (because i get more time to work with sram :) )

          • pelrun says:

            It’s a bit too much to expect good performance doing significant cpu-based blitting on any small platform, this is no exception :) There’s the graphics accelerator (DMA2D?) available on the F4 to do a lot of the heavy lifting there; if that’s unsuitable then there’s also the CLUT mode that limits you to 256 colours, but cuts the memory usage in half allowing you to do double or triple buffering. Dual port ram isn’t really required.

  4. Doub says:

    Do you have an ebay link to the display panel that is used?

  5. Mike says:

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

Join 96,369 other followers