cancel
Showing results for 
Search instead for 
Did you mean: 

STM32 New Year wish list

gdp123a
Associate II
Posted on May 07, 2009 at 13:34

STM32 New Year wish list

45 REPLIES 45
st3
Associate II
Posted on May 17, 2011 at 12:58

The documentation seriously needs either a re-work or a supplement that gives complete descriptions of how to actually use the various peripheral functions.

eg, the USART documentation just describes the specifics of the USART IP block in isolation - but to actually use a USART you also have to wade through the RCC documentation, GPIO documentation, NVIC documentation, etc, etc...

As another example, I don't think I've managed to find anywhere that clearly and explicitly states which APB clock is required by each USART. :|

As a further example, setting up an external interrupt on a port pin transition seems to require that the AFIO clock is enabled - and I don't think I've managed to find that clearly and explicitly documented anywhere. :|

etc, etc,...

dir1
Associate
Posted on May 17, 2011 at 12:58

1. Disconnect Vref and Vdda in 36, 48 and 64-pins STM32 (create pin +Vref as in 100-pins STM32). Please. It's not dificult.

2. Add internal precision reference 2,5V for ADC

[ This message was edited by: dir on 03-01-2009 21:46 ]

fastmapper
Associate II
Posted on May 17, 2011 at 12:58

Here are some of my STM32 wishes:

1. Fewer flash wait states at high operating frequencies

2. True 32-bit peripherals with word, halfword, and byte access. In particular, this means that 32-bit registers (such as the seconds counter in the real time clock) should require only one read or write to operate on all 32-bits. It also means extending peripherals to 32-bits where it makes sense. So there should be at least one 32-bit timer available on each device. If this is not possible, improvements such as hardware support for reading both halves of the time synchronized value in a 32-bit register would significantly improve access to these peripherals.

3. Improved branch prediction for loops -- or at least user configurable branch prediction options.

4. An option for working with large SRAM even when flash memory is small. There are a large number of applications (including imaging) that could effectively use a larger workspace. This could be accomplished using either internal SRAM or an external memory controller. As an example, here are some possible configurations that could be paired with 64KB flash: 20KB internal SRAM, 384KB internal SRAM, or external SRAM controller.

5. At least one or two digital to analog converters on each device.

st7,

USART1 uses APB2, USART2, USART3, UART4, and UART5 use APB1. See figure 1 in the overview of the datasheet or figure 1 in the system architecture section of the reference manual.

Generally the AFIO clock is required in order to work with the AFIO peripheral registers. I believe that the great majority of peripherals follow a similar rule, but there may be exceptions (involving the backup domain and the RTC registers for example).

I don't see it as a major problem, but some clarification in the documentation would be good.

st3
Associate II
Posted on May 17, 2011 at 12:58

Quote:

USART1 uses APB2, USART2, USART3, UART4, and UART5 use APB1. See figure 1 in the overview of the datasheet or figure 1 in the system architecture section of the reference manual.

That's the trouble - you have to search high and low to find this stuff.

And it's not clear if that diagram is supposed to be definitive and exhaustive, or if it's just illustrative.

There needs to be a clear, explicit description of what needs to be done, with cross-references to the detailed descriptions.

That's the principal thing that's missing - the cross-reference on how to bring all the separate parts together.

st3
Associate II
Posted on May 17, 2011 at 12:58

Quote:

USART1 uses APB2, USART2, USART3, UART4, and UART5 use APB1. See figure 1 in the overview of the datasheet or figure 1 in the system architecture section of the reference manual.

That's the trouble - you have to search high and low to find this stuff.

And it's not clear if that diagram is supposed to be definitive and exhaustive, or if it's just illustrative.

There needs to be a clear, explicit description of what needs to be done, with cross-references to the detailed descriptions.

That's the principal thing that's missing - the cross-reference on how to bring all the separate parts together.

obtronix
Associate II
Posted on May 17, 2011 at 12:58

Quote:

4. An option for working with large SRAM even when flash memory is small. There are a large number of applications (including imaging) that could effectively use a larger workspace. This could be accomplished using either internal SRAM or an external memory controller. As an example, here are some possible configurations that could be paired with 64KB flash: 20KB internal SRAM, 384KB internal SRAM, or external SRAM controller.

Oh boy, I would love that, I have to use the expensive D or E series to get 64KB of RAM which is barely enough. The D and E series has 384K and 512K, respectively, of FLASH, I need maybe 20K of FLASH and 20 I/O pins, what a waste.

It's not imaging processing either, just accelerometer data with FFT's. You store 4K x16 bits of data from 6 accelometers, it adds up real fast, 384KB would be make my product much better, but I'd settle for a smaller part with 64K RAM, just to reduce cost.

It's rare you see a small FLASH/large RAM part, must not be much demand.

gdp123a
Associate II
Posted on May 17, 2011 at 12:58

Hi StOne-32,

as requested, here is more detail about my wish list.

Current consumption:

There is an interesting article I read on the internet ''ARM Cortex-M3 core-based MCUs with ultra-low-power standby By Jean-Michel Gril-maffre, STMicroelectronics''. In this article it says: ''... Even though several techniques exist to limit the leakage of a digital library (increase poly length above minimum allowed by the technology, increase gate oxide thickness on transistors), such modifications impact the propagation time in the digital cells. Using such a library in the entire core logic would prevent the device from achieving high performance in run mode. ''

Although I don't understand most of this, it does give me the hint that a lower powered device could be produced - but it might have a lower maximum frequency and have less memory.

From my earlier tests, my application uses 5.8 milliamps (micro only) when run at 8MHz, with a sleep current of 965 microamps. At 1MHz the run current is 1.6 milliamps with a sleep current of 505 microamps. The 1MHz consumption is obviously no where near 1/8th of the 8MHz consumption. Leakage current? I wish an expert could explain why it is so and relieve my curiosity.

It would be great if the 1MHz run consumption was say 5.8mA/8 = 725 microamps and the sleep current was 505uA/8 = 63uA. Then I could use the chip with small Lithium coin cells where the maximum current draw is around 1mA. These coin cells prefer a nice steady low current draw.

Automatic CS:

I'm not sure which other micros have an automatic CS. All I know is that if I want to use a chip like the Linear Technology LTC 2641 16/14/12 bit DAC (or a LTC 16 bit ADC), I need to manually control the the CS line. Which means I can't use DMA to automatically load the DAC. If I use an interrupt to load the SPI then I have to wait for the transmission to complete to raise CS. The LTC chip mentioned above uses a 16 bit data word, so they are perfect to use with the STM32 (eg. for producing a simple low power audio output).

obtronix
Associate II
Posted on May 17, 2011 at 12:58

Quote:

From my earlier tests, my application uses 5.8 milliamps (micro only) when run at 8MHz, with a sleep current of 965 microamps. At 1MHz the run current is 1.6 milliamps with a sleep current of 505 microamps. The 1MHz consumption is obviously no where near 1/8th of the 8MHz consumption. Leakage current? I wish an expert could explain why it is so and relieve my curiosity.

Leakage is part of it, I assume you are using the internal 8Mhz clock? Another part of the problem is that clock is still running at full blast even when you divide it down, so it current demand is constant in both cases (not 1/8). There is a new revision to the Cortex-M3 (Revision 2 core), to help with ultra low power application, maybe STM will use it in their future products.

Anyway, this chip is meant to be pulsed at high speeds to get maximum throughput/energy used. So for a lithum coin cell application (which has 5-15mA pulse current capability, I think), if you duty cycle it at high speed for short periods of time, you should average
16-32micros
Associate III
Posted on May 17, 2011 at 12:58

Hi all,

Good suggestions and enhancement's features :) I will make a summary by the end of the week and post them in a single message with some formatting.

Cheers,

STOne-32.

loeffel
Associate II
Posted on May 17, 2011 at 12:58

Some other whishes for the STM32:

- USB Host or at least an OTG

- I2C more user friendly or rework on the documentation. I had and have troubles to get the I2C running as a simple master if there are other interrupts running on the system.

- USART with selectable timeout capability

- Timer capture input with capability to choose rising and falling edge detection.

regards