Go Down

Topic: NilRTOS - A Fast Tiny Preemptive RTOS (Read 17 times) previous topic - next topic


Feb 02, 2013, 08:35 pm Last Edit: Feb 02, 2013, 09:19 pm by pito Reason: 1
Yes, hex is faster.. A little bit laborious when working with .csv afterwards. For example 2E6 in your above hex file example would be a pain to process in excel :)
I am thinking how to proceed with I2C. I have got 10DOF IMU (I2C) and want to log data from accelerometer, gyro, magnetometer, barometer and few ADC channels, ie. in 10ms period. Getting timestamps synced by RTC (I2C) and writing files with max length of 65k lines. And not loosing single data record..  ;)
Do we need an I2C driver for the NilRtos?


Hex is a pain.  I have logged in binary and converted the file to text with a second pass.

AnalogIsrLogger20121219.zip http://code.google.com/p/beta-lib/downloads/list works this way.  It can log 8-bit ADC samples on an Uno at up to 100 ksps.  you get about 7 effective bits.

I have a very fast small AVR I2C driver that I plan to include with Nil.  It is master only and much faster than Wire.  It doesn't use interrupts and would work well in a high priority thread.


Feb 03, 2013, 04:26 pm Last Edit: Feb 03, 2013, 06:52 pm by pito Reason: 1
It doesn't use interrupts and would work well in a high priority thread.

To get data from one sensor may take ~1.2msecs (@100kHz)..
Would such blocking driver be working with nil properly?

PS: I've tried to log the BMP085 bar sensor with current wire lib. Reading the pressure:
Code: [Select]
p->barpress = (uint32_t)bmp.readPressure();

takes 34.5ms @16MHz (inclusive a lot of integer math in it). So log periods >37ms work w/o an overrun.
I think I maybe need a thread where I read all the i2c sensors in a loop, lp smoothing data and updating them, as fast as possible. And the measuring thread will just copy the actual i2c sensors' data into the Record_t.


Feb 03, 2013, 07:48 pm Last Edit: Feb 04, 2013, 02:18 pm by fat16lib Reason: 1
I think an interrupt based driver would help at 100 kHz.

Writing an interrupt base I2C driver that sleeps may not be too hard.


I started looking at a general framework for I/O drivers on Nil.  It needs to accommodate device sharing.

It's likely more than one thread will want to use I2C or ADC channels.


Not sure if I ought to be starting a new thread, rather than continue with this old one - but here goes!

NilRTOS looks promising for my project. I've got it more or less working with SCoopME, but want to see if NilRTOS is better suited, and more compact.

I've noted in all the examples the warning:

"Loop is the idle thread. The idle thread must not invoke any kernel primitive able to change its state to not runnable"

I'm not sure what this means and its implications for my project! My existing code has functions that access an LCD, and functions accessing a few digital sensors.

What sort of functions do I need to look out for, please?


Go Up