The Netduino forums have been replaced by new forums at community.wildernesslabs.co.
This site has been preserved for archival purposes only
and the ability to make new accounts or posts has been turned off.
Hi,
I'm working on a project that will allow to control RGB LEDs using Netduino. I planned to use the TI TLC5940NT LED driver chip that has 16 channels with 12-bit PWM, and is quite popular with Arduino. Here are some resources for anyone interested: Arduino library Demystifying the TLC5940 ebook
I started writing the .NET MF driver for this chip with a reference implementation as described in the above ebook. However the pure managed code is too slow to drive chip's clock signals. So the next step is to use the hardware functions.
This chip uses SPI to receive the grayscale values from microcontroler, and moving this to hardware SPI was easy. However this chip also requires a clock signal for PWM outputs. Whats more the new SPI values should be latched preciesly at the end of each PWM cycle, that is every 4096 clock sygnals.
Now the Arduino library uses the hardware timer counter with interrupt to achieve this. Here is the corresponding code to set this (from the "Demystifying the TLC5940" ebook):
// CTC with OCR0A as TOP
TCCR0A = (1 << WGM01);
// clk_io/1024 (From prescaler)
TCCR0B = ((1 << CS02) | (1 << CS00));
// Generate an interrupt every 4096 clock cycles
OCR0A = 3;
// Enable Timer/Counter0 Compare Match A interrupt
TIMSK0 |= (1 << OCIE0A);
Would something similar be possible on Netduino? I admit I got stuck on this so all suggestions how to best convert this to .NET MF would be welcome :-)
That should be possible, but it's probably something that would require native C++ drivers (much like the Arduino uses direct interrupt control).
This brings up a good question: should we expose a standard C# class which lets you read/write processor registers directly?
Chris
That should be possible, but it's probably something that would require native C++ drivers (much like the Arduino uses direct interrupt control).
This brings up a good question: should we expose a standard C# class which lets you read/write processor registers directly?
Chris
This should really be a firmware extension. If you have the knowledge to write the registers correctly then you can extend the firmware.
This is much simpler then the port of the CLR since all it really needs is a managed class for the .NET side with the stubs produced for the native functions.
All the nasty driver work and HAL/PAL work just isn't needed here. That just gets compiled in as a black box. As a reference point, how many people actually know how the c-runtime gets started up when they run a program they wrote in C?
The rest of the firmware just gets treated the same way, as kind of a c-runtime, for most people.
So perhaps what we really need is a simple sample that shows how to do this.
This should really be a firmware extension. If you have the knowledge to write the registers correctly then you can extend the firmware.
This is much simpler then the port of the CLR since all it really needs is a managed class for the .NET side with the stubs produced for the native functions.
All the nasty driver work and HAL/PAL work just isn't needed here. That just gets compiled in as a black box. As a reference point, how many people actually know how the c-runtime gets started up when they run a program they wrote in C?
The rest of the firmware just gets treated the same way, as kind of a c-runtime, for most people.
So perhaps what we really need is a simple sample that shows how to do this.
I'm afraid writing a native driver is still way out of my reach. I don't know that much about microcontrollers and was hoping that .NET MF will shield me from this ;-)
Sample showing where to begin with would be great!
That should be possible, but it's probably something that would require native C++ drivers (much like the Arduino uses direct interrupt control).
This brings up a good question: should we expose a standard C# class which lets you read/write processor registers directly?
Chris
Hi Guys,
I've coded in assembly, C/C++, and C# for the last good 10 years. I coded in assembly for 8051, in C/C++ for the 8-bit AVRMega MCU, and now in C# for the NETDUINO. It only make sense that NETDUINO continues to motivate development in C# and not going backward to C/C++ or native code. With this in mind, I recommend that the NETDUINO opensource community should expose a standard C# class which allows read/write to/from the MCU's registers directly.
This would allow C# programmer to create their own driver in C# and not have to deal with any native C/C++ code. I think this feature will make NETDUINO unique compare to other products out there. I strongly suggest that this feature gets implemented.
Also, an example of how to do this in native C/C++ would be nice to for those folks who like to do hardcore programming like myself
I think this feature will make NETDUINO unique compare to other products out there.
Unfortunately not, GHI Electronics has already done it a maybe others as well
...I recommend that the NETDUINO opensource community should expose a standard C# class which allows read/write to/from the MCU's registers directly
I would suggest to first evaluate, which registers should or could be exposed in such way - please keep in mind that certain registers are in use by .NET Micro Framework itself, and many are wrapped by various abstraction layers, so by direct access the state of managed objects may be corrupted or it can lead into unexpected behavior (likely impossible to troubleshoot). IMHO there should be managed classes for the most of functionality available, and then some powerful but safe mechanism for low level tasks - like native functions directly callable from the managed code. And, you don't want me to start wailing over the memory...
I have to agree with CW2 that exposing all registers my lead to unexpected errors. I was also thinking that it will be better to expose the wrapper for the timer/counter function alone. Very similar as we have managed wrappers for PWM and analog ports now. Maybe it should be Microsoft team responsibility to implement this in next release of .NET Micro Framework.
Are you looking for managed code access to timers/counters? Registers? Memory?
If we can firm up with community members would find useful in the native firmware, we can add an appropriate managed code wrapper. There's a lot of power in a Register class...but with that power comes danger
Are you looking for managed code access to timers/counters? Registers? Memory?
If we can firm up with community members would find useful in the native firmware, we can add an appropriate managed code wrapper. There's a lot of power in a Register class...but with that power comes danger
Chris
I *really* like this chip, I'd love to get it working. Managed code access to timers would be wonderful, or whatever the arduino has that lets it work with this chip (I think that the acces to the timers would allow me to do what the arduino does, but I might be wrong)...
to be better informed I will read up on this stuff... here: http://www.avrfreaks...ewtopic&t=50106, thanks for the link Szymon!
Hi Omar,
What are you trying to accomplish with timers? We can certainly provide access to them, but C# code is managed so I'm not sure how useful that would be.
Perhaps you're looking for ways to use timers to do very precise actions? If so, perhaps what we need is a good way to launch native code routines off of timer interrupts?
If you can give me an idea of your application, I can make some recommendations...and then we can explore possible features to help you accomplish your goals.
Chris
If you can give me an idea of your application, I can make some recommendations...and then we can explore possible features to help you accomplish your goals.
Chris
I will try to read that stuff and get a better understanding of it so I can let you know exactly what I need. But I am trying to do what Szymon was trying do.
Hi Omar,
Glancing at the datasheet, I'm guessing that you'd need a native code driver to get the precise nano/microsecond timings required by that chip.
Perhaps there is a SPI- or I2C-controlled chip which drives multiple PWM outputs?
Chris
Perhaps there is a SPI- or I2C-controlled chip which drives multiple PWM outputs?
hnh... this chip uses SPI and a two PWMs ... maybe I can find one that uses only SPI. I'll look into that then, I dont want to get anywhere near C++ yet (C# = , C++ = )
It would be great if the three timer/counters in the Netduino ARM7 CPU were exposed. I agree with CW2 and other posters that exposing the registers is the wrong way to go - better to provide a managed resource that integrates with the other parts of the firmware. I need access to the counters, ideally 2 independent ones. I would like to be able to intialize/reset the count in each, clock each one from an external pin, read the value from the counter, and generate an interrupt on overflow. This would let me count pulses from a c. 10KHz input without overwhelming the interrupt mechanism that the Netduino currently supports. Of course, all of this would have to work in harmony with the PWM support that is currently offered . I think this would be generally useful for the community.
I would like to be able to intialize/reset the count in each, clock each one from an external pin, read the value from the counter, and generate an interrupt on overflow. This would let me count pulses from a c. 10KHz input
Let's say someone creates a 'frequency counter' class to measure the frequency of a signal on any input pin - would it meet your requirements? Or would it be better to capture the input state transitions with timestamps into a buffer? Or both?
It would be great if the three timer/counters in the Netduino ARM7 CPU were exposed.
I agree at all that would be useful, but the problem is that the managed code is time-uncorrelated. Even having a hi-precision interrupt, the managed handler will be called after an indeterminate delay.
Let's say someone creates a 'frequency counter' class to measure the frequency of a signal on any input pin - would it meet your requirements? Or would it be better to capture the input state transitions with timestamps into a buffer? Or both?
The ability to measure how many pulses happens within a time-window could be useful, but I think it is a seldom used function.
Since I really would love having the ability to sample data in real-time fashion, I'd suggest to think to a component whose interface could be shaped as follows:
public class PortSampler
: IDisposable
{
//Create a sampler using the specified sampling period
public PortSampler(TimeSpan period)
{
}
//returns true if the sampler is actually collecting data
//false when idle (see RunOnce/Run/Stop)
public bool IsBusy { get; }
//returns the logical position of the last sample collected
//-1 is for no samples available
public int Position { get; }
//configure the sampler to collect any I/O port (boolean)
//by copying all the bits as an UINT32
public void SetBooleanReader(uint[] buffer)
{
}
//configure the sampler to publish a mask of output ports (boolean)
//by copying all the bits from an UINT32
public void SetBooleanWriter(uint[] buffer, uint mask)
{
}
//configure the sampler to collect the specified ADC port reading
//as INT32 samples
public void SetAnalogReader(int[] buffer, int port)
{
}
//configure the sampler to collect the specified ADC port reading
//as FLOAT normalized samples
public void SetAnalogReader(float[] buffer, int port)
{
}
//configure the sampler to publish an INT32 sample
//to the specified ADC port
public void SetAnalogWriter(int[] buffer, int port)
{
}
//configure the sampler to publish a FLOAT normalized sample
//to the specified ADC port
public void SetAnalogWriter(float[] buffer, int port)
{
}
//starts the samples collection, until the buffers fill
public void RunOnce()
{
}
//starts the samples collection, using the buffers as circular
public void Run()
{
}
//stops the sampler, bringing its status to idle
public void Stop()
{
}
}
Instead of creating many super-specialized components, that would be a general-purpose sampler. It samples whatever you want granting high precision and reliability, but the glue-logic can be written using managed code.
Happy to hear from you all.
Biggest fault of Netduino? It runs by electricity.
I agree at all that would be useful, but the problem is that the managed code is time-uncorrelated. Even having a hi-precision interrupt, the managed handler will be called after an indeterminate delay.
In certain cases, such as frequency measurement, there is no need for a managed event handler at all - the calculation (in either timer overflow or pin state change interrupt service routine) just needs to divide number of events by time period and store the result in a variable, accessible via the managed wrapper property (locking/atomic assignments assumed). Then it is possible to avoid the delay imposed by HAL completions.
Since I really would love having the ability to sample data in real-time fashion