iainism
Member
I may be missing the point here, but can't you 'just' create a header file for each hardware configuration? i.e.
/pathTo/RET6/hwSpecific.h
-----------------
#define MyPin 3
#define otherRet6Stuff
/eof
/pathTo/mini/hwSpecific.h
-----------------
#define MyPin 5
#define otherMiniStuff
/eof
main.c then has "#include <hwSpecific.h>" with the include path being varied between /pathTo/mini/ and /pathTo/RET6/ as required by setting up the makefile (or command line, but seriously, use a makefile) appropriately.
In the libmaple boards.h file you find
#ifdef BOARD_maple
#include "maple.h"
#elif defined(BOARD_maple_native)
#include "maple_native.h"
#elif defined(BOARD_maple_mini)
#include "maple_mini.h"
#elif defined(BOARD_maple_RET6)Check if these defines also work in your main code.
@ala42 - thanks very much, this appears to work.
@iainism - the point is to be able to compile the same project for different boards without having to change anything other that the make command line (or the BOARD environment variable). I had been doing something similar to what you suggest, but this required me to change two things every time I switch boards. I can't tell you how many times I'd forget to change the pin defs and got some seriously weird (and time consuming to troubleshoot) symptoms as a result.
tlgosser
Member
/*
It is also possible to write a permanent identifier to flash memory for each board - a number that stays in memory even when you load a new program. This way you can write code for ALL of your boards in one program! But only run one set of instructions. I find this makes things dramatically simpler.
To write an identifier you will need to put this eeprom lib in your 'libraries' folder:
http://akb77.com/g/stm32/maple-eeprom-emulation-library/
*/
//Program to write a permanent 'label' on your board:
#include <EEPROM.h>
uint16 DataWrite = 9;//lets just say this is board no. 9
uint16 AddressWrite = 0x10;
void setup(void){
EEPROM.write(AddressWrite, DataWrite);
}
void loop(void){}
tlgosser
Member
//To read your board's 'label':
#include <EEPROM.h>
uint16 AddressWrite = 0x10;
uint16 DataRead = 0;
void setup(void){
EEPROM.read(AddressWrite, &DataRead);
}
void loop(void){
delay(3000);//let the serial monitor wake up
SerialUSB.print("Confirmed. Board No.: ");
SerialUSB.println(DataRead, HEX);
}
tlgosser
Member
I've never heard of this. So the option bytes are here... 0x1FFF F800 -0x1FFF F80F.
EEPROM.h makes us erase and program an entire flash page in order to write data. Although we can read words anywhere.
Is it just those 2 bytes that are available for user data?
How would you write to just those two bytes?
gbulmer
Moderator
tlgosser - "So the option bytes are here... 0x1FFF F800 -0x1FFF F80F."
Yes, the "Option Bytes" are 16 bytes in the "Information block".
They are described in PM0075 "Programming manual", "STM32F10xxx Flash memory microcontrollers":
http://www.st.com/web/en/resource/technical/document/programming_manual/CD00283419.pdf
The option bytes are described in Table 9. "Description of the option bytes" on page 20.
They are rather obscure. Using them is mentioned in RM0008 (search for "option bytes") but I don't think that explains what they are, or how to program them. For example, they are mentioned as containing nRST_STDBY and nRST_STOP. The most helpful statement is "For further information on the User Option Bytes, refer to the STM32F10xxx Flash programming manual."
"Is it just those 2 bytes that are available for user data?"
Yes, AFAIK. Other bytes control write protection of Flash memory, configure the watchdog timer, and how stop and standby work.
"How would you write to just those two bytes?"
Section 2.3.5 "Option byte programming" describes the process, which is basically the same as programming Flash memory, except their is an extra bit (OPTPG bit in the FLASH_CR) which must be set.
tlgosser - Hiding a board definition value somewhere in flash would probably work fine for a small project but I don't think it would scale well for a larger program as this is a significant trade off of a one time decision during compilation versus many bazillions of run time decisions. Also the program would have to carry all of the code for all of the boards it might need to run on, whereas the former only compiles what's needed for the specific target.
gbulmer - thank you for the info on the option bytes - definitely an interesting tidbit.
You must log in to post.