2014-09-24 10:01 AM
[duplicated thread due to locked thread above]
Impressive, looking forward to real silicon. Nice: - all clocks apper to be able to tick up to 200MHz - low-power timer running independently of the main clock (i.e. also in stop mode) - quad SPI Things which made me sad at the first glance: - ST chose to omit double-precision from the FPU - up to 1MB FLASH may turn out to be a severe limitation - there's a gotcha in the ''fully pin-to-pin compatibility to 'F4'': LQFP100 has a shifted row of pins Question: Will there be DISCOVERY board? If yes, will it be same or different as the existing '429/439 one? JW #whiskey-tango-foxtrot2014-09-24 12:42 PM
The [DEAD LINK /public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/STM32%20F7%20Series%20The%20World%E2%80%99s%20First%20ARM%20Cortex-M7%20Core-Based%20MCUs&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&TopicsView=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/AllItems.aspx¤tviews=12]locked thread
Yes, seems a little odd there isn't 1 and 2 MB out of the gate. A proper cache architecture does however suggest the SDRAM might be a viable place to unpack code, either from internal flash, serial SPI flash, or SD Card The LQFP100 stuff is just wrong. Pins 18 thru 25 aren't like the diagram onhttp://www.st.com/st-web-ui/static/active/en/resource/technical/document/data_brief/DM00116941.pdf
, and surely there was a less broken way of doing this?2014-09-24 12:50 PM
2014-09-25 12:30 AM
I guess the new core ate up the silicon area of the second MB FLASH while hitting some technological (mask stepping/dicing/packaging) size limit.
> A proper cache architecture does however suggest the SDRAM might be a viable Viable maybe, but certainly suboptimal. Not only is it inevitably slower (cache helps but is no panacea) and decreases security; it also eats the pins, which in case of applications utilizing majority of the peripherals may be an asset potentially counterweighing even a drastical price increase for the extra FLASH, or a multi-chip package (ST has or had the know-how - they used to use it in the uPSD3xxx line).> The LQFP100 stuff is just wrong. Pins 18 thru 25 aren't like the diagram on
http://www.st.com/st-web-ui/static/active/en/resource/technical/document/data_brief/DM00116941.pdf
, > and surely there was a less broken way of doing this? No wonder, once they can't draw a proper diagram... :( JW2014-09-26 02:15 PM
Things which made me sad at the first glance:
- ST chose to omit double-precision from the FPU
Yes, that would be a frustrating omission, because the performance isn't going to be orders better than a M4 @ 180 MHz. With double precision you'd have somewhere to tie your flag compared to competitive solutions. ARM also suggests it should have single AND double precision, and as it is the CORE is quite small contrasted to the FLASH, RAM and PERIPHERALS, so you'd think having doubles would be a reasonable trade-off. Thermal Issues?
http://www.arm.com/products/processors/cortex-m/cortex-m7-processor.php
''Single and double precision floating point unit IEEE 754 compliant''http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1858/LN1902/PF260794
''The STM32F756xx devices are based on the high-performance ARM®Cortex®-M7 32-bit RISC core operating at up to 200 MHz frequency. The Cortex®-M7 core features a single floating point unit (SFPU) precision which supports all ARM® single-precision data-processing instructions and data types. It also implements a full set of DSP instructions and a memory protection unit (MPU) which enhances application security.''2014-09-29 12:28 AM
> ARM also suggests it should have single AND double precision, and as it is the CORE is
> quite small contrasted to the FLASH, RAM and PERIPHERALS, so you'd think having > doubles would be a reasonable trade-off. Thermal Issues? Or marketing. There may be an even fatter chip in the pipeline, and ARM might have asked an extra buck for the double-precision FP. At least I hope so. I wouldn't say this a couple of years ago, but we do have a micro*controller* application calling for floating point, which can't be circumvented effectively ... The gotcha for floating point is that it does not scale so straightforwardly in software as fixed does, so when a genuine need for double-precision arises, hardware support for single precision won't help. JW2014-09-30 01:37 AM
Hi Clive,
This is a typo in the Figure1. But other figures are correct.It will be fixed fo the next version.With regards,Heisenberg.2014-09-30 02:01 AM
So, does it mean that Fig.9 is OK, and compared to the 'F4xx, pin 19 is not VDD anymore, all pins from pin 20 to pin 49 are shifted clockwise, and pin 49 is VSS, right?
JW2015-05-22 12:41 PM
Was starting to wonder if the STM32F7 had fallen off the road map.
http://www.st.com/web/en/seminar/stm32f7-hands-on-seminars
Not seeing anything in the North-American market, and had an ATSAMV71-XULT for several weeks.2015-05-22 01:48 PM
Yes, this part got a mention in the RTEMS email list today.
I was wondering if I could order samples in a VG package or some sort of dev board to do some performance comparisons with the F4s, but it looks like they are unobtanium (damn you James Cameron, you've taken a perfectly good word and tainted it in your crappy movie!).