The Netduino forums have been replaced by new forums at community.wildernesslabs.co.
This site has been preserved for archival purposes only
and the ability to make new accounts or posts has been turned off.
Eric Falsken's Content
There have been 6 items by Eric Falsken
(Search limited from 30-November 20)
I've got a big problem with the new Netduino Plus 2. The official Arduino wireless, prototyping, Wi-Fi, and ethernet boards all route MOSI/MISO to the ICSP header. It seems like the Arduino team has standardized using the ICSP header for all SPI data. While at the same time, the Netduino team has dropped the classic ICSP for this new mini-JTAG header. And, as far as I know, the only shield that routes those pins anywhere useful is the MakerShield.
If you guys wanted to make an Arduino R3 (1.0) compatible board...I hate to break it to you, but you failed.
That is a good question. There's enough space left that you could actually run one app which flashes and loads another app. Not an overnight thing, but we have allocated a little bit of space for future potential on-chip storage...so that might help along the same lines.
The other thing we may be able to do with this board: local deployment/debugging over Ethernet. There were some issues with the lwIP implementation that prevented this, but it may be possible with NETMF 4.2/4.3.
What about using the SD card for flashing new deployments? If our user code saves the firmware to the SD card and sends a reset signal, could the firmware auto-deploy user code or firmware from that image?
I can confirm this working. After installing the MF 4.3 SDK, Visual Studio 2012 shows all of the .NET Micro Framework versions, so it must include the multi-targeting pack all the way back to 4.2 and 4.1.
I was also able to open my old Netduino project and build+deploy+debug with no problem.
The only thing missing are the Netduino-specific project templates, which you can copy from MyDocuments\Visual Studio 2010\Templates\ProjectTemplates to MyDocuments\Visual Studio 2012\Templates\ProjectTemplates.
Thanks for your post, I got my LCD displaying text.
However, I was wondering if anyone could shed some light on a weird issue I've seen.
I found that if I instantiate my DfRobotLcdShield class with the class type (instead of var), I just get garbage on the display.
For example, this works fine...
var lcdshield = new DfRobotLcdShield();
This does not (produces garbage output on the screen)...
DfRobotLcdShield lcdshield = new DfRobotLcdShield();
I'm not opposed to using var, but two things...
Just plain curiass as to why this is.
I would like to make a global field for the LCD but from my understanding, var can not be used as a global field.
Replacing it with "var" should not make a difference. But I've noticed many times that simply resetting it at the wrong time does not "flush" the buffer. Try pressing the reset switch when you see garbage on the screen, or remove power and plug it back in again. This clears up the screen 100% of the time (for me). Try putting a delay of about 20ms before writing anything to the display. It takes a short time to initialize before it's ready to listen.