My Embedded eBrewery

[Sting]

I have played around with uGFX for about a month now and think I have a basis for how I want to build my brewery.  The brewery, it is a home project and there will only be one of them, will be based on the STM32F746 Discovery board.  It will consist of 3 network devices, the brew station, the ferment station, and the bar station.  Each component isn't that sophisticated, and the GUI will be the prominent technical component and I have chosen uGFX library for that.  

I have a few questions:

1)  I have not selected the RTOS for the project.  I have a work project that will use FreeRTOS, and thought I could kill 2 birds with one stone if I used FreeRTOS.  The issue is it is larger then other RTOS, like ChibiOS, but has a tcp stack built in.  Has anyone used ChibiOS with a tcp stack with reasonable performance.  The brewery applications will not be high performance applications, one second will be a very long time for this application.  Any advice here would be appreciated.

2) What IDE do people use with the STM32F7 discovery board?  I would prefer an open source IDE.  I am currently using plain eclipse cross compiling to arm and using the remote project explorer to transfer the files to the arm board.  Eclipse doesn't support the ST Link so I can move to another platform.  Also if I do it correctly I can develop in uGFX without the hacks I have to use to work in raw eclipse. 

3) Are there any text based database implementations that would allow an application to store information on the micro sd card? I don't need it to be fast.  

[Joel Bodenmann]

1) We recommend using ChibiOS. It's a great RTOS with an awesome community. µGFX actually started off as a ChibiOS add-on called ChibiOS/GFX. Although µGFX has become a standalone project we are trying to stay close to ChibiOS. Almost all of our regular in-house tests that use an underlying RTOS are made using ChibiOS/RT. Therefore, our recommendation is to use ChibiOS if you can and want to. However, µGFX will work on any kind of operating system.
We have also used ChibiOS/RT with LwIP for some projects that involved TCP/IP and it worked great. There are also some official demos that use LwIP that come with ChibiOS/RT.
Disclaimer: We have no idea what the current support status of ChibiOS/RT for the STM32F7 is.

2) Our users & customers use a broad range of different IDEs. Some people just use a text editor & make, others use Eclipse, Keil µVision, IAR, CrossWorks, ... the list is very extensive. Besides the financial aspect, the choice of IDE is usually quite subjective. @inmarket usually works with eclipse (using external makefiles) while I just use a text editor. However, depending on customer projects I also work often with Keil µVision and other IDEs. The choice really is up to you.
You should definitely be able to use uGFX in Eclipse without any hacks. The recommended way is to setup an Eclipse project that uses external Makefiles.

3) Personally I don't know anything like that. I guess google will help although you will most likely end up implementing your own application specific solution. You can use the GFILE module of the µGFX library to interface files. It comes with built-in FatFS support.

Can't wait to hear and see more of your project. Please keep us up to date

[inmarket]

St link is supported well with openocd. You will in fact find an openocd.ini in each board directory in the repository for the boards i commonly use. I use openocd under eclipse for just about all my dev work. It works well with the stm32f7 boards (although you need an up to date version of openocd for the f7 support).

[Sting]

I kind of had to take a step sideways, I am still looking for a display to use with STM32 board, but is is not as urgent as it was.

I happen to have a Jetson TK1 board laying around that I did some parallel processing projects on and it happens to support SDL2 so I decided to use it.  It makes the brewery a different kind of project, it will still use uGFX.  I have uGFX running on SDL2 and the project is cross compiled from a linux machine, so thats all good.  It is much faster then the linux frame buffer project.  The part I am not so happy about is it has to run in X.  

The processor is better, it is a quad core Cortex A15 running at 2.X MHz.  The added benefit is it has 192 GPU cores, and has a sata port to enable me to run a real database on a solid state drive.  Not exactly an embedded project, but close..

[Joel Bodenmann]

May I ask why you change your platform/system all the time?

You should be able to use almost any display panel that offers the compatible RGB interface (and works with the electrical specification). Worst case is that you have to create some sort of adapter board.
There are literally hundreds to choose from. These are the ones from the same manufacturer as the stock display of the STM32F746G-Discovery board: http://www.rocktech.com.hk/pro.aspx?TypeID=2

[Sting]

I am changing until I can find something I can work with.   I don't think I have changed too many times.  I started on the beaglebone black which would never really work.  It does not support SDL2 and hence is very slow.  It can't run raw, without linux, and access to all of the gpio and other features of the board would be unavailable.  I then tries the STM32F7 and I still want to use this board.  I spent two weeks looking for a display that would meet the design for the project and found few available larger displays.  This is still something I would consider if I found a reasonable display.  I am not a hardware designer, I have never build a pcb and am not comfortable that I would be successful.  I had the Jetson TK1 laying around and I can make it work.  

 I looked at those boards you referenced and none will meet my needs.  The minimum I need is a 1024x600 RGB with a touch screen.   The 1024x768 doesn't have a touch screen and the ones with a touch screen are not big enough.  I am not comfortable that I could be successful building a board that could bridge between the display.  Most of the boards this size seem to be LVDS, many have a 50 pin connector.

I do plan to use the STM32F7 for the fermentation station because that device needs a smaller display.

The change to the jetson allows me keep making progress and if in the interim I find a display that works I will go back.  I intend to use the stm32F7 in a project because I have a production project I would like to use it for.  The production project also requires a larger display, so I will continue to look.

[Joel Bodenmann]

Sorry, I didn't mean to be offensive or anything. It's just always good to know what factors people are taking into consideration when choosing their platform.

With larger displays it is quite common that you purchase the display panel and the touch panel separately and stick them together yourself.
That is also the reason why you won't find a display + touch combination that has the exact same connector like the one that came with the discovery board. When the touchscreen and the display panel share the same flex cable connection they usually tend to be manufacturer specific.

[inmarket]

Sounds like a raspberry pi might be a good choice as it will support framebuffer, standard hdmi displays of any size and standard serial or usb touch panels. It also has plenty of io.

[Sting]

@joel  Seriously, I wasn't offended.  My wife also accuses me of changing the plan all the time.  I have very little loyalty to the past if I can't see a path to where I want to go.  

About finding a display and touch panel separately:  Because I don't want to build a board for this project, due to my qualifications, I looked for a flex connector that would be like the one that is on the display that came with the STM32F7 and couldn't find one.  Maybe I didn't look hard enough.  Since I couldn't find something I had to rule this out.  For the business project I will be able to get my partner to build the connector, and he is waiting to see how my personal projects pan out before he is willing to participate.

@Inmarket  What would I get in the Raspberry Pi that I don't get in the Jetson TK1.  From my perspective the benefit would be performance.  The Brewery is a very simple device.  I have built most of it on a Arduino Uno.  Basically it has to measure temperature and use pwm to control a solid state relay to boil water.  The difficult parts are:  controlling the temperature +- 1 degree and halting the progress of the temperature at specific points for some time period.  The reason why the Uno didn't work was because of the display issue.  I have many different micro controllers and many different micro pc's.  If I knew I would get something from the Pi that the Jetson wouldn't do I would switch.

One problem with the micro pc approach is that because it is linux reading the temperature from the DS18B20 temperature sensors is accomplished using sysfs.  Each thermometer takes about 1 second to get the temperature.  This is way better on the Arduino and other such controllers because the temperature reading/translation can be done in two steps and one can read 8 thermometers in the same second.  This is the main reason why I want to use the STM32F7 for the fermentation device.  The fermentation device can ferment up to 6 different brews simultaneously and even though a second is a long time in these kind of devices, taking 7 seconds to measure all of the temperatures, 6 fermentations and the controlling device, seems excessive. There is very little user interaction other then setting the goal temperature for a specific fermentation so a smaller display could be used.