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.
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.
Modern CAN uses two formats referred to as CAN 2.0A and CAN 2.0B. These again can use at least two wired solutions. The one we discuss here is the high speed version using twisted pairs. Two newer relatives to CAN that require either a logic circuit or MCU with special port support are CAN FD and FlexRay.
CAN eXtended uses CAN 2.0B that often is called “extended frame”. CAN 2.0A uses a 11 bit arbitration field as ID, while CAN B add’s another 18 bits to this. CAN eXtended uses these 29 bits as follows:
- – 2 bit priority
- – 1 bit message direction
- – 8 bit device id
- – 10 bit stream id
- – 7 bit sequence number
- – 1 bit message continue indicator
As CAN only can carry 8 bytes on a single message we need to use several CAN messages for some of the larger easyIPC messages. To do so we take advantage of the 1 bit continue indicator. If cont = 0 we know this is a new message with a Message ID in the first byte of the payload. If we need to use several CAN messages as an envelope we add a envelope header and an envelope tail:
PID is 16 bit parameter ID. PID=0 is Envelope head, PID=1 is Envelope Tail. Envelope Head contain a 8 bit parameter indicating number of messages that at minimum is 2 and maximum 255. The first message will have cont flag =0, the rest will have cont flag =1 to indicate that this is not a message head.
Envelope Tail contain a 16 bit Envelope CRC which is the CRC for the total message payload.
BasicPI Hat’s uses SPI in a full network with up to 8 Hat’s per Raspberry PI. Communication with a STM32 will clock at ca 15Mhz (Set on Raspberry PI). The protocol uses GPIO pin’s as chip select for critical messages, but will otherwise rely on each device to filter out it’s own messages on MOSI. This allows Raspberry PI to send on MOSI independent of what device that is sending on MISO.
This is possible since all information about sender and receiver is in the message header in the form of a hat/stream-id and MOSI can be filtered in software. The SPI Message format is illustrated below:
Chip Select on MISO is always done between two messages from a Hat. Raspberry PI will either detect a pad character meaning the Hat has nothing to send or wait for a message to complete if the device uses it’s time slot. Each active Hat have a 1ms time slot before Raspberry PI switch to another Hat. The device with Chip Select active will send a status message and either continue with messages in the queue or send pad’s if no messages is waiting.
The way this should work is that messages on MOSI are sent in the same sequence as they are inserted into the queue. Messages on MISO will be received as soon as the Hat receive chip select. ME will load balance chip select so that Hat’s with large MISO queues receive more sending time than Hat’s with empty queues.
HAL (Hardware Abstraction layer) is an interface between “normal” user modules and actual hardware. It makes hardware access easy and portable, it also gives us a layer where we can write optimized, hardware specific code if we need to. We will add more HAL classes as we go.
ETC (Elapsed Time Clock) count the time in ms and ys since the MPU was started. This is used for time differences by the RTOS itself and available all through code using the ETC::millis() or ETC::micros() functions.
GPIO is a class that provide access to a collection of pins. GPIO collections are declared in global space by the user and support logical pin grouping. This means that user modules can toggle pins with a given name even if their location is different from hardware to hardware. This allows the user to “wire” a board during initialization to preserve portability on modules that need pin Access.
More details on HAL classes can be found on Documentation->HAL in the menue as they are added.
Looking at my Rx breakout board I realize I need to add a LED for status. I don’t like wasting pins, but not having a Status led will be a pain.
This is the current revision 1.0 of the Rx breakout board. I am trying to find a decent way to display schematics, but the EDA I use is a bit limited in that respect. I am not going to mention what I use because I intend to change that to an open source EDA soon.
This SWD Adapter was created to avoid the need for 2.54 pitch connectors on the boards and to have a standard way of supporting a debug environment with the mini version of ST-Link v2.
The form factor above is made narrow to allow it to be connected to a Hat that is in the middle of a mounted stack. The square version below is the same with a different form factor. These are PCB’s with two connectors that can be soldiered for hand, so they are designed to be dead cheap in volume and will be adapted to various boards.
I have used this for a while myself and it makes development on these boards a lot easier. The standard uses 10 pins, but keep in mind that only 4 of those (SWCLK, GND,SWDIO and RESET) are required. 5V/3.3V is just added for convenience. The serial port is nice, but might need to be dropped on some boards.
This is mostly for my own usage. I have a strong preference for wiring and testing on bread boards before I order PCB’s. Sometimes it saves you 2-3 extra rounds to be able to do simple concept testing. I have plenty of breakout boards with STM32, but I fancied my own with my own SWD connector etc. For now I am using the first GPIO Hat’s for Zero more on breadboards they are not designed for than on the Zero. It only have components on one side using a two layer PCB, so this is designed to be cheap.
This breakout will work for STM32F103Rx, STM32F105Rx, STM32F107Rx and STM32F405Rx. It might work for others as well, but I have not checked yet.