2020-04-12 05:50 PM
As far as I understand, ART Accelerator improve the performance of the microcontroller and make it to save power. If what I said is ok, why is not ART always working? Why I should enable it to work. Shouldn't it always be working to improve the microcontroller performance?
If you can recommend me some document to read, I would be great.
Thank you.
2020-04-12 07:10 PM
The Reference Manual for the "STM32" you're using?
I don't think anyone claims it saves power, it is an outboard caching mechanism for the flash which is SLOW, and enabling it will engage a lot more transistors. It might net out as things run more efficiently. One of the cases is perhaps that making the FLASH physically faster would draw more power for sure, and that caching would get you most of the benefits with less of the costs. The performance is somewhat less predicable.
Generally you have the option to turn stuff ON, so a flaw in the design or manufacturing doesn't render the entire design unusable and untestable.
2020-04-13 09:52 AM
Hi, clive1,
Thank you for answer.
First I read it in a book Mastering STM32. When you ask me for the reference manual I said "It's true, I shuld have used a references manual", so I checked the STM32F205xx user manual.
Tables 20 and 21 in page 78 and 78, respectively, show the current in RUN MODE. Table 20 with ART accelerator enable, and table 21 with ART accelerator disable.
When ART accelerator enable the current consuption is 38 mA, and when it is disable the consuption is 48 mA.
2020-04-13 10:24 AM
It would interfere with flash programming, so it should be enabled only when the application starts, i.e. not yet enabled in the (factory or user) bootloader stage, or while flashing throug SWD.
2020-04-13 10:35 AM
Thank you for answer, berendi,
Excuseme, do you have some documentation about it? I would like to know more about ART accelerator.
2020-04-13 10:48 AM
Not really. I've just seen example programs always carefully disabling the cache before, and re-enabling it after writing the flash. Because flash programming is a slow operation anyway, it can't hurt much.
2020-04-13 12:10 PM
Note that the first table's description is "... or RAM", with footnote 1, which says, \
1. Code and data processing running from SRAM1 using boot pins
I'd like to hear ST's explanation (including the interpretation of these figures in AN3430 where this footnote is conveniently omitted).
Also:
All Run mode current consumption measurements given in this section are performed using CoreMark ® code.
CoreMark is a synthetic benchmark which does not very well represent real-world code; contrary - the jumpcache (which is mostly what ART is) favours the tight loops of which the bulk of CoreMark consists. This allows ST also to claim the "0WS" performance, which is a marketing lie.
This is also probably the cause of the weird recommendation of AN3430 to switch off the prefetch - prefetch (and particularities of its implementation are again not told by ST) is a feature favouring linear code, as opposed to the jumpcache.
Impact of both prefetch and jumpcache on the occurrence of actual read from FLASH has undoubtedly relatively dramatic impact on overall power consumption, given 20mA raw FLASH consumption as leaked by AN3430; and it's hinted also by prefetch being recommended to be switched off for decreased ADC noise in AN4073 (again with undocumented code and unanalyzed impact of that particular code).
So, in particular cases, it may quite well be that decreased FLASH read occurrence counterbalances the increased power consumption of the ART unit when switched on. However, while in real-world code there are often tight loops, but typically in controlling code there are often long heavily branching sequences and high percentage of interrupts (i.e. non-recurring code path change), rendering validity of synthetic benchmark questionable.
JW
2020-04-13 03:35 PM
Hi, waclawek.jan
As you said I could be a marketing strategy, so I think I shouldn't assume this apparent energy saving.
Thank you for your answer. It was very help full for me