Not finished yet, but an early draft of my communiaction adapter.
STM32F303 is a M4 clocking at 72Mhz. It has strong ADC’s and build in op amps as well as 3 motor controllers on the larger chips. It is a very interesting MCU for specialised motor controllers, but have so far been priced in the 10++ USD region. Lately I noticed that CB and CC versions of the MCU are down to 3-4.- USD on AliExpress.
My interest in F303 is limited because I believe MCU’s like F405 and F427 are better choices, but F303 offer the LQFP48 package making it attractive on applications where a LQFP64 is to large. I have so far not considered it because of the cost. I will add veroboard friendly breakout boards for STM32 Cx chips later.
The Rx Version should be able to use my Rx Board. I have mentioned ST’s pin compatibility between MCU’s before. It simply means that if a feature is on both STM32F103CB and STMF303CB they will most likely be available on the same pins though registers and coding might be different. This makes it possible to start With a low end MCU and simply upgrade to get more Flash/SRAM/Speed or extra features.
Connecting things to a Windows PC is sometimes a bit of a challenge. I am in urgent need of a CAN-X adapter. These things cost and if I add my request for a Wired Ethernet, Wireless Ethernet as well as USB prices start to have several digits. The amount of software needed and the component cost is however not that big a job, so I can as well make one myself for the fun of it.
I will use STM32F405RG as MCU this time. This is an overkill, but I fancy doing something with this small M4 and it only cost 5.- USD.
- – 32bit ARM M4 168Mhz, 1Mb Flash, 192+4Kb SRAM
- – BasicPI SWD connector
- – Issolated RS485
- – Issolated CAN HS
- – NRF24L01+
- – 10/100Mbps Ethernet
- – Wifi
- – USB
This is my first Ethernet design and I am cheating big time. The F405 don’t have a Ethernet connector so I am adding a Wiznet W5500 chip. This provide a hardwired TCP/IP stack that we interface to through SPI. The smaller version of this W5100 should be well known for hobby makers.
As for Wireless we use ESP8266. Either ESP-3, ESP-12 or similar. This is a cheap solution that will work well in this case.
I am doing the same trick on USB. This MCU actually have a USB connection, but I am cheating and using a CH340 to get a serial over USB connection. I have used this for years and I never have any fuzz with this one. Programming a serial port is also much easier than programming USB drivers.
The rest of the code is a small router. I will not be doing any clever code on the CAN. I simply want to provide a dumb remote I/O and let software on the PC do the rest.
It’s not been much activity lately. You can blame the summer and the mess in my garden for that. I want to wire up a few experiments. One is a motor controller based on F405 and the other is a Ethernet controller based on F107. The Rx breakout board is excellent for this as it is vero-board friendly. Looking at my earlier draft I realize that I need to add a few more leds. I want the breakout to be as generic as possible, so using pin’s for leds is a challenge because it means those pins already are used. But, I notice that PC13 and PC14 are located quite handy so I will add a led on those.
The first batch will be only 10 PCB’s, but this board will be available in several options. I will make a few assembled boards available for ca 10.- USD + P&P later, but I will also be looking into options to manufacture the boards in higher volumes.
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.
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.
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.