Netduino home hardware projects downloads community

Jump to content

The Netduino forums have been replaced by new forums at This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.

Mike P's Content

There have been 41 items by Mike P (Search limited from 28-October 20)

By content type

See this member's

Sort by                Order  

#25669 Anyone is interested on a high-end acquisition shield?

Posted by Mike P on 18 March 2012 - 03:45 AM in General Discussion

I was breadboarding a 24 bit ADC with integral current sources. I wanted it for high resolution temperature sensing (4-wire PT100). The same device would be well suited for load cells and strain gauges(used for measuring force/weigh/pressure/stress) I was testing both the exas instruments ADS1247 or Analog device AD7794. Unfortunately the project was shelved.

#19787 CANBus ...

Posted by Mike P on 26 October 2011 - 03:31 AM in General Discussion

I must have been half asleep when I wrote my earlier response. It was full of mistakes. I've edited it and fixed the errors. Regards, Mike Paauwe

#19568 SPI, Netduino, and RGB LED Strip

Posted by Mike P on 21 October 2011 - 10:02 PM in General Discussion

If you look at Stefan W's oscilliscope images you will see why an "almost high enough" voltage level could cause multiple clock triggers. look at the spike at the leading edge of the clock pulse. If you looked at the signal even closer you would see a decaying oscillation that could cause several false clock pulses to be received.

#19565 SPI, Netduino, and RGB LED Strip

Posted by Mike P on 21 October 2011 - 09:08 PM in General Discussion

If you have time I would be very interested to see if the LED strip works without the level conversion chip. I mean with the SDI , SCLK and GND connnected directly to the netduino. Regards, Mike Paauwe

#19513 SPI, Netduino, and RGB LED Strip

Posted by Mike P on 21 October 2011 - 09:38 AM in General Discussion

What you are describing sounds very much like some false triggerring on the clock pin. Between the write transactions the MOSI line goes high. That explains why you are gettin white LEDs at the start. You are getting a number of clock pulses being detected while the clock is supposed to be low. Try increasing the thread.sleep to 500ms. You should see the LED states change instantaneously every 1/2 a second and be stable between changes. A couple more questions. The 2A @ 5V power supply, is it a Switch mode power supply or a plug-pack or wall-wart type power supply? Some of these have very little smoothing and ripple on the supply line might be causing the unwanted clock triggers You definitely need the gnd pin from the data connector connected to the netduino. The gnd pin of the power connector should already be connected to the ground pin of the data connector internally on the LED strip Perhaps if you can take a photo of the setup.

#19502 SPI, Netduino, and RGB LED Strip

Posted by Mike P on 21 October 2011 - 07:28 AM in General Discussion

Just to be clear, when you say it pushes it down do you mean that the 4th led comes on or do you mean that the colour keeps moving on down the string of LEDs all the way to the end? Also what if anything is showing on the first two LEDs? The code should be resetting the first 3 LEDs to Red, Green, Blue respectively about 10 times a second. Either way, if you are seeing anything on the 4th or subsequent LEDs then the string is receiving spurious clock pulses. Can I confirm some things about your power supply arrangements? Do you have the LED strip connected to a separate 5V supply that is capable of supplying at least 1.8A and NOT the 5v pin on the netduino? Do you have the ground for the LED strip connected to both the 5v high current PSU and the netduino mini ground pins? Sorry if these questions are basic to you but I don't want to assume anything.

#19481 SPI, Netduino, and RGB LED Strip

Posted by Mike P on 21 October 2011 - 12:56 AM in General Discussion

You need to look at the output from MF Deploy

#19465 SPI, Netduino, and RGB LED Strip

Posted by Mike P on 20 October 2011 - 06:17 PM in General Discussion

Can you try the following in a new solution please?
Let's remove all the other code from the list of suspects and focus on just getting the SPI transfer functional.
This should set the first 3 LEDs to Red, Green, Blue.

        public static void Main() 
            byte[] buffer = new byte[] { 0xFF,0x00, 0x00,  0x00,0xFF,0x00, 0x00,0x00,0xFF }; 
            SPI.Configuration xSPIConfig; 
            SPI xspi; 
            xSPIConfig = new SPI.Configuration(Pins.GPIO_NONE, false, 0, 0, false, true, 100, SPI.SPI_module.SPI1); 
            xspi = new SPI(xSPIConfig); 
            while (true) 

#19463 SPI, Netduino, and RGB LED Strip

Posted by Mike P on 20 October 2011 - 06:07 PM in General Discussion

Just something out of left field. Could you have clock and data reversed? That would explain a lot of 0xFFs Clock should be on pin 16 MOSI should be pin 14.

#19429 SPI, Netduino, and RGB LED Strip

Posted by Mike P on 20 October 2011 - 10:45 AM in General Discussion

I wish I had a solution to your problem but Mario has already suggested everything I can think of.

The bug Mario refers to would only affect you if you used clock_idle=true. This is because the SPI firmware always sets clock to false after the transaction.
The bug has no effect if using clock_idle=false.
The WS2801 spec says it's good for up to 25MHz clock speed. Don't try to set 25MHz though because you will end up with 48MHz. You should be able to use 24MHz though if you keep lead length short. But there's no reason that 2MHz shouldn't work.

You could try running the strip at Vcc=4V or less. Add a couple of 1N4007 diodes in series to drop the voltage. The chip is spec'd for 3.3-5V VCC but obviously the LED intensity would be lower. This would only be to prove that the logic hi level is not the issue.
For those reading this thread who haven't looked at the data sheet the specification for a logical high input level is 0.8* Vcc. With Vcc at 5v this means a minimum voltage of 4v is required to be certain it is registered as logic hi. Netduino can only put out 3.3v on the outputs.

Since your chip does not use the CS, you should use CS = GPIO_None. Pin 13 on the mini is the only pin that you can't use for CS (with the currently released firmware) the same is true for Pin 4 on the netduino(&plus)
This is due to some functionality in the .NETMF porting kit that was abandoned but not completely removed.
I can't see how this could stop your code from working though.
Are you using the latest firmware? or 4.2?

If I were you, I would buy myself an Open bench logic sniffer from Seeed studios. It'll be the best $50 you've ever spent.
A logic shrimp or a bus pirate might even be sufficient. Or borrow an oscilloscope from someone.

I duplicated Stefan W's sample on my Netduino plus (FW4.1.0.6) and got a different result.
Here is my sample taken using the Logic Sniffer
spi sample.png
        public static void Main()
            byte[] buffer = new byte[] { 0x55, 0xFF, 0X00, 0X55, 0XAA };
            SPI.Configuration xSPIConfig;
            SPI xspi;
            xSPIConfig = new SPI.Configuration(Pins.GPIO_NONE, false, 0, 0, false, true, 100, SPI.SPI_module.SPI1);
            xspi = new SPI(xSPIConfig);
            while (true)

Even at 100kHz there is nothing like a 500us break in the transmission. The GC (garbage collector) may run between bytes during an SPI write comman making a slightly longer delay between bytes but it would never get to anything like 500us.

#19131 multiple spi devices (thermocouple)?

Posted by Mike P on 13 October 2011 - 08:33 PM in General Discussion

That's right. The 304 can only log data if connected to a PC or laptop. It comes with the serial cable and windows software for logging and displaying the temperatures. The 309 has internal memory for storing temperature and time. I've used a 309 and a 302(2ch).

#19101 Netduino with 24Bit ADC (LTC2400) Help.

Posted by Mike P on 13 October 2011 - 03:49 AM in Netduino Plus 2 (and Netduino Plus 1)

SDO (pin 6), is going to Hi-z when the ADC is not accessed, so /CS=high. Since isn't a good choice leaving the MISO input without any drive, I'd add a weak pullup to this pin.

Hi Mario,
The firmware sets the MISO pin to its GPIO function and enables the internal pullup between transactions so an external pullup is not necessary.
Mike Paauwe

#19099 Netduino with 24Bit ADC (LTC2400) Help.

Posted by Mike P on 13 October 2011 - 03:41 AM in Netduino Plus 2 (and Netduino Plus 1)

3 and final) This last thing has freaked me out big time.
The calculation I did to see the Volt value was this:

3000 * adcValue / System.math.pow(2, 24)

This resulted in something obscene.
When a colleague was messing around with my code he changed it to this:
3000.0 * adcValue / System.math.pow(2, 24)

Which actually gave the correct volt value!!!
I don't really get why this happens but I assume it has something to do with my declaration of ltw

Hi George,
I realise this post topic is quite old but someone else has brought it to the top again and it was left with an un answered issue.
There's two things at play here.

Firstly the reason your code didn't work as intended is because intermediate stages in your calculation overflowed the capacity of the int data type.
Int is a 32 bit integer and your calculation takes 3000 (12 bits) and multiplys it by adcValue (up to 24 bits) potentially the result could require 36 bits.
You need to use type long which is 64 bits long and your resulting answer would be correct, although it would be truncated to an integer millivolt value.
More likely you wanted to do floating point math, and this is what your freinds change does.

3000 * adcValue / System.math.pow(2, 24)
3000.0 * adcValue / System.math.pow(2, 24)

The two lines of code above have one important difference. In one 3000.0 is a floating point value and in the second 3000 is an integer.
so the first line of code is int * int / int and .net will solve this using integer maths.
by declaring the constant as a float the second version is float * int / int. In this case .net won't try to solve this using integer math. It will instead convert the integers to floats and use floating point math.

Something else you might find useful are the following alternatives to using System.math.pow(2, 24).
You could use the resulting value directly eg 16777216 or 0x1000000
or try (1<<24). This is "1" shifted left 24 places.

Mike Paauwe

#19019 multiple spi devices (thermocouple)?

Posted by Mike P on 11 October 2011 - 06:20 AM in General Discussion

I certainly don't want to steer you away from a netduino solution if that is what you want but have you considerred an off the shelf product like this:
This doesn't log on it's own but if you connect it to a laptop or a pc it will log.

Just in case the link above goes dead, it is a CENTER-304 4-channel RS232 Thermometer that costs US$119.64 with free shipping.

#18893 CANBus ...

Posted by Mike P on 07 October 2011 - 07:57 AM in General Discussion

Hi Dan,
I think I can help you with a few things here.
The Spec sheet for MCP2515 gives the max SPI bus speed as 10MHz. Your configuration has a value of 16000 which is 16MHz. Try using 1000 10000 or less.
From the figure below the clock idle state is false and the clock edge is true.
However this chip supports both SPI Mode 0,0 and mode 1,1. So clock idle=true will also work. There is a bug with the current firmware that only affects clockidle=false so I would recommend you use clock idle=true
There is a bug with the current firmware that only affects clockidle=TRUE so I would recommend you use clock idle=FALSE (Sorry for the confusion)

Lastly the timing diagram(FIGURE 12-10) and the table that accompanies it (TABLE 13-6) show the maximum clock rate is 10MHz and the CS Setup Time and the CS Hold Time must be a minimum of 50ns.
Using a value of 0 for both these settings in your configuration will result in delays far exceding 50ns
So your config line should be:
config = new SPI.Configuration(Pins.GPIO_PIN_D10 , FALSE, 0, 0, TRUE, TRUE, 10000, SPI.SPI_module.SPI1);
config = new SPI.Configuration(Pins.GPIO_PIN_D10 , FALSE, 0, 0, FALSE, TRUE, 10000, SPI.SPI_module.SPI1);

Now for the read command.
Section 12.3 of the datasheet explains the read register process. It says that "The read operation is terminated by raising the CS pin"
It also says "
The MCP2515 expects the first byte after lowering CS to be the instruction/command byte. This implies that CS must be raised and then lowered again to invoke another command."
By writing using 3 operations as you are doing the chip select will be raised between each operation.
So you need to combine the read instruction, address data and reading the result into one writeread operation.
The following code should do this:
        SPI.Configuration xSPIConfig;
        SPI xspi;
        xSPIConfig = new SPI.Configuration(Pins.GPIO_PIN_D10, false, 0, 0, false, true, 10000, SPI.SPI_module.SPI1);
        xspi = new SPI(xSPIConfig);
        private byte readReg(byte regno)
            byte[] writeBuffer = new byte[] {0x03, regno};
            byte[] readBuffer = new byte[1];
            return readBuffer[0];
You can find some more info in the Wiki

#18382 Need Documentation for Netduino(SDK)

Posted by Mike P on 24 September 2011 - 10:11 PM in General Discussion

Have you tried pressing "F1" while editing code in the Visual Studio? The information in the online help isn't always very helpful but it is complete in that all comands are there. If you have a command highlighted when you press F1 you will get help on that command.

#18056 Compiling firmware

Posted by Mike P on 15 September 2011 - 07:49 PM in Netduino 2 (and Netduino 1)

Thanks CW2. That makes a lot of sense. Success. I compliled and uploaded firmware from source for the first time.

#18044 Compiling firmware

Posted by Mike P on 15 September 2011 - 12:55 PM in Netduino 2 (and Netduino 1)

There are several really good posts buried in the forum on how to compile the Netduino firmware from source code.
I've managed to get as far as this error:

C:\GCC\bin\arm-none-eabi-ld.exe: C:\MicroFrameworkPK_v4_1\BuildOutput\THUMB\GCC4.2\le\FLASH\release\Netduino\bin\tinyclr.axf section ER_FLASH will not fit in region LR_FLASH
 C:\GCC\bin\arm-none-eabi-ld.exe: region LR_FLASH overflowed by 65128 bytes

Now I have read this very helpful post by CW2:

And I understand that I have to adjust the blockrange for the code.

What I am stuck on is where do I find the size of the ER_FLASH file since it does not get created when the build fails.

In CW2's post he says "but our firmware is 0x50ADC bytes" but I don't know where that figure came from.
How do I find the size of the firmware so that I can know how big to make the BlockRange?

#18037 Pin 4 can't be used at a high speed?

Posted by Mike P on 15 September 2011 - 09:48 AM in Netduino 2 (and Netduino 1)

Hi Stefan, since you've brought this back to the top again I'll add my 2cents. If you are interested I think I can explain why pin4 does not work as a chip select. The SPI driver is part of NETMF code. SecretLabs have a few lines of code they have added but by and large it is untouched from the NETMF distributed version. The AT91 core SPI peripheral supports 4 pins as hardware chip select pins CS0-CS3. CS0 is also used as a slave select (NSS) in slave mode. Pin4 is the pin that connects to this CS0/NSS peripheral output. Within the driver code there is a block of code that would convert pin 4 from its GPIO function to its SPI peripheral function if you pass pin4 as the chip select. This line of code is commented out. There is also a code block that sets the CS pin to the appropriate state before and after the transfer. This block of code doesn't get executed if you use GPIO_PIN4 or GPIO_PIN_NONE. It appears as though the programmer intended to support use of pin 4 as a peripheral hardware chip select and any other pin as a software chip select. But when they couldn't get CS0 working they commented it out in one place but not the other. I think I can see why it wouldn't have worked too. As written the CS line would have pulsed inactive between each character which would have messed things up in most applications. So until someone fixes the SPI class properly you will just have to accept that pin4 can't be used for Chip select. If you are interested to look yourself the driver code is in the porting kit here: C:\MicroFrameworkPK_v4_2\DeviceCode\Targets\Native\AT91\DeviceCode\AT91_SPI\AT91__SPI.cpp

#17966 Where is DateTime?

Posted by Mike P on 14 September 2011 - 04:12 AM in General Discussion

Have you seen this post?

#17965 3.3v, 5v, Various Ports and Components, oh my.

Posted by Mike P on 14 September 2011 - 04:09 AM in General Discussion

Welcome aboard. One of the first steps in learning is figuring out what questions to ask. Judging from your post you have that well underway. You will find many basic tutorials on the net. There's dozens of them. A basic understanding of the function of resistors, diodes and capacitors will answer a lot of your questions. I would make sure you understand why a resistor is required before you connect your LED to your netduino. There is no overcurrent protection on the netduino outputs which means you can burn them out. Good luck

#17953 Combining Pins

Posted by Mike P on 14 September 2011 - 12:30 AM in General Discussion

NETMF may not have a built in class but GHI have implemented a parallelPort class for their products on NETMF.
I wonder if this could be ported into the Netduino firmware? They also have an outputCompare class that looks pretty useful.

Oh well...

#17952 EM406a not fixing satelites

Posted by Mike P on 14 September 2011 - 12:08 AM in General Discussion

Did you take it outside? My experience is that very few GPSs work inside.

#17750 SPI bug report (NETMF bug)

Posted by Mike P on 08 September 2011 - 11:40 AM in Beta Firmware and Drivers

Hi I think this is a bug in the netMF code. Would any of you code gurus like to have look and tell me if you agree?
Feel free to visit codeplex and vote.

AT91_SPI_Driver::Xaction_Stop() has CS release sequence reversed

After the SPI transaction completes the Chip Select should be released before setting MOSI, MISO and SCLK to their idle levels.
in 4.1 and 4.2RC2 the MOSI and SCLK pins are both set low before CS is deactivated.
I am not sure but perhaps SCLK should be set low or high to honour the Clock_IdleState setting.
The file is C:\MicroFrameworkPK_v4_2\DeviceCode\Targets\Native\AT91\DeviceCode\AT91_SPI\AT91__SPI.cpp
Lines 376-384 should be moved up to line 342
This would only cause a problem for slaves where the Clock_IdleState was true. In this instance an unwanted clock edge is sent before chip select is released. Depending on how the slave has been implemented this may have no effect.

Here is a capture of the SPI transfer and you can see MOSI and SCLK being set low before CS is released.traces are SCLK, MOSI, MISO, CS.
single sample.png

#17739 Pinout Cards

Posted by Mike P on 08 September 2011 - 04:29 AM in General Discussion

Thanks Tecchie,
Thanks also Inquisitor for bringing this to the top again.
I wonder how many more gems like this are buried in the forum archives.
I have taken the liberty of copying this to the Wiki so that it will remain readily available for all.


home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.