8 years, 8 months ago.

What is best way to Get different configuration from STM for a given board.

What is best way to get this kind of request into the STM32 product managers?

I love the Nucleo-F303K8 which I can solder right into prototype designs but am quite often forced to use the F401RE to obtain sufficient pins. A board that follows the general plan of the F303K8 would but is twice as long exposing twice as many pins would be super helpful. I don't like the form factor or pin layout on the F401RE and find it cumbersome to fit into prototype / demonstration projects where size matters. The PSoC CY8CKIT-043 is just about ideal in form factor versus available pins but I prefer the mbed software environment. I personally prefer to receive the board without header pins so we can solder wires to it directly. We lose a little time soldering but we lose many time more hours diagnosing loose connections than we do soldering.

It would be good if you could produce the boards assuming the CPU portion will run from an external power supply so we could simply supply 2V and run successfully. This should be pretty easy simple by adding a separate regulator so the programmer side runs at 5V while the CPU remains isolated at a lower power level such as 2V all the time. It may require a level shifter for the programming signals but those are cheap. A 2nd regulator could produce 2V delivered to the CPU side of the board via a diode so the programmer can never be never powered from the CPU VDD net. This would allow us to plug in the external voltage supply with anywhere between 2V and 3.3V with no conflict and without paying the cost of a separate regulator when running from battery. You should provide a simple jumper to completely disconnect the CPU VDD from the programmer V+ to make it easy to prevent excess drain against the USB port.

You have some great chips but mbed is extremely slow supporting some of the advanced features in a nice way. Even when the functionality is available in a private library it is slow to migrate into the standard product. For example the ADC component should have a method that says set_href that can switch the reference voltage between VDD, Bandgap and aRef because this is a heavily used feature that is not properly supported. VBat is a great chip level feature to read VDD using an internal voltage divider and is needed for just about any battery enabled application but it is not properly exposed via mBed. Why not expose it as a function ReadVDD() so it can be used as a multiplier for the ADC reads. You should also provide built in support for differential_adc where you specify 2 pins, Use and routing of the OpAmps and built-in support for your fast comparators. If you need to hire external consultants like A2WH to expose the more of the full capabilities of STM32 chips in mbed then I think that would be a good investment as it would give you a competitive advantage. I prefer to use your chips in mbed but we are forced to make trade-off decisions. It is more cumbersome to use PSoC software compared to mbed but if we lose days every time we need to use an advanced CPU feature to write drivers in mbed then the cost of those drivers can end up higher than that cost of writing our software in the clumsier PSoC C environment but with PSoC I can be confident that I am accessing the chip features correctly and will get a successful result. I think you would end up garnering the majority of the new mbed dev projects started by professional engineers with improved mbed peripheral support for your STM32 chips.

You have a nice free-running ADC conversion feature with DMA support in the CPU. From this point it is trivial to have a series of variables that contain the last conversion reading so rather than calling adc.read() program can simply access the last reading. It then becomes easy to support low level averaging of the ADC reads rather than seeing it done in much more expensive polling code. This can be exposed with an AnalogIn object such as ADC1x.setFreeRunning(clockSource, freqDivider, &tagetVariable). Combined with a simplified overload of ADC1X.setFreeRunning(&targetVariable) that uses a default read rate. It can be extended with functionality to enable low level averaging ADC1X.setAveraging(maxNumRead) and ADC1X.setAveraging(maxNumRead, newNumCallback). You may as well add the function ADC1.setVMult(R1,R2) so the ADC reading can adjust it’s reading for the voltage divider since that is a common use of the ADC. You can also add a method for ADC1.setLowerLimit(LimitVolt, &callback) and ADC1.setUpperLimit(LimitVolt, &callback). With this support you are getting closer to supporting the critical chip features. Please note these changes are non-breaking so old AnalogIn code continues to run while exposing the advanced features in an easy to use fashion.

Every embedded project I work on with the rare exceptions must run from battery in production where we prefer to run at 3.3V on the main bus or 2V if all the peripherals allow it. Making assumptions that change the VDD voltage on the CPU portion of the board when it is plugged into the USB for programming complicates our designs. It is better to keep the programmer side and the CPU side of the board as isolated as possible. Please make it easy to add the battery and drive the CPU side from battery while the USB port powers the programmer side. Think of the programmer more as a ISP programmer interface. In an ideal scenario the programmer is a separate component that connects via a header when programming or debugging but is absent the rest of the time. When the programmer is connected it should not change the operating voltage on the CPU portion of the board otherwise it greatly complicates ISP updates. You accomplished 75% of this with your F401RE design but missed it in the F303K8 design which doesn’t even have the line to break the board to isolate the programmer and still support ISP updates. The funny thing is that you really need this capability in the F303K8 which is the size and shape to make it friendly for permanent embedding into prototype designs where we absolutely do not want to pay the power cost to operate the programmer side of things when running from battery. Most designs need to support field level ISP firmware updates anyway so the ISP approach makes it easy. I don't really care about the line to break the programmer off physically but I care a lot about isolating the programmer circuit so it is completely inert when not plugged into the USB for programming.

The most common communication interfaces I use are SPI1, I2C2, TX1,RX1 and I almost always consume all the ADC pins. Your default mapping should bring the default pins for these interfaces out in a way that using all the ADC pins does not conflict with using SPI1, I2C1, TX1, RX1. The CPU supports these functions on alternative pins so I think it is mostly an issue of routing.

Thanks Joe Ellsworth CTO of A2WH

Question relating to: