Mike P's Content
There have been 41 items by Mike P (Search limited from 20-April 23)
#17499 Wiki tutorial on SPI
Posted by
on 04 September 2011 - 01:37 AM
in
General Discussion
Hi Mario,
Thanks for adding the example.
I think that a tutorial on using the 74HC595 is worthy of being a wiki topic in its own right.
Can I suggest that you copy the tutorial to a new topic and link to that from the SPI configuration topic.
This bit is not quite correct:
"In the below picture there are the four possible combinations of Clock_Edge (NCPHA) and Clock_Idle (CPOL)"
The NCPHA and CPOL bits used by the processor to control the SPI transfer do not map directly to the Clock_Edge and Clock_Idle parameters.
It is not true to say that Clock_Edge==NCPHA. If CPOL==1 then Clock_Edge = !NCPHA
It is correct that CPOL and NCPHA select 1 of four SPI modes and Clock_Edge and Clock_Idle have the same function.
It would be better to show an excerpt from the 74HC595 datasheet and highlight what to look for.
#17521 Wiki tutorial on SPI
Posted by
on 04 September 2011 - 12:31 PM
in
General Discussion
My English could be better and it is my firt language.
What I meant to say was
CPOL and NCPHA select 1 of four SPI modes and Clock_Edge and Clock_Idle also select one of 4 SPI modes.
#17966 Where is DateTime?
Posted by
on 14 September 2011 - 04:12 AM
in
General Discussion
Have you seen this post?
http://forums.netdui...uino-date-time/
http://forums.netdui...uino-date-time/
#17567 What is this called?
Posted by
on 05 September 2011 - 09:17 AM
in
General Discussion
This would be my guess.(see labels on photo)
The GND plane is pretty obvious - large filled area.
There is a cap between GND and what I would assume is VCC
VCC is also supplied to one pin of the sensor via a resistor. This would be a current limiting resistor for the LED side of the light gate.
The detctor side appears to have a connection to VCC and GND and two ouptuts. These are normally called A and B and are 90° out of phase. This allows you to work out which direction the sensor is moving.
If you think of the output as a 2-bit binaty value then the signal would 0-1-3-2 going in one direction and 2-3-1-0 in the other direction.
#17702 What is this called?
Posted by
on 07 September 2011 - 01:42 AM
in
General Discussion
This would be a guess but there was probably another sensor conected to that 3 pin connector. Maybe a home position sensor or something.
The decoupling cap serves to smooth out the power supply. It acts like a shock absorber on the supply voltage. Without it small spikes on the power supply would be created whenever loads were switched on and off and these spikes might be transfered to the output signal.
The spikes on the output could be mistaken for real output transitions and cause the encoder to lose its count.
I posted some code on the Wiki last night for a rotary encoder. Chances are that it would work fine with your strip as well.
http://wiki.netduino...oder-Input.ashx
The decoupling cap serves to smooth out the power supply. It acts like a shock absorber on the supply voltage. Without it small spikes on the power supply would be created whenever loads were switched on and off and these spikes might be transfered to the output signal.
The spikes on the output could be mistaken for real output transitions and cause the encoder to lose its count.
I posted some code on the Wiki last night for a rotary encoder. Chances are that it would work fine with your strip as well.
http://wiki.netduino...oder-Input.ashx
#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
#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
#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);
}
}
#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.
#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
#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.
#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.
#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.
#17750 SPI bug report (NETMF bug)
Posted by
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.
http://netmf.codeple...m/workitem/1219
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.
Feel free to visit codeplex and vote.
http://netmf.codeple...m/workitem/1219
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.
#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.
#16003 PWM demystified
Posted by
on 28 July 2011 - 12:50 PM
in
Netduino 2 (and Netduino 1)
Since noone has offered ant solution to this, what about using I2C or SPI bus to do it?
You could buffer up a command to send 1024 bits and change the number of 1s to adjust the pulse width.
I don't know what control you have over the bus speed though.
#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
#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
#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
#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
#18382 Need Documentation for Netduino(SDK)
Posted by
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.
#19131 multiple spi devices (thermocouple)?
Posted by
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).
