3

I want to buy the book STM32 Arm Programming for Embedded Systems

The examples of this book are done with STM32F4 (ARM)

But I have a board which is STM32F103RB (ARM)

Does the code done for STM32F4 compile and execute as well as if I copy them for my STM32F103RB ?

Thank you for your help

Clifford
  • 88,407
  • 13
  • 85
  • 165
Dev
  • 463
  • 3
  • 12
  • 1
    There are no threads on StackOverflow, we have Q/A pairs. If you asked a question below another question better go and delete that one. It is otherwise bound to attract the wrong kind of attention. – Yunnosch Jul 25 '19 at 21:36
  • I followed your advise – Dev Jul 25 '19 at 21:39
  • 2
    Books are generally *not* a good resource to learn about embedded development, particularly in a practical hands-on sense. While the processor cores of the STM32F1 and STM32F4 do not differ much, those are not where the thought goes. Most of the practical effort that is platform specific concerns the on-chip peripherals, and those are actually quite different between the STM32F1 and STM32F4. So this is not likely to be a good course of action; you are better off just using a board with its matching archive of example software. All of these are available on $12 or so Nucleo/Discovery boards. – Chris Stratton Jul 26 '19 at 14:29
  • So, I decided to stick and come back to my STM32F103 RB with my MOOC at the moment to be focused on one thing and understand better how it works with principles of Keil... Thank you – Dev Jul 26 '19 at 14:44
  • 1
    There are some significant differences between the peripheral implementations between the STM32F1 and STM32F4 processors. The STM32F2 peripheral set is largely compatible like-for-like with those on most F4 parts. For a novice such differences may be confusing. The use of hardware abstractions such as CMSIS, STM32Cube, or Mbed go some way to mitigate this at the cost of deep understanding, but the book in question may not use these in any case. – Clifford Jul 27 '19 at 13:51
  • Given the low cost of the board in question, just get a new board perhaps? Although there are plenty of free resources for the chip you have - but you have only told us what chip is on the board, not what the board is - there are likely resources specific to your board too. – Clifford Jul 27 '19 at 13:52

1 Answers1

1

There are subtle differences between the STM32F4 and your STM32F1, and some code will not work 1:1 on both processors.

You should be able to find a cheap development board for the STM32F4 however, if you want to buy and follow the book.

This paper from ST describes migration from STM32F1 to STM32F4 and you should be able to learn the specific differences from that: https://www.st.com/content/ccc/resource/technical/document/application_note/group0/e9/c4/6b/99/4e/d3/4e/a0/DM00325582/files/DM00325582.pdf/jcr:content/translations/en.DM00325582.pdf

EDIT:

All platform independent C code should work the same on both platforms. I don't know the book, but if it is using some of the more advanced HW-features on the STM32F4, you may find that they are not present on the STM32F1 or work with other configurations.

Talking with sensors via I2C / SPI etc. should be pretty straight forward on both MCUs (microprocessors) though and I would expect the instructions in the book to be transferable from STM32F4 to STM32F1.

There are HW features that are only present on STM32F4, but for the most part, it's just the C support library that has a slightly different API. E.g. enum's are called something slightly different, or there are only one XXX-peripheral instead of two etc.

But since a development board for the STM32F4 costs ~10 dollars on eBay, I would advise you to just buy that one instead, if you want to feel more sure that you can follow the book 1:1.

Morten Jensen
  • 5,818
  • 3
  • 43
  • 55
  • So I understand I should be aware about that element. Thank you – Dev Jul 26 '19 at 07:11
  • 1
    @D.K. I have updated my answer and added a bit more nuance. Thank you for accepting my answer by the way :) – Morten Jensen Jul 26 '19 at 09:21
  • I appreciate your time. I reply to your update : I agree that it is better to have the bood board. In fact, I started to follow embedded C with a MOOC done for STM32F103 RB. that's why I bought that. And I think I will continue with this MOOC done with STM32F103RB before buying this book.... Another point : it seems that in the book of Michael Barr, you could introduce assembly code by doing asm{ .......................} but that code was not accepted on Kile MuVisiion 5. On my MOOC done for STM32F103RB, they use : __asm{ .......... }. should I understand that the other is obsolete ? – Dev Jul 26 '19 at 11:22
  • 1
    @D.K. Regarding the assembly code: The C standard doesn't say anything about how inline assembly instructions should be written. There are usually a few subtle differences between compilers, and the Keil-compiler may use a different format from GCC or whatever you were using previously. Sometimes it's `asm(xxx)` othertimes it's `asm { xxx }` etc. See this page regarding Keil inline asm: http://www.keil.com/support/man/docs/armcc/armcc_chr1359124246903.htm – Morten Jensen Jul 26 '19 at 11:26
  • 1
    Thank you that page is helpful. I realize that , despite I have good basis in C++ and C, I a discovering subtile things with embedded programming that can make the difference. And it reinforces my knowledge in C and C++. In particular, I did not practice too much the unions and bitwise operators. I feel that embedded programming is what makes the difference between an average C/C++ program and advanced programmer. It helps to understand what really happens. And I have lots of questions about that since long time about processors, microcontroller. I hope people will help me with kindness. – Dev Jul 26 '19 at 11:35
  • 1
    @D.K. I agree with you completely. Embedded programming is hardcore :) It has been some of the most challenging work I've done professionally, but also the most rewarding and instructive/educative – Morten Jensen Jul 26 '19 at 11:41
  • 1
    Actually the peripherals are quite substantially different between the STM32F1 and the STM32F4 – Chris Stratton Jul 26 '19 at 14:27
  • @ChrisStratton : please what do you mean by peripherials for STM32F... Do you mean for example hard disk, ear phone, bluetooth ? – Dev Jul 26 '19 at 14:56
  • 1
    No, the on-chip peripheral interfaces which allow you to usefully interact with the outside world. They, and not the CPU core, are where the majority of platform-unique attention will fall. – Chris Stratton Jul 26 '19 at 14:57
  • for example a LED ? – Dev Jul 26 '19 at 15:05
  • 1
    @D.K. more like UART, SPI, ADC etc. -- In my experiences the differences are small enough that you can port code from one to the other (usually, per the document) - but some HW is only available on one MCU – Morten Jensen Jul 26 '19 at 15:08
  • on this : https://fr.wikipedia.org/wiki/UART they explain that UART SP are protocols, so there are not hardwares ? – Dev Jul 27 '19 at 12:32
  • 1
    @D.K. UART and SPI are standardized communication protocols just like e.g. Ethernet, but are usually implemented in HW. You could also implement UART and SPI with general purpose IO, but when HW-speeds approach single or dual-digit MHz, they usually need specialized HW. Such HW-blocks are called peripherals. – Morten Jensen Jul 27 '19 at 13:19
  • 2
    The on-chip peripheral differences between F1 and F2 go right down to the GPIO level; the pin multiplexing, drive options, speed options etc. all differ. Nothing a comprehensive understanding of the data sheets, user manuals and app notes won't solve (which are probably larger than this proposed book), but from @D.K.'s questions, it seems that is not where he is at experience-wise. – Clifford Jul 27 '19 at 14:13
  • 1
    @D.K. `for example a LED?` - no, an LED is clearly not an on-chip peripheral, although your board may have a number of them, and you might add more. An LED is normally driven from a microcontroller GPIO pin, or possibly a PWM pin. Both GPIO and PWM are "peripheral" hardware in the microcontroller die, but not specifically part of the ARM core - they are microcontroller and manufacturer specific. – Clifford Jul 27 '19 at 14:21
  • 1
    @D.K. ... The reference manual for your part describes all the peripherals for the series and the data sheet describes the subset available on your specific part, as well as which pins the peripheral I/O can be mapped to on the specific part. These and other resources are available at https://www.st.com/en/microcontrollers-microprocessors/stm32f103rb.html#resource (for free - the book may not be needed, though probably assumes less prior technical knowledge - but that too is available elsewhere) – Clifford Jul 27 '19 at 14:23
  • Because an LED would be connected to a GPIO pin, and because the GPIO functional blocks are substantially different between the F1 and the F4, in effect, yes, code which toggles an LED would be drastically different between these boards, and porting it from one to the other would be almost as complicated as writing it from scratch. – Chris Stratton Jul 27 '19 at 18:05