I'm using an Arduino platform with the Asynclabs library (an open-source wifi library for old yellowjacket and redback wifi boards).
Something is breaking the Arduino String object (note the capital S).
I'm using just a simple test:
Serial.println("Test Strings:\n");
String junk = "Do Strings print or what?";
Serial.println(junk);
while (1) { delay(2000); Serial.print("+");}
This prints as you'd expect at the start of my setup() block. When I move it to after the wifi.init() call, it still works. But when I move it after a call to a short network interaction, it is ignored as if it isn't there. No output is generated other than the first print w/o the String object.
Everything compiles okay - I'd have hoped the compiler would've told me if I had library collisions.
I grep'd thru the library files for other uses of the word 'String' and 'string' but have seen nothing much there. I renamed a file called strings.c to canned_strings.c. Still no improvement.
I'm at a bit of a loss. Any sugg of other things to look for?
[One note - I see several of the library files are including <string.h> - is this a deprecated Arduino lib file that should be switched to something else? Investigating... ]
-Ross
Ultimately it was clear that the String object is way too RAM intensive for the compact resources of the Arduino.
I got around the problem by eliminating all use of the String type from the code, and using char arrays with lots of pointers. This was much more RAM friendly.
[Also - in the Asynclabs Wifi library, it was helpful to reduce the size of the packet, to further free up some RAM. Highly recommended strategy to make any progress.]
Related
I work on the Aurix microcontroller on eclipse
i need to display unsigned char values on the console,
I did like that
printf ("% hhx", tab [j]);
but I had this error:
error: AppKit_TC277TFT_TimeDemo.elf section `.inttab' will not fit in
region `PMI_PSPR'
error: region `PMI_PSPR' overflowed by 16788 bytes
Is there anyone who could help me
Searching for PMI_PSPR Aurix in a well-known search service brings up this forum post.
Apparently you are linking your code to run from RAM. Change the linker settings to link it to flash, and run from there.
First try to isolate what is the cause. Two thoughts are:
Check if the stdout stream works.
Check if a memory issue (as the error suggests).
1. stdout check:
Try using the stdout stream without using printf formatter. The formatter is bloated as people suggest and generally not a good idea on embedded systems. Also have you setup where the stdout stream goes (is it mapped to some UART code, normally on embedded systems you need to write or configure this)? Test by using putch('.'), putchar('.') or even puts("Hello").
2. memory check:
Try building the code that uses sprintf() by itself without stdout. If that doesn't build either then it is likely the formatter. Some embedded compilers allow configuring the formatter library as smaller options to get around this issue (doesn't support the full implementation).
Use printf in embedded c
One way is to use UART communication.
Convert numeric value to printable ascii form and send to UART so that one may see on console.
For simple applications you may consider storing printable characters to some array buffer and at the end of activity print the array buffer to UART
I am trying to generate an incrementing value at load time to be used to "serialize" a PCB with a unique code value. Not an expert in ld or preprocessor commands, so looking for some help.
The value will be used in a unique ID for each board that the code is loaded on and will also be used as a counter for boards in the field.
I have no preconceived idea of how I might accomplish this, so any workable answer to get me started, including a pre-preprocessor macro is fine. In my olden days, I recollect adding a couple lines to the linker file that would accomplish this, but I have been unable to resurrect that information anywhere (including my brain's memory cells).
The simpler the answer, the better.
My solution to the problem was remarkably simple.
The binary contained
const char *serial = "XY-00000";
I then wrote a short program that boiled down to:
char uniqueserial [8];
/* Generate serial - this was an SQL call to the manufacturing DB */
char *array;
/* Read binary into array */
memcpy(memmem(array, "XY-00000",8), uniqueserial,8);
/* Write array to temp bin file for flashing */
Depends on the serial template string being unique in the binary. Use strings command to check. I disable crc protected object files due to taste. I like my embedded binaries being exact memory dumps.
The linker is not the right place for two reasons:
the executable can be loaded with the same id in several devices, making your approach void.
You should have to link the executable for each device you are programming, which poses an spent of cpu resources.
The best place is to patch the executable at loading time with the serial number.
Select a data patern as token to initialize your variable with the device id (a pattern difficult to happen elsewhere in your program binary) and initialize your serial number variable to that data pattern (better if you do it statically initializing an array variable or something similar)
Make a program to be executed on each download to device that search for the pattern in the executable file, before loading the binary program into the device and writes the correct value to be programmed into the device (beware that you are patching a binary, so you cannot think on variable lenght strings or the like, that can trash all the work made by the linker)
Once patched the binary executable, you can download it to the device.
Another solution is to reserve a fixed area in your linker script for all this kind of information. Then, put all your device information variables there. Then get the exact positions in rom for the individual variables and include the proper data in the loaded image. In this case, the linker is your friend, reserving some fixed segment in your device's rom allocated for storing the device's individual data (you can put there mac addresses, serial numbers, default configuration, etc.)
I am trying to read the MCU_ID (device electronic signature) from STM32L476 chip using a JTAG ST-Link/V2 on Windows 7. No code has to be uploaded inside the chip, the program shall just be launched on my cumputer and read this information from the flash memory.
I have managed to find and extract the following screenshot from the Reference Manuel given on ST website :
So I have to read the value stored in the flash memory at the adess 0x1FFF7590 by using a C program. I am using the Atollic TrueStudio IDE which is recommended by ST itself, but it seems to me that it includes the "stm32l476xx.h"library which does not even contain any function which could help me.
What I have done so far
After spending days and days looking for some functions or examples to do something as simple as read flash memory, I have asked on this very site How to interact with a STM32 chip memory, which helped me understand a couple of things about what I had to do; nevertheless, I haven't been able to find what I was looking for even after days reading all the links and docs advised in the comments.
I have asked a couple of professionals who told me that I should search for a JTAG driver to interact with the flash memory, but it seems a bit complicated and I haven't been able to found any.
Someone on this site told me that simply using pointer should be enough; the lack of C example and internet tutorials couldn't help me figure out how to do so.
Finally, I started recently digging around STM32Cube and HAL, even since I wanted to avoid using those because I thought that a simple read could be done without having to include those layers. Asking this question is my final hope before trying to use them.
In Conclusion :
I can't show any code since the only thing I have so far is a #include "stm32l476xx.h"and an empty main.
A hint or solution on How to read a STM32L476's flash memory in C would be just perfect. Every example of C (or any programming language which would be as low or higher level) program or instructions interacting with a STM32 chip's memory could help me a lot since it is very hard to find on internet.
Reading MCU ID using ST-Link (graphical interface)
You can use ST-Link Utility (can be downloaded from ST.com here: http://www.st.com/en/embedded-software/stsw-link004.html). After you do Target->Connect you can specify the address and number of bytes you want to read on top of the Window. This also works for the memory area where MCU ID is defined.
For STM32L476 MCU that you use it's going to be memory address 0x1FFF7590, size 0xC (96 bits). Pressing enter should allow you to see the unique ID read from the MCU you're connected to, in form of 3x32 bit values.
Reading MCU ID using ST-Link (command line interface)
ST-Link Utility provides CLI (command line interface) to do the most common operations. This is done using ST-LINK_CLI.exe located in your ST-Link Utility installation directory.
Reading Unique ID as 32-bit values (STM32L476 MCU from the example):
ST-LINK_CLI.exe -r32 0x1FFF7590 0xC
Reading as 8-bit values:
ST-LINK_CLI.exe -r8 0x1FFF7590 0xC
You can also read it to file using -Dump parameter:
ST-LINK_CLI.exe -Dump 0x1FFF7590 0xC D:\temp\out.bin
Keep in mind that you must have the priviledges to write to the destination directory. If you don't run the command prompt with administrative priviledges, in most common cases this means that you won't be able to create the file in locations such as root drive directory (C:\out.bin) or inside "Program Files", where most likely your program is installed (for example by specifying a relative path, such as giving an output file name only out.bin). The program sadly doesn't inform about failed attempts to write the file, however it does say when it succeeds to create the file. The program execution should end with a green line saying Dumping memory to D:\temp\out.bin succeded. In addition, keep in mind that only the following file extensions are supported: *.bin *.hex *.srec *.s19. It cannot be anything because the extension determines the format in which the data will be written to the file.
You can find more information about CLI parameters in User Manual UM0892.
Reading MCU ID using C code
The same can be done using a program loaded into the MCU. You read it by simply accessing the memory directly. Sample code:
#define STM32_UNIQUEID_ADDR 0x1FFF7590
uint32_t id[3];
id[0] = *(STM32_UNIQUEID_ADDR + 0);
id[1] = *(STM32_UNIQUEID_ADDR + 1);
id[2] = *(STM32_UNIQUEID_ADDR + 2);
After this operation id array should contain the same 3x32bit values you've previously read using ST-Link Utility. You may of course choose to read it as uint8_t byte array of size 12, you may even choose to read it into a struct, in case you're interested in the details (lot number, wafer number etc.). This example should however give you a general idea of how to access this value.
There is Texane stlink, that does what you want. It's written in C, interacts with STM32 chips through an ST-Link adapter, and it can read from chip memory.
What you are looking for is not a feature of ST but a feature of ARM.
Remember, ST simply uses an ARM core. I know most programmers load some code in RAM and use that to access flash. You can find these simple programs in the install directory or Keil for example.
I think this is the manual you will need. But I don't know if there is more information behind the login-wall.
At work we have an Arduino sketch that gets changed periodically. In a nutshell, it communicates back and forth on a Serial port. For the most part our software development team controls the code; however, there are some other teams at our company that periodically make last minute changes to the sketch in order to accommodate specific client needs.
This has obviously been quite problematic because it means we might have different versions of our sketch deployed in different places without realizing it. Our software developers are very good at using source control but the other teams are not quite so disciplined.
One idea that was proposed was hard-coding a version number, so that a certain serial command would respond by reporting back the predefined version number. The trouble however is that our other teams might likewise fail to have the discipline to update the version number if they decide to make other changes.
Obviously the best solution involves cutting off the other team from making updates, but assuming that isn't possible for office politics reasons, I was wondering if there's any way to programmatically "reflect" on an Arduino sketch. Obviously a sketch is going to take up a certain number of bytes, and that sketch file is going to have a unique file hash. I was thinking if there was some way to either get the byte count, the file hash, or the last modified time as a preprocessor directive that can be injected into code that would be ideal. Something like this:
// pseudocode
const String SKETCH_FILE_HASH = #filehash;
const int SKETCH_FILE_SIZE = #filesize;
const int SKETCH_LAST_UPDATED = #modified;
But that's about as far as my knowledge goes with this. Is there any way to write custom preprocessor directives, or macros, for Arduino code? Specifically ones that can examine the sketch file itself? Is that even possible? Or is there some way that already exists to programmatically track changes in one way or another?
Risking an answer.
SKETCH_FILE_HASH : you would have to precompute externally and pass as a flag. I guess you're using the arduino IDE and this is not doable
SKETCH_FILE_SIZE: same answer
SKETCH_LAST_UPDATED: You can use __TIME__ to get a string containing compilation time.
What I would do, taking into account the polititc parts.
enmbed a keyword linked to your version control (e.g. svn:id for subversion, almost all VCS provide this)
embed compilation time
change the official build (the one the SW team controls) to use the actual toolchain and not the IDE and put it on a jenkins : you'll be able to use compilation flags!
embed a code like
#ifndef BUILD_TYPE
#define BUILD_TYPE "Unsupported"
#endif
On your continuous build process, use -DBUILD_TYPE="HEAD" or "Release"
I'm sorry I don't see a magicx wand solving your solution. I'd invest a lot into training on why version control can save you (seems you already have the war stories)
I was looking at this issue myself, and found this:
https://gist.github.com/jcw/1985789#file-bootcheck-ino
This is to look up the bootloader; but I'm thinking that something like this could be used for determining a signature of some sort for the code as a whole.
I did a quick experiment, where I added something like:
Serial.print("Other...");
Serial.println(CalculateChecksum(0, 2048));
in void setup(), and was able to get different values for the CRC, based on changing a tiny bit of code (a string).
This is not an explicit solution; I tried CalculateChecksum(0, 32767), and so on, and if I defined an integer like int a=101; and changed it to int a=102; the checksum was the same. Only when I changed a string (i.e., add a space) did this value change.
I'm not crystal clear on the way memory is allocated in the Arduino; I do know there is program memory (32,256 bytes) and global variable memory (2048 bytes), so I'm sure there is some way of doing this.
In another experiment, I used the pgm_read_byte() function, and if I create a simple memory dump function:
void MemoryDump (word addr, word size) {
word dataval = ~0;
// prog_uint8_t* p = (prog_uint8_t*) addr;
uint8_t* p = (uint8_t*) addr;
for (word i = 0; i < size; ++i)
{
dataval = pgm_read_byte(p++);
Serial.print(i);
Serial.print(" ->");
Serial.print(dataval,HEX);
Serial.print(" ");
Serial.print(dataval);
Serial.print(" ");
if(dataval>32)
{
Serial.print(char(dataval));
}
else
{
Serial.print("***");
}
Serial.print("\n");
}
}
... and I put in a line like:
Serial.println(F("12345fghijklmnopqrstuvwxyz"));
because the F() puts the string in program memory, you will see it there.
Reading the SRAM is a bit of an issue, as noted here:
http://forum.arduino.cc/index.php?topic=220125.0
I'm not a compiler god, so I don't know how stuff like a=101; looks to the compiler/IDE, or why this doesn't look different to the program memory area.
One last note:
http://playground.arduino.cc/Code/AvailableMemory
Those functions access SRAM, so perhaps, with a bit of tweaking, you could do a CRC on that memory, but it would seem a bit of an issue, since you have to be doing a computation with a variable... in SRAM! But if the code was identical, even if doing a computation like that, it might be possible. Again, I'm in deep water here, so if an AVR god has issue with this, please destroy this theory with an ugly fact!
I'd like to interpret a command string, recieved by a microcontroller (PIC16f877A if that makes any difference) via serial.
The strings have a pretty simple and straight-foward formatting:
$AABBCCDDEE (5 "blocks" of 2 chracters+'$' for 11 characters in total) where:
$AA= the actual name of the command (could be letters, numbers, both; mandatory);
BB-EE= parameters (numbers; optional);
I'd like to write the code in C/C++.
I figure I could just grab the string via serial, hack it up into blocks, switch () {case} and memcmp the command block ($AA). Then I could have a binary decision tree to make use of the BB CC DD and EE blocks.
I'd like to know if that's the right way to do it (It kinda seems ugly to me, surely there must be a less tedious way to do this!).
Don't over design it ! It does not mean to go blindly coding, but once you have designed something that looks like it can do the job, you can start to implement it. Implementation will give you feedback about your architecture.
For example, when writing your switch case, you might see yourself rewriting code very similar to the one you just wrote for the preceding case. Actually writing down an algorithm will help you see some problem you did not think off, or some simplification you did not see.
Don't aim for the best code on the first try. Aim for
easy to read
easy to debug
Take litlle steps. You do not have to implement the whole thing in one go.
Grab the string from the serial port. Looks easy, right ? Well, let's do that first, just printing out the commands.
Separate the command from the parameters.
Extract the parameters. Will the extraction be the same for each command ? Can you design a data structure valid for every command ?
Once you have done it right, you can start to think of a better solution.
ASCII interfaces are ugly by definition. Ideally you have some sort of frame structure, which maybe you have, the $ indicates the division between frames and you say they are 11 characters in length. If always 11 that is good, if only sometimes that is harder, hopefully there is a $ at the start and 0x0A and or 0x0D/0x0A at the end (CR/LF). Normally I have one module of code that simply extracts bytes from the serial port and puts them into a (circular) buffer. The buffering dating to the days when serial ports had very little of no buffer on board, but even today, esp with microcontrollers, that is still the case. Then another module of code that monitors the buffer searching for frames. Ideally this buffer is big enough to leave the frame there and have room for the next frame and not require another buffer for keeping copies of the frames received. using the circular buffer this second module can move (discarding if necessary as it goes) the head pointer to the beginning of frame marker and waits for a full frames worth of data. Once a full frame appears to be there it calls another function that processes that frame. That function may be the one you are asking about. And "just code it" may be the answer, you are in a microcontroller, so you cant use lazy high level desktop application on an operating system solutions. You will need some sort of strcmp function if created yourself or available to you through a library, or not depending on your solution. The brute force if(strncmp(&frame[1],"bob",3)==0) then, else if(strncmp(&frame[1],"ted",3) then, else if... Certainly works but you may chew up your rom with that kind of thing, or not. And the buffering required for this kind of approach can chew up a lot of ram. This aproach is very readable and maintainable, and portable though. May not be fast (maintainable normally conflicts with reliable and/or performance), but that may not be a concern, so long as you can process this one before the next one comes along, and or before unprocessed data falls out of the circular buffer. Depending on the task the frame checker routine may simply check that the frame is good, I normally put start and end markers, length and some sort of arithmetic checksum and if it is a bad frame it is discarded, this saves on a lot of code checking for bad/corrupt data. When the frame processing routine returns to the search for frame routine it moves the head pointer to purge the frame as it is no longer needed, good frame or bad. The frame checker may only validate a frame and hand it off to yet another function that does the parsing. Each lego block in this arrangement has a very simple task, and operates on the assumption that the lego block below it has performed its task properly. Modular, object oriented, whatever term you want to use makes the design, coding, maintenance, debugging much easier. (at the cost of peformance and resources). This approach works well for any serial type stream be it serial port in a microcontroller (with enough resources) as well as applications on a desktop looking at serial data from a serial port or TCP data which is also serial and NOT frame oriented.
if your micro doesnt have the resources for all that, then the state machine approach also works quite well. Each byte that arrives ticks the state machine one state. Start with idle waiting for the first byte, is the first byte a $? no discard it and go back to idle. if first byte is a $ then go to the next state. If you were looking for say the commands "and", "add", "or", and "xor", then the second state would compare with "a","o", and "x", if none of these then go to idle. if an a then go to a state that compares for n and d, if an o then go to a state that looks for the r. If the look for the r in or state does not see the r then go to idle, if it does then process the command and then go to idle. The code is readable in the sense that you can look at the state machine and see the words a,n,d, a,d,d, o,r, x,o,r, and where they ultimately lead to, but generally not considered readable code. This approach uses very little ram, leans on the rom a bit more but overall could use the least amount of rom as well compared to other parsing approaches. And here again is very portable, beyond microcontrollers, but outside a microcontroller folks might think you are insane with this kind of code (well not if this were verilog or vhdl of course). This approach is harder to maintain, harder to read, but is very fast and reliable and uses the least amount of resources.
To matter what approach once the command is interpreted you have to insure you can perform the command without losing any bytes on the serial port, either through deterministic performance of the code or interrupts or whatever.
Bottom line ascii interfaces are always ugly, the code for them, no matter how many layers of libraries you use to make the job easier, the resulting instructions that get executed are ugly. And one size fits no-one by definition. Just start coding, try a state machine and try the if-then-else-strncmp, and optimizations in between. You should see quickly which one performs best both with your coding style, the tools/processor, and the problem being solved.
It depends on how fancy you want to get, how many different commands there are, and whether new commands are likely to be frequently added.
You could create a data structure that associates each valid command string with a corresponding function pointer - a sorted list accessed with bsearch() is probably fine, although a hash table is an alternative which may have better performance (since the set of valid commands is known beforehand, you could construct a perfect hash with a tool like gperf).
The bsearch() approach might look something like this:
void func_aa(char args[11]);
void func_cc(char args[11]);
void func_xy(char args[11]);
struct command {
char *name;
void (*cmd_func)(char args[11]);
} command_tbl[] = {
{ "AA", func_aa },
{ "CC", func_cc },
{ "XY", func_xy }
};
#define N_CMDS (sizeof command_tbl / sizeof command_tbl[0])
static int comp_cmd(const void *c1, const void *c2)
{
const struct command *cmd1 = c1, *cmd2 = c2;
return memcmp(cmd1->name, cmd2->name, 2);
}
static struct command *get_cmd(char *name)
{
struct command target = { name, NULL };
return bsearch(&target, command_tbl, N_CMDS, sizeof command_tbl[0], comp_cmd);
}
Then if you have command_str pointing to a string from the serial port, you'd do this to dispatch the right function:
struct command *cmd = get_cmd(command_str + 1);
if (cmd)
cmd->cmd_func(command_str);
Don't know if you're still working on this. But I'm working on a similar project and found an embedded command line interpreter http://sourceforge.net/projects/ecli/?source=recommended. That's right, they had embedded applications in mind .
The cli_engine function really helps in taking the inputs from your command line.
Warning: there is no documentation besides a readme file. I'm still working through some bugs integrating the framework but this definitely gave me a head start. You'll have to deal with comparing the strings (i.e. using strcmp) yourself.