deac/osd-contiki
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

CC2538 Documentation typo and grammar fixes

Browse source
This commit is contained in:
George Oikonomou 2013-04-16 16:28:23 +01:00
parent c99b62f628
commit 8b5b2bd4d8
2 changed files with 4 additions and 4 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

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: