LeafLabs Garden » Topic: ST Micro STM32F4xx Cortex-M4 Documents available

LeafLabs Garden » Topic: ST Micro STM32F4xx Cortex-M4 Documents available http://forums.leaflabs.com/topic.php?id=1056 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:07:21 +0000 http://bbpress.org/?v=1.0.2 <![CDATA[Search]]> q http://forums.leaflabs.com/search.php ala42 on "ST Micro STM32F4xx Cortex-M4 Documents available" http://forums.leaflabs.com/topic.php?id=1056&page=4#post-7076 Wed, 02 Nov 2011 18:39:24 +0000 ala42 7076@http://forums.leaflabs.com/ Some infos to get the F4 FPU running: - the CodeSourcery arm-none-eabi-gcc-4.5.2 works fine - to be able to use the fpu use the compiler options -mfpu=fpv4-sp-d16 -mfloat-abi=softfp - make sure you do NOT use -fpack-struct, as the fpu load and save instructions need word aligned addresses. Otherwise the code throws an exception using unaligned addresses. - the fpu needs to be enabled in the startup code somewhere. Currently I use <pre><code>ldr r0, =0xe000ed88 //; enable cp10,cp11 ldr r1,[r0] ldr r2, =0xf00000 orr r1,r1,r2 str r1,[r0]</code></pre> in start.S, but it might be better to add <pre><code>SCB->CPACR |= ((3UL << 10*2)|(3UL << 11*2)); /* set CP10 and CP11 Full Access */</code></pre> somewhere. gbulmer on "ST Micro STM32F4xx Cortex-M4 Documents available" http://forums.leaflabs.com/topic.php?id=1056&page=4#post-6994 Wed, 26 Oct 2011 13:43:07 +0000 gbulmer 6994@http://forums.leaflabs.com/ becker - I am happy to have an incomplete but reasonable abstraction that makes the common cases easier, and don't prevent me getting at the hardware. As long as the default initial values are meaningful and usable, for example PWM or ADC, I am fine. Maple lib has been around in some form for more than two years and I don't think the abstractions are close to complete, so I don't expect some 'magic' to suddenly make them all complete and right. I agree with you that poor abstractions get in the way, and poor implementations can maken things harder or more error prone. For example, implementations that cache register values into variables, can be a nightmare because it is error prone or nerve wracking to work around them. Similarly I don't like something abstract which tries to force a bunch of registers to be 'consistent', rather than give access to the individual components. For example, I do think the HardwaretImer's setPeriod is a poor abstraction because most values for period have multiple prescaler & reload values. IMHO it is better for the user to understand a little bit more detail about the HardwareTimer's counter, then use a calculator to work out the two numbers to have exactly the properties needed. This seems simpler, more stable and robust than hope a piece of library software will do the right thing for most cases. In this case it doesn't matter because the library gives access to the pre-scale and reload values, but an interface which only provided setPeriod would not be good. So I don't expect abstractions of the timers which are complete, but I do expect to be able to use the useful parts and work around them for the extra functionality. I do expect to have an abstraction of the counter, with prescaler and reload value. I'd like more control, but I am okay with nothing more than up/down or just up counting. If I need more, I am happy to get at the raw-hardware. I'd like an abstraction for the encoder. I do expect to have an abstraction of an output channel. I'd like one for an input channel. Because I don't expect perfect, complete abstractions, I'd prefer things to match the ST Micro Peripherals documentation (RM0008). So I'd prefer to have the register names match the ST documentation. Any alternative to following the ST documentation needs to deliver significant added value (cute or nifty do not count:-) (a bit off topic, sorry folks full disclosure: I am not a member of LeafLabs staff.) becker on "ST Micro STM32F4xx Cortex-M4 Documents available" http://forums.leaflabs.com/topic.php?id=1056&page=3#post-6990 Wed, 26 Oct 2011 08:38:23 +0000 becker 6990@http://forums.leaflabs.com/ I don't entirely agree with "provide a decent abstraction". Sometimes abstractions just get in the way and introduce bugs. A good test is "does the user ever have to look below the abstraction?". If so, the abstraction needs to make a major improvement in code readability to be worthwhile. (And often the "readable code" ends up being superficial -- changes often introduce subtle bugs.) There are enough quirks in functionality that it's difficult to provide an abstraction that simplifies yet allows fully using the device. Timers are a good example. Every one is slightly different. Some have complementary outputs, some have up/down capability, some can be chained, and some trigger specific devices. gbulmer on "ST Micro STM32F4xx Cortex-M4 Documents available" http://forums.leaflabs.com/topic.php?id=1056&page=3#post-6989 Wed, 26 Oct 2011 07:14:35 +0000 gbulmer 6989@http://forums.leaflabs.com/ Pete Harrison did a quick and dirty comparison of STM32F103RE with STM32F407VG (on the DISCOVERY board) performance at: <a href="http://www.micromouseonline.com/2011/10/26/stm32f4-the-first-taste-of-speed/#axzz1bsvHxvsi" rel="nofollow">http://www.micromouseonline.com/2011/10/26/stm32f4-the-first-taste-of-speed/#axzz1bsvHxvsi</a> The code comments show cycles, so these differences would show running at the same clock speed. The numbers are generated by Rowley Crossworks. I assume they are correct, but I'd like to verify them. Very encouraging. It suggests improvements of about 7x, or more, for float operations. Only float operations, and a few arithmetic operations show this improvement, the rest should be the same number of cycles. Pete's results show an anomaly on long load and store which is a bit weird. Of course, the STM32F4 could be run a tad over 2x faster clock too, giving a theoretical speed-up of 14x or more on floating point operations. gbulmer on "ST Micro STM32F4xx Cortex-M4 Documents available" http://forums.leaflabs.com/topic.php?id=1056&page=3#post-6984 Tue, 25 Oct 2011 16:16:27 +0000 gbulmer 6984@http://forums.leaflabs.com/ I went on a free STM32F4 seminar today (in Bristol UK): <a href="https://www.silica.com/events/seminar/silica/view/stmicroelectronics-cortex-m4-seminar.html" rel="nofollow">https://www.silica.com/events/seminar/silica/view/stmicroelectronics-cortex-m4-seminar.html</a> It was a good use of my day. We got three free evaluation boards! STM32F4, STM32L, STM8L We only used the STM32F4 DISCOVERY in the workshop. We used it with Keil's free tools, which we also got (on a USB flash drive) We did about 4 small projcets to get to grips with the tools, the chip, and a Real-time OS. Pretty nice debug. It has a second chip handling the USB hardware debug support. I have been resistant to using a second chip on-board but if the debugger worked well, I might be persuaded to change :-) Debug supported the usual source-code orientated breakpoints, and could watch data values, they said including peripheral registers (register writes, not spontaneous external inputs, I believe). There were some knowledgeable techies in the room too, so we got several questions resolved during the day. So very good stuff! The STM32F4 Discovery is only £11.67 (GBP) including Tax anyway, so not a fancy freebie, but definitely worth havinf someone who could help drive Keil and the CMSIS libraries. It has a 3-axis accelerometer, microphone and headphone amp, plus some LEDs and buttons, so plenty of fun, and the free Keil IDE (crippled to 32KB program) seems to be enough to do some experiments.Be warned, there are some bugs in Keil which are being worked on, but likely won't be fixed this week. If there is anyone in Europe who can get along to one of the seminars, and is interested in STM32F4, I recommend you try to go. But you will have to be very quick. mbolivar on "ST Micro STM32F4xx Cortex-M4 Documents available" http://forums.leaflabs.com/topic.php?id=1056&page=3#post-6977 Tue, 25 Oct 2011 12:54:10 +0000 mbolivar 6977@http://forums.leaflabs.com/ Hm. I think I'd prefer to keep base addresses in the peripheral headers, rather than consolidate them into one file. SPI and timers don't care about each other, so it's bad separation of concerns to stick the addresses together. What the actual addresses are doesn't really matter; what's important is the peripherals available and the functionality they provide. If we're going to provide a decent abstraction, the registers themselves should lose prominence in favor of devices and the functions that operate on them. Focusing on registers leads to the kind of unportable code that ST writes. ala42 on "ST Micro STM32F4xx Cortex-M4 Documents available" http://forums.leaflabs.com/topic.php?id=1056&page=3#post-6975 Tue, 25 Oct 2011 11:07:51 +0000 ala42 6975@http://forums.leaflabs.com/ What I ment is you could keep the family specific base addresses for all peripherals in one file for each family, so the base addresses are not scattered over several files. Might make sense to add the base addresses to the rcc_dev_table, so the info is kept in one place. mbolivar on "ST Micro STM32F4xx Cortex-M4 Documents available" http://forums.leaflabs.com/topic.php?id=1056&page=3#post-6974 Tue, 25 Oct 2011 10:28:47 +0000 mbolivar 6974@http://forums.leaflabs.com/ <blockquote> - some of the identical peripherals like USART1, TIM1, TIM8 and also ADC1-3 have different base addresses now. Base addresses should be kept in a central table. </blockquote> Disagree. Family-specific include files should specify base addresses, so that adding a family doesn't require modifying any central file. Using the correct <code>-I<family-include-dir></code> lets us pick the right one at compile time. <blockquote> - HardwareSerial currently needs the bus clock speed in the constructor, which should be changed </blockquote> Agree. Similar clock issues affect HardwareSPI as well. ala42 on "ST Micro STM32F4xx Cortex-M4 Documents available" http://forums.leaflabs.com/topic.php?id=1056&page=3#post-6956 Mon, 24 Oct 2011 09:03:40 +0000 ala42 6956@http://forums.leaflabs.com/ When you restructure the code and do not want to copy everything, you should keep these points for the F2/F4 in mind: - some of the identical peripherals like USART1, TIM1, TIM8 and also ADC1-3 have different base addresses now. Base addresses should be kept in a central table. - HardwareSerial currently needs the bus clock speed in the constructor, which should be changed ThomasB on "ST Micro STM32F4xx Cortex-M4 Documents available" http://forums.leaflabs.com/topic.php?id=1056&page=3#post-6943 Sat, 22 Oct 2011 02:26:27 +0000 ThomasB 6943@http://forums.leaflabs.com/ Yes,the F4 should be really similar.. I had a look at the errata sheet. If you check the CPU ID of the first F4 Series you will get the ID of the F2 So it seems that the F4 is 'only' a F2 with enabled floatingpoint :) mbolivar on "ST Micro STM32F4xx Cortex-M4 Documents available" http://forums.leaflabs.com/topic.php?id=1056&page=3#post-6940 Fri, 21 Oct 2011 14:05:01 +0000 mbolivar 6940@http://forums.leaflabs.com/ <blockquote> The difference between the F2 and F4 is quite small, the clock system and I/O should be almost identical, so the F2 to F4 migration should be simple. </blockquote> Exactly. F2 -> F4 should be pretty trivial, and ST has a lot already written (AN3427 and AN3364) about converting F1 -> F2, but nothing I could find for F1 -> F4. It seems like a win to support all three, and having F2 sit in the middle as a checkpoint for progress should make debugging easier. ala42 on "ST Micro STM32F4xx Cortex-M4 Documents available" http://forums.leaflabs.com/topic.php?id=1056&page=3#post-6935 Fri, 21 Oct 2011 07:09:56 +0000 ala42 6935@http://forums.leaflabs.com/ I have an GitHub account, but have not really used it. At least I know how to clone the files from GitHub :) The difference between the F2 and F4 is quite small, the clock system and I/O should be almost identical, so the F2 to F4 migration should be simple. It requires some compiler option changes to use the fpu, but this is a later step. mbolivar on "ST Micro STM32F4xx Cortex-M4 Documents available" http://forums.leaflabs.com/topic.php?id=1056&page=3#post-6926 Thu, 20 Oct 2011 22:35:11 +0000 mbolivar 6926@http://forums.leaflabs.com/ <blockquote> @mbolivar: Is there anything of the F4 maple port ready to be shared, no matter how incomplete it is ? </blockquote> No, not yet. We're going to go F1 -> F2 -> F4; however, the first step will be to restructure libmaple so that adding a new family affects the rest of the library in a minimal way. The current mess of #ifdefs is a bit disgusting. I've been thinking about the best way to do this for a couple of weeks now, and I believe I've got a reasonable initial design in my head. I hope to have something worth pushing by the end of the week, even if it's just to my libmaple tree, <a href="https://github.com/mbolivar/libmaple" rel="nofollow">https://github.com/mbolivar/libmaple</a> . My plan of attack can be summarized as "apelike imitation of the Linux kernel", so if you're familiar with how arch/ is laid out, you can guess the direction I'm going in. Help on this is extremely welcome. Do you know how to use git / have a GitHub account? dreamcat4 on "ST Micro STM32F4xx Cortex-M4 Documents available" http://forums.leaflabs.com/topic.php?id=1056&page=3#post-6916 Thu, 20 Oct 2011 06:26:21 +0000 dreamcat4 6916@http://forums.leaflabs.com/ A few of you might be interested in this recent Anandtech article. It talks about ARM's announcement of their new Cortex-A7 chip. <a href="http://www.anandtech.com/show/4991/arms-cortex-a7-bringing-cheaper-dualcore-more-power-efficient-highend-devices" rel="nofollow">http://www.anandtech.com/show/4991/arms-cortex-a7-bringing-cheaper-dualcore-more-power-efficient-highend-devices</a> It seems to be what will be replacing the ARM7. ala42 on "ST Micro STM32F4xx Cortex-M4 Documents available" http://forums.leaflabs.com/topic.php?id=1056&page=3#post-6915 Thu, 20 Oct 2011 06:21:43 +0000 ala42 6915@http://forums.leaflabs.com/ @mbolivar: Is there anything of the F4 maple port ready to be shared, no matter how incomplete it is ? I got my F4 discovery board in the mean time and it accepted the before untested boot loader that I modified for the F2 CPU a few months ago. After disabling the USB stuff the led was flashing, so it looks like the CPU initialization and port setup was good enough in the first try. I already use a program start address of $10000 in the boot loader and linker script to adapt for the different flash rom pages sizes. I want to start porting the lib on the weekend, so anything that is already done is welcome.