giomba
/
nes-proj
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Merge pull request #202 from g-oikonomou/cc2538-minor-fixes 

CC2538 IEEE address location and documentation fixes
This commit is contained in:
Adam Dunkels 2013-04-17 07:48:57 -07:00
parent c99b62f628 704309cfd4
commit 424a7b2c8e
3 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
cpu/cc2538/dev/uart.h
View File

@ -66,8 +66,8 @@
#define UART_FBRD_115200 44 /**< FBRD value for baud rate 115200 */
#define UART_IBRD_230400 4 /**< IBRD value for baud rate 230400 */
#define UART_FBRD_230400 22 /**< FBRD value for baud rate 230400 */
#define UART_IBRD_460800 2 /**< IBRD value for baud rate 230400 */
#define UART_FBRD_460800 11 /**< FBRD value for baud rate 230400 */
#define UART_IBRD_460800 2 /**< IBRD value for baud rate 460800 */
#define UART_FBRD_460800 11 /**< FBRD value for baud rate 460800 */
#if UART_CONF_BAUD_RATE==115200
#define UART_CONF_IBRD UART_IBRD_115200

2
cpu/cc2538/ieee-addr.h
View File

@ -52,7 +52,7 @@
* \name IEEE address locations
* @{
*/
#define IEEE_ADDR_LOCATION_PRIMARY 0x00280020 /**< IEEE address location */
#define IEEE_ADDR_LOCATION_PRIMARY 0x00280028 /**< IEEE address location */
/** @} */
/*---------------------------------------------------------------------------*/
/*

4
platform/cc2538dk/README.md
View File

@ -257,12 +257,12 @@ Note: Some early production devices do not have am IEEE address written on the I
### Scripted multi-image builds
You can build multiple nodes with different `NODEID`s sequentially. The only platform file relying on the value of `NODEID` (or more accurately `IEEE_ADDR_NODE_ID`) is `ieee-addr.c`, which will get recompiled at each build invocation. As a result, the build system can be scripted to build you multiple firmware images, each one with a different MAC address. Bear in mind that, if you choose to do such scripting, you will need to make a copy of each firmware before invoking the next build, since each new image will overwrite the previous one. Thus, for example, you could do something like this:
You can build multiple nodes with different `NODEID`s sequentially. The only platform file relying on the value of `NODEID` (or more accurately `IEEE_ADDR_NODE_ID`) is `ieee-addr.c`, which will get recompiled at each build invocation. As a result, the build system can be scripted to build multiple firmware images, each one with a different MAC address. Bear in mind that, if you choose to do such scripting, you will need to make a copy of each firmware before invoking the next build, since each new image will overwrite the previous one. Thus, for example, you could do something like this:
for image in 1 2 3 4; do make cc2538-demo NODEID=$image && \
cp cc2538-demo.cc2538dk cc2538-demo-$image.cc2538dk; done
Which would build you `cc2538-demo-1.cc2538dk`, `cc2538-demo-2.cc2538dk` etc
Which would build `cc2538-demo-1.cc2538dk`, `cc2538-demo-2.cc2538dk` etc
As discussed above, only `ieee-addr.c` will get recompiled for every build. Thus, if you start relying on the value of `IEEE_ADDR_NODE_ID` in other code modules, this trick will not work off-the-shelf. In a scenario like that, you would have to modify your script to touch those code modules between every build. For instance, if you are using an imaginary `foo.c` which needs to see changes to `NODEID`, the script above could be modified like so: