It would be really interesting to know why Keil omitted driver for SPI4 in their BSP software pack for STM32F4 family - SPI1, SPI2, SPI3 and SPI5 are supported, but SPI4 (and SPI6, for that matter) are not... Not to mention wrong DMA channel assignments for SPI2. I mean, it's not a problem to fix such things, but then new release comes out and you can't just upgrade, since bugs might not be fixed and you have to do it all over again. Pretty lousy work...
Hello Dejan, which version of the STM32F4xx_DFP are you using (check the Pack Installer)? 1.0.7 should fix the problems you referred to.
Matthias
RTE version is 1.07, but SPI_STM32F4XX version is 1.04. And it is definitely not fixed.
this issue is kind of moot due to the afct that manufacturers updts are notoriasly slow getting into the Keil directories.
when using device specifi code ALWAYS get it from the manufacturers website
Erik
PS not a big blame to Keil, keeping up with every manufactutrers upgrades (often no message "xx is updated" is sent) would be a herculean task
I am not complaining about missing drivers - I am complaining about poorly written ones. If they decided to release a driver, somebody should at least check for formal errors...
Well, "It would be really interesting to know why Keil omitted driver for SPI4..." certainly sounds like a complaint about a missing driver to me!
Let's make things clear - in RTE there's a single SPI driver file that contains instances for SPI1, SPI2, SPI3 and SPI5. Even if you consider it as a separate driver for each SPI interface, there are still bugs that make it clear nobody tested it for real at all - like wrongly assigned DMA channels, for example... Anyway - over and out.
still bugs that make it clear nobody tested it for real at all - like wrongly assigned DMA channels, for example did you get it from Keil or ST?
... whose name is in the copyright notice?
Yes, and isn't a great deal of software coded without direct access to hardware, in all possible permutations. Sometimes you're just given a specification and told to make it happen.
How many halfwits have we seen here complaining that something compiles and links without error, but then fails to actually work, as if the syntax checker can diagnose programming errors.
Submit a bug report to support, and move along. Better yet, fix the problems as you see them, and submit a complete patch with your report.
Better yet, fix the problems as you see them, and submit a complete patch with your report.
What???
But that would require thought and a degree of commitment. Two qualities that appear to be disappearing.
Keil are by no means alone in having problems in some of the source code they supply.
Just yesterday, a colleague downloaded some source code from Microchip. Compilation threw up a number of rather obvious minor errors. I saw it and determined that it would have been easy to at least get past the first hurdle.
Did my colleague attempt to fix it? Nope. he just swore, whinged, dumped it and then downloaded something from another site.
Anyone know someone who is looking for a firmware writer that is prepared to take time to think about a problem?
Many moons ago, you built the hardware yourself, or payed lots of money for the hardware to program. Today, everyone can get a $20 development board and start hacking code. Somewhere along the line, the commitment got lost.
People are so busy locating code to cut/paste that they don't spend time learning the hardware they are using. And they don't learn the behavior of assemblers/compilers/linkers.
The cut and paste generation will put its mark on society.
I wouldn't say this is a loss of commitment. Embedded software development is going through the same paradigm shift PC development did long ago. The application level software gets far more complex, but the hardware access is getting more abstract. Many moons ago no one asked you to have TCP/IP connectivity, USB stacks or a full blown graphical interface. And a "driver" for an 8051 SPI was actually 5 lines of code that wrote some values to SPCON or SPDAT. I can see some slight differences in complexity and I can understand that many developers don't want to reinvent the wheel over and over again.
Many moons ago, I started a project for Intel's 8048. Complete manual (TRM+datasheet) has ~100 pages. Program memory was 2K in size adn there were just a few peripherals. I wrote my own assembler & simulator in for it, as I had nothing else at disposal. TRM for STM32F4xx has 1710 pages. I agree that you should know your hardware - otherwise you can't complete the job properly. I understand (and do not expect) that Keil should have a driver for any imaginable Cortex chip's peripheral since it's an enormous task which requires a lot of resources to be done. When you first start with new architecture (or device), there's a lot of vague points in the manual - points that are hard to understand from sparse information that's given. Working piece of code often helps you to understand it better. But, if that piece of code is not working, you will be only more confused. I also know that software bugs are fact of life and anybody claiming that he or she write a bug-free code is not telling the truth. But some parts of the code must be bug-free, otherwise your device won't work at all. And device drivers are cerainly in that class of code.
In my oppinon, it's better not to release anything at all than releasing non-working driver code. That's all what I wanted to say. And the problem with RTE is that when Keil releases a new version, you are prompted to update your project with new release, but you can't update selectively - you have to update all modules that are changed. And for some modules (that are configurable), that will mean loss of old configuration, so you have to re-configure it all over again - including the fixes that you've just made.
And for those who care - I've posted a few fixes for RTE driver's bugs in the past when I found them, somehow they've disappeared - I guess, in the process of spam cleanup.
But it is a lack of commitment when we see so many who just do not want to open the datasheet for the processor.
It's one thing to write the complete code for USB communication and another to spend some time figuring out what the different processor pins are able to do.
And we constantly see people who aren't interested in looking at the documentation for the API of the source code packages they make use of. They expect that someone should supply them with a ready-glued solution making use of multiple packages and supplying exactly the functionality they need.
Anyone who wants to use a library - on PC or embedded platforms - must be prepared to read up on the library capabilities and how to make use of them. And anyone who wants to use a code package on embedded hardware must be prepared to figure out how to perform the mapping between code bundle and own hardware. In the embedded world, there are no "PC compatible" standard where someone else has decided on what pins or addresses different functionality should be mapped to.
It's a lack of commitment when people do not realize that debugging and testing are important parts of software development - the task doesn't end when the linker produced an output file without emitted errors.
You can very selectively update components with the RTE. See:
http://www.keil.com/support/man/docs/uv4/uv4_ca_swoptions.htm
Yes - you're right. I'll take my statement back.
it all comes back to the fact that downloaded code is worthless if you can't code it yourself. Too many just believe there is no need to know anything but Google.
But too many can't even use Google.
View all questions in Keil forum