1
\$\begingroup\$

Okay so here is my exact problem.... I want to design an embedded system with a micro controller at it's heart that I can use to control various peripherals all powered by a batter that can be plugged in and charged. To me, that is the "simple" part. Now the problem is, I want to be able to connect a nice LCD screen, say 3-4 inches viewing size, and create a NICE GUI. I've already been able to hook up a simple 16x2 LCD and control it nicely with a micro controller, but I don't want my projects to feel like they are out of the early 90's! I am used to nice graphical user interfaces.

I've come to the conclusion that the best way of doing this would be to use a Linux embedded system. The issue is, how do you go about designing something like that? Are there any helpful guides? Looking at other answers people suggest using processors like this one. I've also seen this chip that helps simplify GUI design, but the software costs 500$!! I don't want to spend a fortune but I DO want to be able to design stuff like this into a CUSTOM embedded system. I do not want to just go out a Raspberry Pi for this (I already have one anyway)...

So what solutions exist for a problem like this and are these any good resources with tips??

\$\endgroup\$
1
  • \$\begingroup\$ This is far too broad. Questions discussing the concept of a whole project are not welcome. Try to ask about specific problems. \$\endgroup\$
    – Rev
    Apr 14, 2015 at 18:21

2 Answers 2

Reset to default
5
\$\begingroup\$

Firstly, to drive a TFT screen doesn't take much in the way of processing power.

However, it does take a lot of memory and processing power to drive a TFT screen well.

You can interface pretty much any microcontroller to a TFT screen as long as the TFT screen has its own display controller chip in it. Most cheap "development board" style TFT screens (screens already mounted on a small PCB) have that kind of arrangement. They make interfacing easy, and there is usually one of two interface types - SPI or Parallel. SPI is slow, but only uses a handful of pins. Great for interfacing with small MCUs. Parallel needs around 20 pins to interface with it, but allows much faster access to the screen, and often much more flexible access.

The main thing though is memory - both flash and RAM. Most small TFT screens have their own framebuffer memory built in, so you don't need to worry about that, but if you want to manipulate images in memory before pushing them out (which makes for the smoothest screen refreshes) then you need enough RAM to cope with that. And any images you want to display have to come from somewhere. That could be an SD card (which is usually quite slow) or internal Flash memory (much faster), so the more of that you have the better.

You really don't need a full embedded Linux system just for controlling a TFT screen. Most of the time that just gets in the way.

I do a lot of work with TFT screens on PIC32 chips. The high end of the MX series (such as the PIC32MX795F512L) has both the IO capabilities for fast parallel interfacing (a hardware "Parallel Master Port") and just about enough RAM to allow you some graphical manipulation. The new MZ series though, as it's much faster and has considerably more RAM, is a much better candidate. Of course, they are comparable to the gazillion ARM chips that are out there these days, so you can do similar things with those.

Designing and implementing a full embedded Linux TFT display environment is no small job. Believe me, I have been working on one for the past 6 months now. About 10% is the circuit design. The other 90% is getting Linux built and configured in the right way for your system. And that's not counting trying to squeeze information out of Broadcom. They won't talk to me - they will only talk to my contractees, and relaying information back and forth is a PITA.

So if you really want to create a system with a SoC and Linux, copy the BBB not the Pi. TI are far more open and willing to help.

\$\endgroup\$
4
  • \$\begingroup\$ If the screen can be divided into non-overlapping rectangles, each of which will contain one "object", most TFT LCD displays can be updated just fine without double-buffering. \$\endgroup\$
    – supercat
    Apr 14, 2015 at 20:12
  • \$\begingroup\$ @supercat But you want the memory to create those "objects" in the first place. \$\endgroup\$
    – Majenko
    Apr 14, 2015 at 20:47
  • \$\begingroup\$ Generating text-based screens by unpacking bitmap fonts directly to the SPI port is often faster than unpacking the bitmaps to memory and then copying the memory to the SPI port. Depending upon screen complexity, figuring out which areas need to be drawn or erased may be a tiny bit tricky, but for simple displays it's not hard. \$\endgroup\$
    – supercat
    Apr 14, 2015 at 21:10
  • \$\begingroup\$ @supercat Who wants text based screens when you have a TFT?! :) By the way, some of my work (website in progress): DisplayCore.org \$\endgroup\$
    – Majenko
    Apr 14, 2015 at 22:12
2
\$\begingroup\$

I have a feeling you're looking for some fine wine on a beer budget. For an embedded TFT project like this, your best bet is to start with some kind of SBC like Beaglebone (with an LCD or touch screen cape) or similar. These have all the parts built in taking advantage of economy of scale. To do this yourself will cost big bucks.

If you're trying to understand how things work, study the schematics. Many SBCs are open source.

\$\endgroup\$

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