BasicPI

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.

I am not sure this will work, but many of the STM32’s have an external memory interface that is capable of a very decent clock speed. An F7 clocks the memory bus at 108Mhz, a F42x at 90Mhz and F405 at 60Mhz etc. The data-bus vary from 16 to 32 pins, but you need the LPQF176 for 32 pin data-bus.

The issue is that if I use the data-bus as Logic Analyser pins I should be able to sample at this speeds in bursts to create a high frequency Logic Analyser. I am not so fuzzed about the high frequencies because I mainly want a x channel Analyser that can display up to 10Mhz. It is very seldom that I come across higher frequencies and I don’t want the added complexity.

A 100Mhz, 32 channel Logic Analyser sounds great, but the added complexity of routing a LPQF176 with 100Mhz signals in mind is not worth it. A F405 with up to 60Mhz is more than I want, but it should not have any challenge with my 10Mhz on 16 channels.

The upside is that I also can use the same ports as output and have a 16 channel Logic Generator. That is assuming I can use the external memory interface the way I now plan. If it works we will be able to support 1-6 samples per Hz depending on how fast I run the clock.

The downside with 60Mhz or faster is that you start getting additional challenges on routing as the frequencies increase. As a hobbyist I prefer to stay well below 50Mhz due to this and this is one of the few applications where I could benefit from higher frequencies.

Early morning planning!

Whenever dealing with applications that will be depending on high performance it is wise to check out bottlenecks asap. This apply to all risk scenarios based on assumptions, simply check them out first because they might force your next step. I have three checkpoints coming up:

(1) Speed of SPI with a Hat involved. I am fairly confident on this due to the nature of SPI.

(2) Sampling speed on STM32 and 5LP. I am actually expecting 5LP to be capable of sampling GPIO at a very high frequency, but I might be wrong. Dealing with programmable logic I was hoping for far more than 10Msps, but reading the datasheet I get an impression that this might be a wrong assumption. SPI on a STM32F405 is 42Mhz and GPIO 84Mhz, ADC 2.4Mhz etc. I fail to see similar numbers on the 5LP. I know I am comparing a Cortex M3 with a much faster M4, but I expect a lot of performance from Programmable Logic. The reason for this is because I am hoping I can use the logic to buffer as I sample using the logic’s clock speed like I would have done on a FPGA. But, I realise that I might be in error on this!

(3) Speed of graphics. Raspberry PI is fully capable of full screen animations at 50fps using the GPU’s, but we need to verify that the graphics library we use will support this. I know I can do 50fps on Raspberry PI with GPU’s, but can I do so with the graphics quality I want?

I did a GPIO Hat earlier and due to the pin compatibility on STM32 I can just replace the M3 with a STM32F405 and use this to sample GPIO pins. This will act as a low cost Logic Analyzer. My expectation is that I can sample in a Close Assembly loop, apply smart filter and trigger Logic and use DMA to transfer buffers to Raspberry PI. The sampling speed will depend on MCU speed. 10Mhz means I need a maximum of 16 instructions per sample on a 168Mhz RISC. I know I am on deep water on this, but we will see. I am also curious as to what sampling speed I can achieve with a M3 only. It will be funny to test this regardless.

Doing the same on 5LP is also very easy due to the breadboard friendly dev kit at 10.- USD. Time to do some testing.

Cypress released a Cortex M3 MCU some time ago that caught my interest. I ordered two devkits costing 10.- USD each and all in all their concept actually impresses me. Cypress have for years released MCU’s that are referred to as “PSoC” (Programmable System on Chip). The difference is that a 5LP includes a ARM MCU, but very little I/O by default as this will have to be coded in Verilog logic. Basically it is a merge of a MCU and a programmable digital- and analogue- sub-system.

What caught my attention was their free IDE containing a C compiler and a EDA to program logic in block diagram form. This just had to be tested and I am always impressed by something as complex as this being made so easy. I am also pleased to see that all required tools are free so I will advice to pick up a kit and start hacking!

Comparing 5LP with STM32F105 (as an example) is like comparing apples and bananas. The STM32 comes with a pre-defined list of I/O and if you only need standard I/O it will be far more cost optional. But, the issue with 5LP is that it can do so much more than standard I/O.

The included plug&play blocks also comes with C libraries, but testing a simple UART I must admit that the C library did not impress me. Cypress (the Company) did however impress me because as I communicated my thoughts back to Cypress I was contacted by several people in their organization to discuss my opinions. Obviously the company care a lot about their products and customers.

I have three applications in mind for 5LP:

• An advanced GPIO Hat with programmable Logic.
• An Oscilloscope.
• A Logic Analyzer.

I must however admit that while I am fairly comfortable with STM32 this MCU is so complex that it put my skill-set at a test. I need a far better understanding of it’s capabilities before I start any project with this one.

One of my interests  for some time have been how to create a MSO (Mixed Signal Oscilloscope). I have several scopes, but I lack a Logic Analyzer on any of them.

My first thought was to bit-bang the GPIO of Raspberry PI directly, but as I looked into this I realized that I would not get much speed out of it. The issue is that Linux can’t really sit around bit-banging as it got other tasks as well. To actually do this you would be better of without the OS running.

They have created a 14 channel, 100Mhz Logic Analyzer on Beaglebone Black, but that makes heavy usage of the 2 embedded PRU’s. It would make sense if we could use one core to bit-bang, but I am not sure how to do that without replacing Linux itself.

One channel is typically 2kb of display data for a frame on a 1920×1024 screen. To be ideal we need a minimum of 25 frames per second (fps) and preferable 50 fps. That is ca 50-100Kb per second eight channels. Or more exactly 200Kb/s for 16 channels which again is ca 1.6Mbps and well within what we can expect from the SPI if we use a Hat.

A STM32 F4 can sample rather fast. Clocking at 180Mhz it should be able to do intelligent sampling of 16 channels up to 10M samples per second if the write the code correctly. This will obviously include some logic to trigger a sample run and upload it. As uploading is done by SPI from a DMA it don’t lake MCU time and we just need to fill a buffer and send it. This Application will need to be tight.

10Mhz will be good, but the hard fact is that most of my needs are covered with 1Mhz. The additional win here is that we get to program the analyzer logic so we can add recognition of things like CAN, SPI, I2C, UART etc.  I am considering two MCU’s for this job:

STM32F405 ticks at 180Mhz and is a M4. Cypress 5LP is a ARM M3 ticking at 80Mhz, but it contains programmable logic that might significantly increase the sampling frequency if used correctly.

The drawing above illustrate the different components used to achieve a complete application with HMI. We have briefly discussed the internals of the Hat (left) consisting of hardware interfaces or communication drivers, a IO configuration and the SPI driver communicating with Raspberry PI.

RPI have the master SPI driver and two new components that are part of it’s easyIPC server. One is a Data Repository. Basically a database over available features and data associated with it. This database will be in memory.

API Server allows easyIPC to be connected to multiple clients either on the same Raspberry PI or from a different computer. This connect your HMI application to easyIPC as if it was a database of information.

HMI framework is basically the GUI used to visualize real-time data and add user Interfaces.

This is a very brief drawing sop we will consolidate it as we finish it.