Mike P's Content
There have been 41 items by Mike P (Search limited from 24-April 23)
#19481 SPI, Netduino, and RGB LED Strip
Posted by
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
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.
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)
{
xspi.Write(buffer);
Thread.Sleep(100);
}
}
#19463 SPI, Netduino, and RGB LED Strip
Posted by
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
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? 4.1.0.6 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
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.
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? 4.1.0.6 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
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)
{
xspi.Write(buffer);
Thread.Sleep(100);
}
}
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.
#19513 SPI, Netduino, and RGB LED Strip
Posted by
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
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.
#19565 SPI, Netduino, and RGB LED Strip
Posted by
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
#19568 SPI, Netduino, and RGB LED Strip
Posted by
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.
#15914 Unable to deploy without disconnect\reconnect USB cable
Posted by
on 26 July 2011 - 10:00 AM
in
Netduino Plus 2 (and Netduino Plus 1)
Same thing happens to me.
If I hit the reset button then the I need to replug the usb connection before visual studio will reconnect to it. Running WinXP32. NetduinoPlus 4.1.0.6
#17286 Unable to deploy without disconnect\reconnect USB cable
Posted by
on 30 August 2011 - 09:47 PM
in
Netduino Plus 2 (and Netduino Plus 1)
I thouth I would give this thread another kick to see if anyone else has any ideas.
Is this behaviour normal then?
Does everyone just unplug their netduino every time they deploy?
I've tried all the available firmwares in the hope this might be a bug that has been addressed.
4.106 through to 4.2RC1
#19101 Netduino with 24Bit ADC (LTC2400) Help.
Posted by
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.
Regards,
Mike Paauwe
#19787 CANBus ...
Posted by
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
#19099 Netduino with 24Bit ADC (LTC2400) Help.
Posted by
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.
Regards,
Mike Paauwe
#18893 CANBus ...
Posted by
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 using1000 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:
Using-SPI-Write-and-WriteRead
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
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.
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:
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];
xspi.WriteRead(writeBuffer,readBuffer,2);
return readBuffer[0];
}
You can find some more info in the WikiUsing-SPI-Write-and-WriteRead
#18037 Pin 4 can't be used at a high speed?
Posted by
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
#17235 Six Button Interface for LCD Menu System.
Posted by
on 29 August 2011 - 01:37 PM
in
General Discussion
The resistor network works pretty well. I have a DF Robot shield which uses this.
That shield has Up,Dn,Left,Right,Select and Reset(The ultimate cancel?)
One thing that may be a limitation is that it needs to be polled.
You can't trigger an interrupt from an analog input pin. but you could use 2 pins, one as an interrupt port and the other as an analog input and feed the signal into both.
for a digital IO pin voltages over 2.0v are a logic high so arrange the reseistor network so that a voltage of 0v for no keys pressed and voltages of 2.0 - 3.3v for the 6 keys. That's 260mv spacing.
I haven't done the math but that sound like plenty of discrimination.
The digital pin would be used to trigger an interrupt on a rising edge.
Multiple keys being pressed simultaneously can be detected as long as the first key has a lower voltage than the second key.
Usually when you use multiple keys simultaneously you hold one and press the second.
I think that you should be able to implement more than 6 keys with interrupt on keypress and using only 2 pins.
#17279 Six Button Interface for LCD Menu System.
Posted by
on 30 August 2011 - 04:12 PM
in
General Discussion
Now I've got to put my money where my mouth is!
This should work but untested
I tried to put a table in below but the TABs get stripped out so it's in CSV form instead.
The table below gives the resistor values,
The total resistance when the button is pressed,
The voltage on the analog input,
The ADC reading,
The difference between the ADC value for this button and the next one up,
and the suggested cut-off value to use when deciding which button has been pressed
I even managed to keep to common value resistors and get very even separation between the voltages.
Vcc=3300mV
Button,Resistor,Total R,mV,ADC,delta,cutoff
Cancel,1500,1500,3300,1024,,986
Right,120,1620,3056,948,76,908
Left,150,1770,2797,867,81,827
Down,180,1950,2538,787,80,747
Up,220,2170,2281,707,80,668
Select,270,2440,2029,629,78,315
None,,,0,0,629,
In the schematic the second analog input pin would actually be used as a digital interrupt pin and could be on any of the GPIO pins. Its not necessary if you don't mind polling the analog input continuously.
I tried to put a table in below but the TABs get stripped out so it's in CSV form instead.
The table below gives the resistor values,
The total resistance when the button is pressed,
The voltage on the analog input,
The ADC reading,
The difference between the ADC value for this button and the next one up,
and the suggested cut-off value to use when deciding which button has been pressed
I even managed to keep to common value resistors and get very even separation between the voltages.
Vcc=3300mV
Button,Resistor,Total R,mV,ADC,delta,cutoff
Cancel,1500,1500,3300,1024,,986
Right,120,1620,3056,948,76,908
Left,150,1770,2797,867,81,827
Down,180,1950,2538,787,80,747
Up,220,2170,2281,707,80,668
Select,270,2440,2029,629,78,315
None,,,0,0,629,
In the schematic the second analog input pin would actually be used as a digital interrupt pin and could be on any of the GPIO pins. Its not necessary if you don't mind polling the analog input continuously.
#17739 Pinout Cards
Posted by
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.
http://wiki.netduino...nout-Cards.ashx
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.
http://wiki.netduino...nout-Cards.ashx
#17085 Help with Proper Servo Driving
Posted by
on 26 August 2011 - 09:09 AM
in
General Discussion
Another solution is to put 3 1N4007 diodes in series. The forward voltage drop is 0.7V each so the output would be 6.9V
#17952 EM406a not fixing satelites
Posted by
on 14 September 2011 - 12:08 AM
in
General Discussion
Did you take it outside? My experience is that very few GPSs work inside.
#15575 LCDKeypad 16x2 HD44780 Shield
Posted by
on 17 July 2011 - 11:41 AM
in
Project Showcase
Hi All,
I've documented a simple mod to this DFRobot LCD Keypad Shield (DFR0009)
The mod gets the keypad working as intended.
http://forums.netdui...-keypad-shield/
I put the appropriate analog values into the code provided at the beginning of this thread.
The thresholds are chosen to be about mid way between one expected value and the next and are typically 90-100 counts from the expected values so it should be quite reliable.
I've documented a simple mod to this DFRobot LCD Keypad Shield (DFR0009)
The mod gets the keypad working as intended.
http://forums.netdui...-keypad-shield/
I put the appropriate analog values into the code provided at the beginning of this thread.
The thresholds are chosen to be about mid way between one expected value and the next and are typically 90-100 counts from the expected values so it should be quite reliable.
/// <summary>
/// Gets an enumeration of the key press at the current time.
/// Can only be used if the LCD has been initialised with the true parameter.
/// </summary>
/// <returns></returns>
public static Keys GetKey()
{
if (!analogInitialised) throw new Exception("Analog input is not Initialised");
int i = AnKey.Read();
if (i > 910)//expected value = 1024
return Keys.None;
if (i < 90)//expected value = 0
return Keys.Right;
if (i < 290)//expected value = 184
return Keys.Up;
if (i < 490)//expected value = 397
return Keys.Down;
if (i < 690)//expected value = 578
return Keys.Left;
//expected value = 796
return Keys.Select;
}
#15994 ADC value divide by 1024 or 1023
Posted by
on 28 July 2011 - 11:35 AM
in
Netduino 2 (and Netduino 1)
Everything Mario says is correct but I think he missed the question slightly.
The ADC returns a value from 0 to 1023 not 0 to 1024.
0 to 1023 is 1024 different values because zero is a value too.
so ADC value of zero corresponds to 0v and ADC value 1023 corresponds to 3.3v
That is why you divide by 1023 and not 1024.
#15999 ADC value divide by 1024 or 1023
Posted by
on 28 July 2011 - 12:26 PM
in
Netduino 2 (and Netduino 1)
Thanks, CW2 for taking the time to explain that.
Mario didn't miss anything either.
So we should be dividing by 1024 and not 1023.
So...
for an ADC value of "n" (assuming Aref=3.30v)
n*3.3/1024 < voltage < (n+1)*3.3/1024
So to calculate a voltage that represented the ADC value with the least quantising error you need to add 1/2 an LSB to the value.
voltage(mV) = (n+0.5)*3300/1024 quantising error = ±0.5*3300/1024
= n * 3.22265625 + 1.6 quantising error = ±1.6mV
I get what Mario was saying about there being other sources of error eg Aref and conversion error.
Do I have this right CW2 and Mario?
#19019 multiple spi devices (thermocouple)?
Posted by
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:
http://www.dealexcel...eter_p4083.html
This doesn't log on it's own but if you connect it to a laptop or a pc it will log.
Edit:
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.
http://www.dealexcel...eter_p4083.html
This doesn't log on it's own but if you connect it to a laptop or a pc it will log.
Edit:
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.
#17234 AD5206 Digi Pot with SPI code....?
Posted by
on 29 August 2011 - 12:36 PM
in
General Discussion
Hi CableGuy,
I have added some info on SPI to the Wiki since you first posted. I hope you will find it useful.
search for SPI on the wiki.
