The build in 12 bit ADC will give a resolution of 0.0007V if I use it to control a 30V Lab PSU, so I was looking for something with a higher resolution. I did find something that could handle 24 bit @ 2.4Msps, but it required a NDA to see the price – I think not. A little surprised about prising on fast ADC’s.
The one over is a decent choice that is quite popular. ADS1256 from TI delivers 24 bits @ 30Ksps on 8 channels for ca 6.- USD +/-. It has been around for a while. The breakout board is ca 16.- GBP on ebay. I will play with this a little, but for now I will settle with that build in 12 bit on STM32 because they are also very fast.
I do however not need fast sampling rate, I need a very fast response in the MCU on changes. The build in ADC’s have threshold interrupts that should do that for me. Fun to come.
I do however like the ADS1256 so maybe I throw up a PLC ADC board with opto isolators. Non-isolated ones exist.
A breakout board with STM32F042F6. This can also handle STM32F030F4. Very small, cute and breadboard friendly. This little MCU is Corex M0 32 bit, 48Mhz, 32Kb Flash, 6Kb SRAM and contain a long list of IO including touch contacts. The board include x-tal (not mounted here) and a 3.3V PSU that also can act as a PSU for the rest of your design. The SWD Connector is available at top, so you can also Mount this vertical to save Space if you only need a few pins.
Hardware Abstraction Layer is a thin layer of software that “abstract” your code away from the actual electronics. Actually one of the better implementations around is the Arduino library, so it is many good reasons to copy this as much as possible. But, not all of it as Arduino was implemented on a 8 bit AVR and uses a blocking concept.
One thing we need to do different is a concept I call “Software Wiring”. As we use a HAL UART module we also need to tell the HAL module where this UART is located and what pin’s to use. ST have GPIOA, GPIOB, GPIOC etc that are physical Groups of 16 pins each, but if you access these in your code you also need to change your code if Your platform change. This reduces the portability of your source code, so I deal with this using a simple trick in the HAL GPIO module.
For each UART I create a logical HAL GPIO group that need to be wired for the HAL UART module. HAL UART will expect that Rx/TX, Send Enable, Receive Enable and Power On/Off are on selected logical pins that never will change. This Group Access physical pins through a table allowing us to re-wire in software as we initialize our platform.
The result is that I am left with a single function that needs to be re-wired to port source code from platform to platform. Obviously we also enable the physical ports 1:1 through the same mechanism.
Finally updated Revision 1.2 of the Rx breakout board.
- Minor correction ca 0.5 mm on width.
- Correct GND/3.3V tag swap.
- Added a User Led
- Added a jumper for the user led. This is connected on the PCB, but you can disconnect the Led and add a jumper if you want the led on a different pin.
- Added a Gnd connector for Oscilloscope.
- Replaced the Ceramic Murata crystal with a hole through HC49 crystal. The Murata is nice, but the hole through is easier to remove for RC crystal apps or other frequencies.
- Added X1 and X2 – VCAP capacitors to support STM32F4 – these must be replaced woth 0Ohm for F1.
- Added a pull-up on NRST.
This board should be possible to use as breakout for a large range of STM32FxxxRx boards including STM32F103, STM32F105, STM32F107 and STM32F405. I need to check datasheets on other LQPF64 MCU’s from ST.
According to the datasheet this should also work for STM32F205Rx MCU’s. I have no plans to verify this at present. Myself I only use F105 and F405 With an option to use F107 since it provide Ethernet in LQFP64 package.
Nice to see CH340G finally registering correct on Windows. The circuit below works just fine.
The first you always should do is to measure if you have power – in this case 3.3V – I actually did, but as I finally measured on the pins I noticed that I actually did not. Looking at my schematics (and routing) I realized that I had connected the circuit to the wrong 3.3V that I had not assembled yet – doh…
It is an annoying error and even more annoying that I did not see it straight up. The real problem here is that I have made it difficult for myself not providing test points on a rather complex board . But, I am very happy to see this working as expected.
The last I need is yet another board without code, but I like to draft some PLC boards. This is a com adapter connecting the backbone to Ethernet and external RS-X lines. The code will be a variant of what I will make for the com adapter.
The first PLC module I want to make is a box that can hold Raspberry PI + 1 or 2 Hat’s. Having the capability to add a RPI 3 or RPI Zero W is a great asset. It also provide a solution for industrial mounting of a RPI.
This enables 4 PLC modules “as is”:
- Linux/Windows computing module
- 5 port RS485/CAN communication Gateway
- 16 channel Servo/IO
- 8 channel DC Motor, 8 channel Servo/IO
I will create more Hat’s so they can be added as PLC modules as well. I am a bit wage on the details around how to integrate Raspberry PI itself. I want PLC connectors in front and that leaves Ethernet + USB at bottom. The more problematic side is accessing the backbone – suggestions are most welcome.
Maxim Integrated have started a PLC series called “Micro PLC” – the boards have a similar concept with STM32 at core and a backbone bus – except for that I don’t know much about them. It is a cute concept.
The system have several boards, the one above is quad channel analogue input. . I get the impression that the purpose is more to demonstrate Maxim technology than to create a PLC system thought, but who knows.
I see a lot of schematics and people who struggle with getting a STM32 working. I have only been working with F0, F1 and F4, but these SoC (System on Chip) MCU’s are dead easy to get working.
Basically they have internal oscillators so they only need 3.3V power. The F4 range also need VCAP capacitors – the number vary from MCU to MCU. F411 uses 1, F405 uses two etc – so check your datasheet it is well marked. I always use SWD, but you could also use Serial, SPI or CAN for downloading code. The capabilities vary from MCU to MCU, but I like SWD because it is only 2 pins + NRST + GND.
The important thing is – connect power and you should be able to download code. The main reason I struggle is short-cuts on PSU lines, so once you ohm your 3.3V ok – just expect it to work – repeating myself – it is very easy to get a STM32 ticking!