I have a bizarre one here with the serial output when trying to write some code for my Arduino Uno.
I have this proto-code:
MyClass myclass;
void setup()
{
Serial.Begin(9600);
Serial.println("Starting...");
}
void loop()
{
int status = myclass.DoWork();
Serial.println("Status: " + status);
}
class MyClass
{
int DoWork()
{
Serial.println("Doing some work...");
return 1;
}
}
Now when this runs I get the following output:
Starting...
Doing some work...
atus: 1
So the strange part is the "Status: 1" missing the first few characters. Is this because I am using serial in an object improperly or something?
I have noticed when I reference another library that also uses serial like MyClass does that I get other strange output behavior... so I assume that I am doing something wrong.
EDIT: In the end this turned out to actually be a memory issue. A library I was including was quite large and it was consuming the available memory. I found this by adding a few more debugging statements and found the corruption shifted around based on the string lengths and positions. By using the F() function I moved the strings to flash memory (e.g. I now run Serial.println(F("Starting...")); and it has corrected the strange output.
You cannot add strings and integers in C++. It would have been better for you if this failed to compile:
Serial.println("Status: " + status);
Instead the compiler guessed at something. It guessed wrong. Use this:
Serial.print("Status :");
Serial.println(status);
or for complete control of outputting numbers and strings learn to use C string formatting, sprintf()
In the end this turned out to actually be a memory issue. A library I was including was quite large and it was consuming the available memory. I found this by adding a few more debugging statements and found the corruption shifted around based on the string lengths and positions. By using the F() function I moved the strings to flash memory (e.g. I now run Serial.println(F("Starting...")); and it has corrected the strange output.
One more possible explanation.
I was running minicom to monitor, and I usually like that it auto-reconnects after resetting my device.
Well I minimized a terminal running minicom last night, and today I started a new instance that somehow also got connected to the same serial port (if that is even possible).
I think the two instances of minicom were each reading ~50% of the serial characters roughly at random, leaving me with quite a mess of text.
Related
I'm experiencing a perculiar issue when using sprintf.
I need a char array to look like this: g;cmd;arg;e;, where arg gets leading zeros so it is always 3 chars long, and cmd gets leading zeros so it's always 15 chars long.
As an example, if cmd = 20 and arg = 3749, I need a char array looking like this: g;020;000000000003749;e;.
Both arg and cmd are integers.
I initially accomplished this in pretty inefficient way, but I changed it to something much simpler using sprintf because I needed my code to be faster. Both my initial code and my change can be found on github.
My current implementation looks like this:
#define cmdMsgLength 3
#define argMsgLength 15
#define totalFormatedMsgLength (2+cmdMsgLength+1+argMsgLength+3)
#define msgFormater "g;%03d;%015d;e;"
char msgToSendFormated[totalFormatedMsgLength];
void sendMsg(int _cmd, int _arg) {
sprintf(msgToSendFormated, msgFormater, _cmd, _arg);
Serial.print(msgToSendFormated);
}
This seemed to work well, until my uC also had to control 4 ESC's. I honestly can't find any relation between the two, but it seems like this implementation leads to problems with the ESC's, where of course timing is quite important. The ESC's are being programmed correctly, but when using the Arduino function servo.writeMicroseconds to actuate them, they seem to act randomly. After quite a lot of tests, only this change to my code seems to be causing the issue. As this piece code is so simple and the old code (check the github link) also used Serial.print, I assume sprintf is the culprit.
Is sprintf known to cause these sort of timing-issues? Could it be anything else?
As JVApen pointed out, sprintf always writes a null terminator. As msgToSendFormated was not long enough for that, I'd get an overflow. Setting char msgToSendFormated[totalFormatedMsgLength + 1]; fixed the problem.
I wrote a barebone progran template in XC8 (1.37) that I use to develop and test new GLCD functions for the 18F family. Programming is done via a PICkit3. Since I need to quicky reprogram several times the code it is really important that programming is faster as much as possible.
Tipically, the code size is around 2K and it takes less than 10 sec to program,
Everiything is fine until I must use a font table, defined as:
const char font8[] = {....
Now, with just $400 bytes added, the compiler place the table at the ROM's end and the programming of 64K memory takes more than 1 minute.
Is there any way to avoid this?
I tried to manually limit the memory range in the MPLABX options, but this is annoying and a little unsafe (sometimes part of code is truncated).
A while back I had to write some code for emissions testing, where I needed to copy data between extreme ends of RAM. To do that I needed to specify the exact memory addresses. You can also use the C extension __at() construct. http://ww1.microchip.com/downloads/en/DeviceDoc/50002053F.pdf#page=27
int scanMode __at(0x200);
const char keys[] __at(123) = { ’r’, ’s’, ’u’, ’d’};
int modify(int x) __at(0x1000) {
return x * 2 + 3;
}
Is it possible to put a sketch (.HEX file) to an SD card and run it from there?
My objective is to utilize SD storage instead of flash memory for a program.
If yes, are there any libraries doing exactly this?
All i found was "flashing arduino from sd card", which is not what i need.
UPDATE:
the sketch's loop calling is implemented in the bootloader.
so i assume there is something like this in the bootloader:
while(true)
{
call_sketch_loop();
}
can it be changed to this? :
//signature changed from void loop() to int loop()
while(true)
{
int retval = call_sketch_loop(); //get loop call's return value
if( 0 == retval )
continue; // if 0, iterate the loop as usual
else
{
//copy 1.HEX from sd to flash and reboot
copy_hex_from_sd_to_flash( retval + ".HEX" );
reboot();
}
}
change loop singature to int loop()
put {int}.HEX files to an SD card - 1.HEX , 2.HEX , 3.HEX
the loop() call returns 0
continue with next iteration as usual
the loop() call returns 2
copy file 2.HEX from SD card into program flash memory
reboot device
with this approach, we can run flash-capacity-exceeding programs if we split them up to smaller subprograms.
The technical term you are looking for is "SD card bootloader".
Have you looked into this: "https://github.com/thseiler/embedded/tree/master/avr/2boots"?
As far as I understand, 2boot will first load the hex into the flash and then execute it from there. This is not exactly what you are looking for (you want to load it directly to RAM, right?).
The problem with what you are looking for is that arduino's RAM is really small. And there is liittle advantage in loading directly to RAM. Therfore such library might not exist at all.
I can sugget a poor-mans approach for doing this. First write a sketch that contains a function that have an infinite loop inside it and inside this loop, put the code of your desired "loop". In the setup of the sketch take the pointer to this function and write sufficient ammount of bytes into a binary file on the SD card.
Then upload another sketch wich has an empty buffer. This sketch will load the binary file into it and refernce to it's beginning as a pointer to a function. Viola, you can now execute your "loop".
This is ugly and unless you have very specific and isoteric need for loading directly into RAM, I suggest to try the 2boot library.
I'm trying to get started with OpenCL but came across weird behavior of the OpenCL compiler with respect to white-space and can't seem to find any documentation about that.
C-style single-line comments (// foo) immediately cause a meaningless build error: At end of source: error: expected a "}". Multi-line comments (/* bar */) seem to work fine.
Line breaks seem to get stripped without adding whitespace which can cause errors. This example will not compile because of that:
__kernel
void TestKernel() {}
line 1: error: identifier "__kernelvoid" is undefined
This may totally depend on my machine and/or configuration but can somebody confirm that these things should not be this way?
I am using OpenCL via Cloo from .net/C#. The driver is from AMD OpenCL 2.0 AMD-APP (1642.5)
I think I figured it out. I was doing this:
var program = new ComputeProgram(context, File.ReadAllLines(filename));
File.ReadAllLines() returns an array of strings without the line-break characters which is the root of the errors I was getting.
Using File.ReadAllTest() instead fixed all the problems:
var program = new ComputeProgram(context, File.ReadAllText(filename));
But in my opinion some of the blame goes to either Cloo or the OpenCL API for accepting a string array but just concatenating it together..
I have been working on a project recently using a sensor for electrical conductivity in soil (A 5TE sensor from Decagon Devices) with my Arduino Uno. I am ready to code, and found this example code on GitHub (the example code is there when you scroll down the page). When trying to run it on the latest version of Arduino, it gave me these compilation errors:
sketch_dec15a:7: error: expected initializer before 'void'
sketch_dec15a:4: error: 'SDISerial' does not name a type
sketch_dec15a:9: error: expected initializer before 'void'
sketch_dec15a.ino: In function 'void loop()':
sketch_dec15a:22: error: 'connection' was not declared in this scope
NOTE: I believe I installed the library correctly, but am not 100% certain...more like 85%.
What's wrong with the code and how can it be made to work?
The example code is wrong. Look at the compilation errors. The first thing it says is:
sketch_dec15a:7: error: expected initializer before 'void'
So what it's saying is that it found something that said void and expected to see something else first. void occurs only twice in your code, so we can't be far. Let's take a look at the code immediately surrounding it the first void:
char tmp_buffer[4];
char sensor_info[]
//initialize variables
void setup(){
connection.begin();
Serial.begin(9600);//so we can print to standard uart
//small delay to let the sensor do its startup stuff
delay(3000);//3 seconds should be more than enough
}
Right before the void setup(){ is //initialize variables. That's just a comment, and not code, so it doesn't relly count. Looking back one more line we see:
char sensor_info[]
Something is wrong with that line. Work on it and see if you can figure it out (check the other lines for "hints"). If you can't figure it out, the answer is right below (put your mouse over it to see it):
It needs a semicolon ";" at the end to complete the statement. Because the semicolon is missing, it thinks "void setup(){" is part of the previous statement.