BasicPI

SDL (Simple DirectMedia Layer) is a 3D graphics engine that uses OpenGL or DirectX depending on platform. To use it is straight forward. You will do a few rectangles on screen with little work.

I am also working with GDI+ on Windows, so I was stunned as to how slow SDL is to start in comparison. I was even more stunned as I was looking for functions to draw circles, arcs and the finer graphics. They simply don’t exist. All I find is a function to do rectangles, point collections, pictures etc.

In simple words you will have to create a proper 2D library on top of this from scratch if you want to use this as a HMI framework. I have actually done similar tasks back in the DOS days so I know that this is a large task to take on.

Don’t take me wrong! Drawing a rude circle is done in a few lines of code. Drawing a high quality graphics one require a bit more work, but doing this with high performance will require a lot of hours.

It will not be my first option!

Using FSMC (Flexible Static Memory Controller) is straight forward as you set up the FSMC I/O and just access the memory directly. What happens is that FSMC Address and Data pins suddenly start clocking on the pins. But, how do I sample ?

I was first looking for some kind of “magical” burst technique in FSMC before it hit me that the one I am looking for is memory to memory DMA. I should be able to use the DMA directly from the I/O pins on the FSMC Data to SPI. The datasheet actually confirms this. This will allow me to sample at the speed of the SPI which in the case of a M4 is 42Mbit/s. The actual sample time will be lower since we need to adapt to an available Raspberry PI speed.

It is a huge difference between sample frequency and the frequency you can monitor. The reason is because you need an absolute minimum of two samples per Hz. The reality is that the more samples you get the more accurate your Logic Analyzer will be. This is why I actually am interested in 100Mhz because it would give me a fairly accurate monitoring capability at 10Mhz and a very high accuracy at 1Mhz. But, it is no way we can transfer 100Msps so we need to do smart filtering and trigger mechanism’s on the MCU.

I can use an external SRAM to sample with larger depth than the internal SRAM will allow me, but as this also uses FSCM we will be down at 50Mhz since the DMA need to do two operations. A second issue is that as we write we will be sending logic on the same pins we use for reading, so we need additional electronics to avoid that.

I was planning to use STM32F405Rx for this because it is a neat 64 pin MCU, but I notice that FSCM is only available on 100 pin and larger. In which case I can as well use the faster STM32F427.

I am however not sure if I want to go forward with this at all. It is doable, but the cost of using these large and expensive MCU’s makes me wonder if it would be better and cheaper to pick up a FPGA. I will however do the testing since I have the chips and the concept interest me.

<I will upload the pic a bit later … >

The M4 Olimex board have two buttons and I accidentally noticed that one of the buttons was loosening. Easy to fix with super-glue to add mechanical support, but would have been even easier to solve if routed a bit more wisely on the PCB.

Dealing with connectors, buttons or moveable parts that are SMD mounted you MUST take their mechanical support into consideration. If you don’t things will loosen and destroy your product. In this case it is was the PCB lane that was loosening because it ended in a way that made it easy to use the button to tilt it over. The button is mounted on the edge with the lane coming in from the other side causing a mechanical weak point. If lanes had continued a bit it would have strengthen the button significantly.

This one is from Olimex and is based on STM32F407 LQFP144. It has Ethernet, TF Card and 4 x 20 headers + Arduino Uno compatible headers.

As for the Arduino headers pay notice to the capacitors on the bottom half that will be in the way of most Arduino Shields. Also I am a bit surprised as to why they did not add a battery for the RTC on this one. This is impossible to mount on a bread-board, but you can use separate 1×20 or 2×20 cables etc. I purchased it for the 10/100 Mbps Ethernet since I needed this to prepare a full Ethernet stack.

I will return to the Ethernet stack in a later article. I ported uIP in ca 2 hours work, but I am planning to enable the FNET stack if I find the time.

I am not sure what kit I will be using for testing external memory, but this has nothing mounted on the FSMC port. The other boards have 1-8Mb SRAM added which is “ok” since it is on a separate chip select. Also, I realize that I might want to use that SRAM. We will see lets first do a proof of concept.

This is a STM32F429. It has a 64Mbit SRAM on the back. It uses the larger LQFP176 chip. This was a bit of a surprise because the header is 2.0 pitch making it incompatible with bread-boards.

This dev-hit is from HAOYU Electronics who produce some good, affordable kits. This is a LQFP144 version of STM32F407. This is basically the same as STM32F405 with Ethernet added. This board also have 128Mb Flash and 1Mb SRAM mounted. Again 2.54 pich headers enabling vero-board mounting.

My only comment on this kit is that it is as much a RAD kit as a Dev kit, but products like this need a minimum of one PCB screw hole to fasten the PCB to the motherboard. The reason I say this is because vibrations on robotics often make connectors move if they are not fastened.

Using a MCU board like this one actually makes a lot of sense in some low volume Projects.

This is another Cortex M4 that is a bit special. It runs on 72Mhz and have far less Flash/SRAM. It do however have 4 x 5Mhz ADC’s, Op amps and 3 x Motor Controllers on chip. Pitch 2.54 dev-kit so it can be mounted on a vero-board. Mounting dual headers on a vero-board is a bit tricky, but I have several working rat-nests to prove that it is possible.

This is one of the official STM32F429 kit’s using a LQFP144 with a LCD display and 64Mbit of SRAM + a ST-Link. You simply connect the USB on the ST-Link and start programming. This one has 2.54 pich headers that is possible to mount on a vero-board.

This is the 10.- USD dev kit for 5LP I spoke of earlier. P&P comes in addition, but I will encourage people to get one of these to play around with because it is not a “normal” ARM MCU. It actually contain two MCU’s as Cypress also add a programer at right. This can be broken loose and used independently. You obviously need a USB cable extender , but those cost 1-2.-USB on ebay.

This fits on a bread- or vero- Board making it easy to test out concepts.

Assuming using the external memory bus will work as I hope it also open up the possibility of a low cost 2-4 channel, 8 bit Oscilloscope at 60-100Mhz sampling speed. Using discrete components I should be able to create a high speed ADC etc. This should be sufficient for a 10Mhz Oscilloscope where you have 6-10 samples per Hz at 10Mhz.

To avoid the 176 pin chips I could also do 2 channels on a Hat and simply add Hat’s to to create a Mixed Signal lab kit. It adds a bit of timing complexity to sychronize input from several Hat’s, but it should be doable.

As a hobbyist working with robots and motor controllers I seldom deal with frequencies above 1 Mhz, but I need multiple channels + I like the concept of a low cost Oscilloscope  that can be programmed as open source. Using Raspberry PI for graphics means that my Oscilloscope can have a 1920 x 1024 (or even larger) mixed signal display with a standard HMI Interface.

The second side of this is that I can also create a 2 channel function generator with the same speed using a classic resistor ladder. This should be able to output programmable signal patterns at 5Mhz with 20 samples per Hz. I have dedicated chips that can deal with 40Mhz or higher, but those have limitation in patterns + I could add transistors to deliver 5Mhz with programmable Voltage and Effect.

Transferring data to Raspberry PI is an issue, but we can benefit from a faster SPI + we can filter data on the Hat because we only need to transfer as much data as we can display. This would make a heck of a lab kit if I can make this work.

I have a STM32F429 dev kit that I will test with to verify if this is doable.