62 replies to this topic

[monewwq1]

Can someone please speed up my Netduino? Does anyone have a Netduino Ultra I could borrow?

[JonnyBoats]

As others have pointed out, a Netduino is not the right tool when you require precise real-time programming. There are however lots of cheap micro-controllers that can measure frequency and report the results to the Netduino via I2C or many other ways.

One cheap way to do this is with a TI MSP430 board which only costs $4.30 delivered (https://estore.ti.co...-kit-P2031.aspx ) This is probably the cheapest way to do a one-off project and the TI chip has reasonably good support.

The best way to look at this is that there is no one perfect single board computer. The key is to use one appropriate to the task and remember that they are cheap enough that you can break the task down and use more than one board.

[monewwq1]

Can an Atmel AT91SAM7X512 microcontroller support the functions of the Taos TSL235R?

I am still not convinced that I need to throw more components at this problem. Netduino has an ARM7 48MHz processor- why should we deny that there is plenty of speed right on this development board? If I were to remove the processor from the Netduino and program it directly, or remove the .Net firmware and run C/C++ on it, I am sure that this sensor would run fine. I've read in these forums that version 4.1.2 of the Netduino firmware is supposed to offer run-time native code interop. I've also read about someone's project called "Fluent", which runs code something like 20 to 30 times faster than the managed code. I've also read that you can run FreeRTOS on the Netduino platform. Can't you run a quadrocopter with FreeRTOS? Isn't that real-time?

Does version Netduino 4.1.2 have runtime native code interop? If not, when will it have this functionality? Where can I get this "Fluent" project? Where can I find resources on how to run my own C/C++ on this board?

I understand the opinion that more tools will help me solve this problem, but I would rather use what I have instead of having to then deal with connecting, learning, and powering these other pieces.

[JonnyBoats]

You are quite correct that the hardware is quite capable of handling this frequency measurement task with ease.

The issue is the .Net Micro Framework. If you are willing to forgo .Net and program directly to the chip in C, you can get the job done.

What s not as simple or easy is to combine the use of .Net with native code and direct control of hardware interrupts etc. It may very well be possible, and I hope you succeed as we would all like this capability. You should be prepared for some setbacks along the way.

Can an Atmel AT91SAM7X512 microcontroller support the functions of the Taos TSL235R?

I am still not convinced that I need to throw more components at this problem. Netduino has an ARM7 48MHz processor- why should we deny that there is plenty of speed right on this development board? If I were to remove the processor from the Netduino and program it directly, or remove the .Net firmware and run C/C++ on it, I am sure that this sensor would run fine. I've read in these forums that version 4.1.2 of the Netduino firmware is supposed to offer run-time native code interop. I've also read about someone's project called "Fluent", which runs code something like 20 to 30 times faster than the managed code. I've also read that you can run FreeRTOS on the Netduino platform. Can't you run a quadrocopter with FreeRTOS? Isn't that real-time?

Does version Netduino 4.1.2 have runtime native code interop? If not, when will it have this functionality? Where can I get this "Fluent" project? Where can I find resources on how to run my own C/C++ on this board?

I understand the opinion that more tools will help me solve this problem, but I would rather use what I have instead of having to then deal with connecting, learning, and powering these other pieces.

Thanks,

Nick

[Mario Vernari]

As Baxter pointed out, the TSL230R offers a frequency scaling (up to x100), thus perhaps may be used with Netduino. Maybe by writing the code in a very smart way... About Fez. I don't know how the Fez board works, but it embeds a processor running 1.5x than the Netduino's. The compiler used by GHI is the same, and the MF code should be exactly the same (at least a high percentage). So, perhaps the C# code runs a bit faster, but I am suspicious that they are able to reach frequencies over 10-20KHz. *VERY* suspicious... Guys, I feel as the wolf in the Little Red Riding Hood tale. NickDuino, maybe -at least once- you have tried to write and run a Visual Basic 6 program. Very easy and intuitive, but a turtle ran times faster! The Netduino Atmel MCU is blazing fast. Looking at the MCU's specs, there is a section regarding a "TC" (Timer Counter). In practice, the MCU embeds a hardware section being able to measure the frequency, so the software could take advantage of this at no CPU cost. The only problem is that you should write your own native driver to access it. If you have a Netduino mini or standard, you may try to compile the firmware with the driver. Instead, the Plus version needs an expensive compiler, because the free GCC cannot shrink enough all the code in the 512K of flash. Also true about the "arduino" way. I write "Arduino", but I mean a minimal -duino solution with a bootloader, just to keep the programming easy. Any other MCU ready-to-go may fit this purpose, though. Using another microcontroller seems an overkill, but there's no reason for thinking that. The price is often lower than an equivalent ASICS, it allows several different usages, and once you learn it makes very little effort to re-use again. Cheers

[CW2]

Do you think the light-to-frequency converter would work for a Netduino project like this?

Given the low performance of Netduino's managed interrupt handlers, have you considered using light-to-digital converters? Not sure about the price and availability, though.

[CW2]

Can an Atmel AT91SAM7X512 microcontroller support the functions of the Taos TSL235R?

It definitely can. However, on Netduino the only reasonable way is to access hardware Timer-Counter (TC) module via native driver, because the managed interrupts are queued, the queue size is only 128 items, it takes roughly hundreds of microseconds before the handlers are executed and the resolution of 'slow clock' is only 21.33 µs, which determines the precision of time measurement (but it can be increased).

One way to implement frequency counter would be:

• Use TC2 (the only one which has input signals TIOA/TIOB broken out) in capture mode,
• Configure clock source based on the desired precision and frequency range - this may be a little bit tricky, because there are only five clock frequencies (MCK/2, MCK/8, MCK/32, MCK/128 and MCK/1024, where MCK is Master Clock = 48 MHz) and timer register is 16-bit, however this can be easily worked around by using 'overflow' counter in the timer Interrupt Service Routine (ISR), and/or passing the clock ('frequency range') as parameter to the managed class,
• If needed, implement timer ISR to extend the counter range (simply increment 'intervalCounter' variable),
• Connect the input signal to pin PB27 (TIOA2) or PB28 (TIOB2), configure the input as external trigger,
• Start the timer,
• Periodically (e.g. in 1 second managed timer), read the timer counter value (TC_CV2 and intervalCounter variable, reset after reading) and calculate the frequency.

The current implementation of .NET Micro Framework uses TC0 for scheduling ('slow clock'), the code for TC is already there, see AT91_TIMER_Driver in DeviceCode\Targets\Native\AT91\DeviceCode\AT91_TIMER\AT91_TIMER.cpp, and sample usage in Targets\Native\AT91\DeviceCode\AT91_TIME\AT91_TIME.cpp.

[CW2]

One way to implement frequency counter would be:

Another, and perhaps much easier, would be to count pin interrupts directly in the native interrupt handler (so it does not dispatch managed event handler). It may not be as precise as the hardware timer-counter, but can be enabled for any pin (that supports edge interrupts).

[Chris Walker]

Hi NickDuino, I'm just picking up on this thread now, but are you using InputPort to meeasure the time in managed code instead of using InterruptPort (which passes a fairly precise timestamp of the original event)? I saw that you were getting the error "An error occurred: Please check your hardware." This most likely doesn't have anything to do with your device...and is instead a fairly generical Visual Studio .NET MF SDK error which can mean anything from "the device is busy" to "the wrong version of .NET MF is on the device." These errors get more specific with .NET MF 4.2 in some cases. If I can better understand exactly what you're trying to do, we may be able to get you up and running here--or at least point you in the right direction of how to make this work. Worst case scenario, you can write some native code to turn a digital pin into an FIQ pin and then you'll get multi-MHz "super-interrupt" capability to record timestamps in native code with greater MCU priority than .NET MF runs at (although I wouldn't go that far unless the normal methods don't work first). Chris

[Mario Vernari]

@Chris: Nickduino seems having a standard Netduino, so maybe he may arrange a native driver. But what if he had a Plus? Sorry Chris, but that's still a serious gap. Cheers

[Chris Walker]

Hi Mario, Sorry, what I was trying to say was that InterruptPort is the right tool for the job here...not InputPort. With InterruptPort, one gets timestamps of the actual interrupts. With InputPort, one is measuring time changes in managed code at slower speeds and possibly with some latency. Regarding Netduino Plus...you can compile firmware for it with GCC too. You may need to remove a few built-in libraries/features, at least with older and less efficient versions of GCC. I understand that newer versions of GCC compile more efficiently (smaller firmware)...and I know that there are a few folks using newer versions of GCC in some capacity with msbuild. Once .NET MF 4.2 is released (any day now) perhaps a few of us from the community can try to get the newer GCC builds compiling the full Netduino Plus firmware to see how much more efficient it is? Chris

[Mario Vernari]

Maybe I missed some episode of the saga, but time ago I tried to follow the CW2's instructions to compile using GCC. The result was I had to cut off all of the Plus features, because the compilation overflew all the times. At this point, I could not consider any native extension for the Plus. Both you and CW2 told me that the only way to shrink everything into the flash, was to compile the firmware is using RVDS. If anyone may tell me how to try, I'll be the happiest guy in the world! BTW, about the interrupt, the sensor outputs a frequency up to 1MHz. Basically Nickduino should count how many pulses fall within a certain time interval. Surely the best way is to take advantage of the TC module, that acts exactly for the purpose. Otherwise, do you think a one-microsec native interrupt, could be served reliably? Thanks.

[CW2]

If anyone may tell me how to try, I'll be the happiest guy in the world!

ARM offers time-limited trial version of their RVDS 4.1 Pro suite (e-mail registration required).

[monewwq1]

Hi NickDuino,

I'm just picking up on this thread now, but are you using InputPort to meeasure the time in managed code instead of using InterruptPort (which passes a fairly precise timestamp of the original event)?

Hi Chris,

I am using InterruptPort:

                // the pin is expected to interrupt on rising edges
                InterruptPort _dataOutInterruptPort = 
                    new InterruptPort(Pins.GPIO_PIN_D2, false,
                                       Port.ResistorMode.Disabled,
                                       Port.InterruptMode.InterruptEdgeHigh);

                // add an interrupt handler to the pin
                _dataOutInterruptPort.OnInterrupt += 
                    new NativeEventHandler(_dataOutInterruptPort_OnInterrupt);

And in the event handler _dataOutInterruptPort_OnInterrupt, I am simply counting the pulses with a long variable:

            private void _dataOutInterruptPort_OnInterrupt(uint port, uint state, DateTime time)
            {
                _pulseCount++;
            }

I'm then using the _pulsecount to determine the frequency and then using some additional math to get the irradiance. If I cover the TSL sensor with a black cloth, I do get a few readings from the Netduino, but after that, my Interrupt stops firing. If I shine a bright light on the TSL sensor, I never get any readings and the Netduino becomes "busy" and unresponsive to the IDE.

Perhaps there is too much code in my interrupt routine. I am going to write a real simple version that does not do any irradiance calculations and only prints a very limited amount to the Debug console. I will post the code to this thread later today.

[Mario Vernari]

ARM offers time-limited trial version of their RVDS 4.1 Pro suite (e-mail registration required).

Are you pulling my leg?
I am kidding, but I'd prefer avoid comments...

[Chris Walker]

Perhaps there is too much code in my interrupt routine. I am going to write a real simple version that does not do any irradiance calculations and only prints a very limited amount to the Debug console. I will post the code to this thread later today.

Sounds good. Let's see what we can do to get you off and running

Chris

[Chris Walker]

ARM offers time-limited trial version of their RVDS 4.1 Pro suite (e-mail registration required).

It might also be useful to test Microsoft's ARM compiler. I know that it requires several changes to the build/source files--but I've heard rumors that a few brave souls have been building with it as well.

Chris

[Nevyn]

It might also be useful to test Microsoft's ARM compiler. I know that it requires several changes to the build/source files--but I've heard rumors that a few brave souls have been building with it as well.

Do you have a link to that?

Regards,
Mark

[CW2]

It might also be useful to test Microsoft's ARM compiler. I know that it requires several changes to the build/source files--but I've heard rumors that a few brave souls have been building with it as well.

Is it the one included in Windows Embedded Compact 7? Or do Windows 8 developer tools come with ARM cross-compiler as well? Adding build support cannot be much different than adding other toolchain (say CrossWorks ;- )

[Chris Walker]

Is it the one included in Windows Embedded Compact 7?

I believe so, yes. There should be a download somewhere on Microsoft's site. The only thing I don't know is how it's licensed (free, for use with CE only, or other)...

Chris