Smart Reflow Oven is Over-Engineered

reflow

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

28 thoughts on “Smart Reflow Oven is Over-Engineered

    1. It is simple RGB565, but you need SPI to init AMOLED controller. also it need’s special power sequencing at power-up. Software is similar to STM32F429i-disco, only frame buffer is not sdram, but sram, and timings are different

    2. Yeah, it *really* bugs me when I see cool stuff like this and there’s only a youtube video without any documentation or discussion of the technical details.

      1. well, i had blog post in element14 regarding details about this project (code, schematics, and etc) . It was originally designed to be as entrance to contest, (Cypress smart life challenge) but because i don’t get even third place in that contest (even bicycle blinking light beat me ) i was a bit mad and delete everything. If some one is interested in details about this project, can do that with email megahercas6@ or skype kilohercas

        1. Please make this available to the public again! This is the kind of project that I’ve been looking to do recently. You’ve done a lot of hard work and it really shows!

          1. I was interested in using this display since the first post showed up on HaD, but had no time to look into the details. Now I’ve done a quick search, and found that the datasheets are still available attached to a post on the stm32 forum. So I thought to post the link here for those who are interested.

            https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/DispForm.aspx?ID=35026&RootFolder=%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fSTM32F429%20and%20AMOLED%20screen

            However I couldn’t find the display pinout, nor the original example source code, can somemone find it?

          2. Agree – I’m looking for an LCD to use as a calculator screen, and this looks wonderful. I’m going for a “clamshell” design [like a mini laptop] so the dimensions of the screen define keypad size, battery and CPU board.
            Having something known to work with a particular CPU helps define the circuit even more. STM32, eh? [Bye-bye, EFM-32 Gecko]

    1. Problem with camera is that contrast is 1:10,000, so i can’t show black text in white background. But in reality screen is perfect, just like in any modern phone.

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

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

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

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

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

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

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

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

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

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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