Well, my evaluation board came today. Now to try to acquire programming utilities.
Does anyone know offhand if any of the software companies ST mentions is kind to students?
Well, my evaluation board came today. Now to try to acquire programming utilities.
Does anyone know offhand if any of the software companies ST mentions is kind to students?
http://www.atollic.com/index.php/download/downloadstm32
Atollic has a free unlimited time and size C version at the link above. Paid adds some features (C++ etc) and you have to credit Atollic in your docs for products made with the free one.
Keil has a size limited free version but is has all the features of the expensive one but 32k is not much room to play with on a chip that can hold 1 meg.
@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.
A few of you might be interested in this recent Anandtech article. It talks about ARM's announcement of their new Cortex-A7 chip.
It seems to be what will be replacing the ARM7.
@mbolivar: Is there anything of the F4 maple port ready to be shared, no matter how incomplete it is ?
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, https://github.com/mbolivar/libmaple .
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?
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.
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.
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.
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 :)
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
- 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.
Disagree. Family-specific include files should specify base addresses, so that adding a family doesn't require modifying any central file. Using the correct -I<family-include-dir>
lets us pick the right one at compile time.
- HardwareSerial currently needs the bus clock speed in the constructor, which should be changed
Agree. Similar clock issues affect HardwareSPI as well.
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.
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.
I went on a free STM32F4 seminar today (in Bristol UK):
https://www.silica.com/events/seminar/silica/view/stmicroelectronics-cortex-m4-seminar.html
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.
Pete Harrison did a quick and dirty comparison of STM32F103RE with STM32F407VG (on the DISCOVERY board) performance at:
http://www.micromouseonline.com/2011/10/26/stm32f4-the-first-taste-of-speed/#axzz1bsvHxvsi
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.
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.
You must log in to post.