- Netduino Forums
- → Mike P's Content
Mike P's Content
There have been 41 items by Mike P (Search limited from 24-May 23)
#25669 Anyone is interested on a high-end acquisition shield?
Posted by Mike P on 18 March 2012 - 03:45 AM in General Discussion
#19787 CANBus ...
Posted by Mike P on 26 October 2011 - 03:31 AM in General Discussion
#19568 SPI, Netduino, and RGB LED Strip
Posted by Mike P on 21 October 2011 - 10:02 PM in General Discussion
#19565 SPI, Netduino, and RGB LED Strip
Posted by Mike P on 21 October 2011 - 09:08 PM in General Discussion
#19513 SPI, Netduino, and RGB LED Strip
Posted by Mike P on 21 October 2011 - 09:38 AM in General Discussion
#19502 SPI, Netduino, and RGB LED Strip
Posted by Mike P on 21 October 2011 - 07:28 AM in General Discussion
#19481 SPI, Netduino, and RGB LED Strip
Posted by Mike P on 21 October 2011 - 12:56 AM in General Discussion
#19465 SPI, Netduino, and RGB LED Strip
Posted by Mike P on 20 October 2011 - 06:17 PM in General Discussion
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 Mike P on 20 October 2011 - 06:07 PM in General Discussion
#19429 SPI, Netduino, and RGB LED Strip
Posted by Mike P on 20 October 2011 - 10:45 AM in General Discussion
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.
#19131 multiple spi devices (thermocouple)?
Posted by Mike P on 13 October 2011 - 08:33 PM in General Discussion
#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.
Regards,
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.
Regards,
Mike Paauwe
#19019 multiple spi devices (thermocouple)?
Posted by Mike P on 11 October 2011 - 06:20 AM in General Discussion
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.
#18893 CANBus ...
Posted by Mike P on 07 October 2011 - 07:57 AM in General Discussion
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 Wiki
Using-SPI-Write-and-WriteRead
#18382 Need Documentation for Netduino(SDK)
Posted by Mike P on 24 September 2011 - 10:11 PM in General Discussion
#18056 Compiling firmware
Posted by Mike P on 15 September 2011 - 07:49 PM in Netduino 2 (and Netduino 1)
#18044 Compiling firmware
Posted by Mike P on 15 September 2011 - 12:55 PM in Netduino 2 (and Netduino 1)
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:
http://forums.netdui...dpost__p__10332
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)
#17966 Where is DateTime?
Posted by Mike P on 14 September 2011 - 04:12 AM in General Discussion
http://forums.netdui...uino-date-time/
#17965 3.3v, 5v, Various Ports and Components, oh my.
Posted by Mike P on 14 September 2011 - 04:09 AM in General Discussion
#17953 Combining Pins
Posted by Mike P on 14 September 2011 - 12:30 AM in General Discussion
I wonder if this could be ported into the Netduino firmware? They also have an outputCompare class that looks pretty useful.
http://www.ghielectr...tion/Index.html
Oh well...
#17952 EM406a not fixing satelites
Posted by Mike P on 14 September 2011 - 12:08 AM in General Discussion
#17750 SPI bug report (NETMF bug)
Posted by Mike P on 08 September 2011 - 11:40 AM in Beta Firmware and Drivers
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.
#17739 Pinout Cards
Posted by Mike P on 08 September 2011 - 04:29 AM in General Discussion
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
- Netduino Forums
- → Mike P's Content
- Privacy Policy