Created Mon, 30 Apr 2012 00:25:40 +0000 by ricklon
Mon, 30 Apr 2012 00:25:40 +0000
Hi All, I'm vey glad to get some new builds up here. This includes the latest newlib updates from Jason.
Latest status: https://github.com/chipKIT32/chipKIT32-MAX/issues?page=1&state=closed
Linux32 https://github.com/downloads/chipKIT32/chipKIT-builds/mpide-0023-linux32-20120429-test.tgz
Mac OS X https://github.com/downloads/chipKIT32/chipKIT-builds/mpide-0023-macosx-20120429-test.dmg
Windows https://github.com/downloads/chipKIT32/chipKIT-builds/mpide-0023-windows-20120429-test.zip
-_Rick
Mon, 30 Apr 2012 06:21:44 +0000
Thats great! Some of the changes in the compiler and Newlib libc are:
Sun, 06 May 2012 23:12:12 +0000
Hi there!
Just wanted to say that SD card loading works A LOT better in this release! Thanks!
Tue, 08 May 2012 05:30:58 +0000
So is newlib just an experiment, or is it the future of ChipKit?
Tue, 08 May 2012 06:15:12 +0000
Newlib is intended to be the future of the chipKIT compiler.
Sat, 12 May 2012 01:15:27 +0000
Hello again -
I found a bug (and the solution) in the latest SD card library.
It might have been reported before - but is still present.
In the file "Sd2Card.cpp" , on rows 380 and 403 it says "n = count - 1;" and " while (offset_++ < 514) spiRec();" respectively.
These should be changed to read:
n = count; and while (offset_++ < 512) spiRec();
Without these changes the last byte in each block will never be read... If only the n = count is changed, the performance will drop until 514 -> 512 bytes (its' probably error checking/double loading) .
So - I thought my bitpacking routine was faulty, but it turns out to be the library. It looked like it worked when I loaded an unpacked image, but the error was always there - just masked better.
Hope this helps anyone!
Fri, 18 May 2012 09:38:57 +0000
you can change the loop and then use it with the take other condition in the loop.
Tue, 22 May 2012 00:14:45 +0000
ok, here's something i ran across, I'd be curious if anyone can confirm it,
the following code is supposed to calculate the running average.
When i compile it under Mpide 0023 20111221 it works fine, But when i compile it under Mpide 0023 20120429-windows-test, it has many Errors i will say the errors do seem to be valid,
any ideas?
const int numReadings = 20;// how many readings do we want to average
float readings[numReadings]; // the readings from the analog input
int index = 0; // the index of the current reading
float total = 0; // the running total
int averageS = 0;
void setup(){
}
void loop(){
running_average();
}
void running_average (){
total= total - readings[index]; // subtract the last reading:
readings[index] = analogRead(0); // read from the sensor:
total= total + readings[index]; // add the reading to the total:
index = index + 1;// advance to the next position in the array:
if (index >= numReadings) // if we're at the end of the array...
index = 0; // ...wrap around to the beginning:
averageS = total / numReadings; // calculate the average:
}
Philip
Thu, 31 May 2012 10:56:16 +0000
This version seems to have fixed the milis() issue I had with the November release. Thank you.
@hdphillip, I am not sure what might be happening with your code, but you should consider using a filter rather than an average. A filter can be done on 2 samples at a time.
Here is a link that may help: [url]http://www.automationdirect.com/static/manuals/d4user/ch8.pdf[/url] This covers PID loops, but at the end it describes a digital filter. Remember like a loop it must be run at a specific interval to maintain frequency response. This means it is best to have the processed samples at a deterministic rate. Here is the equation they use for the filter in case the PLC code is harder to decipher: (newsample - prevresult) * 0.2 + prevresult = prevresult
The 0.2 value is the filter value. The lower the value the increased number of samples to change a value. So the 0.2 is kind of like increasing the number of points in an average. As you can see you are only doing 1 multiplication, 1 subtraction, and 1 addition.
Now this is a low pass filter. It will tend to pass lower frequencies. Now you can change that operation by doing this: This equation is wrong: maxvalue - ((newsample - prevresult) * 0.2 + prevresult) = prevresult Try this. It gives more weight to a rapidly changing signal: ((prevresult - newsample) * 0.2 + newsample) = prevresult
This will tend to pass higher frequencies. Combine these is different ways and you can create notch filters and band pass filters. Just make sure you are doing this at a deterministic rate (same time between calculations).
Have fun.