chipKIT® Development Platform

Inspired by Arduino™

New newlib test builds available 20120429

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:


Mac OS X




Mon, 30 Apr 2012 06:21:44 +0000

Thats great! Some of the changes in the compiler and Newlib libc are:

  • Addressed a problem with floating-point conversions (%f) in formatted IO functions such as sprintf
  • Reduced the size of the stdout and stdin buffers in order to reduce data-memory usage
  • Reduced the malloc page size in order to reduce the heap size requirements and better tune the algorithm for small-memory devices
  • Added (compiler-only) support for the PIC32MX1 and MX2 families. Support for the Arduino/chipKIT core and libraries will be coming soon.


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(){ 
  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 &gt;= numReadings)   // if we're at the end of the array...           
        index = 0;    // ...wrap around to the beginning:                        
  averageS = total / numReadings;  // calculate the average: 




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][/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.