Edit#3     BLINKY LIVES !!!!

 

When I purged the broken (Release 4.1) SecretLabs libraries that I had somehow acquired, Blinky works including single-stepping from MSVC.  This is running on firmware compiled from the 4.2.1 source using the free GCC compiler (instead of the $5000 one-computer-only RVDS one) following these instructions ( posts for context ) from ziggurat29 (monster thanks again, buddy!).

 

Details:

Initially I wasn't able to get any of the SecretLabs assemblies to load except the diagnostic (it complained there was no SecretLabs.NETMF.Hardware; so it refused the SecretLabs.NETMF.Hardware.Netduino DLL I'd imported -- huh?).  So I dumped them, spent a couple minutes with the board schematic and blinked 

Microsoft.SPOT.Hardware.Cpu.Pin.GPIO_Pin10 instead of SecretLabs.NETMF.Hardware.Netduino.Pins.ONBOARD_LED

It worked fine!  Then I switched back to the compiled source (I was debugging with the official download firmware once I realized that had the problem too after I tried to switch back to 4.2 QFE1 SDK and Porting Kit and Netduino SDK) and verified that worked.  Finally, I tried switching to the SecretLabs ONBOARD_LED, and that worked, too.

 

While Visual Studio 10 was linking, I noticed a message saying it was downloading SecretLabs.NETMF something -- presumably that's why it worked.  That reminded me that I'd seen that message flash up when I first ran MSVS10 after switching back to QFE1.  I'm wondering if that's where my 4.1 SecretLabs assemblies came from that have been messing me up the last day or so.

 

At a programming conference long ago I met a programmer who had named his business "Abracadabra Typesetting" to be first in the Yellow Pages listing (I told you it was long ago).  He'd discovered that name was a big mistake: customers told him it made them afraid his business might go "Poof!".  These automagical downloads are charming when they just work, but now every time I see it, I'll worry what might have broken.  At least give us a way to know what was downloaded if we miss the 5-second popup.

 

Anyway: all's well that ends well.  I can finally make the firmware changes and give my boss what he is clamoring for (just not eager-to-buy-a-$5000-tool-for-what-should-have-been-a-small-project clamoring).  I suspect we aren't the only ones who'll be very happy about this capability.

 

Howie

 

==============  OLDER, FOR BACKGROUND ONLY  =====================

 

Edit#2: In trying to go back to 4.2 QFE1, I clearly have gotten some Netduino 4.1 assemblies somehow.  The version of Microsoft.SPOT.Hardware that two of them ask for (4.1.2821.0) is the exact version in my 4.1 assembly.  I am trying to get the SecretLabs 4.2 references to link properly instead of the 4.1.  Then I should be developing on top of an interop-ready system using the free GCC compiler; yah!

 

Edit #1

Hi --

 

I'm having a related problem.  After uninstalling the QFE2 SDK and PK and installing 4.2 QFE1 versions, a Blinky project created in my MS Visual Studio 10 downloads but refuses to run, not only on the GCC-compiled version that I built following ziggurat29's procedure here , but even on the stock 12/3/2012 firmware download (NetduinoPlus2_Firmware_4.2.1.2.dfu).  Visual Studio apparently is still looking for the wrong version of modules: Debug output at the end of this.  

 

Chris, I think somewhere you mentioned unzipping an update over SecretLabs SDK Visual Studio sources.  Can that work in reverse, or do I need to uninstall and reinstall Secret Labs SDK VS?

 

Thanks!

Howie

================  Debug output on attempted download  ===================

(note cleaning and rebuilding got rid of these errors, but it still failed to initialize after the download)

 

 

...
I wonder who's bright idea it was to name that assembly "TinyCore"? Whoever it was, I'm sure they're still giggling.

Mark

George Orwell's. Right after he wrote http://en.wikipedia....een_Eighty-Four where the "Ministry of Truth" wrote propaganda and changed records to match the current Party line, and the "Ministry of Love" tortured and brainwashed you ;-)

Have a good weekend!
Howie

Hi --

 

Job

Use Netduino Plus2 to make an Ethernet-to-specialized-serial interface for industrial control.  

 

Killer problem

Each round trip takes over 20 milliseconds; it needs to be 1-2.  

 

Analysis

I think the delay comes because my control program is a simple loop running in one thread waiting for Ethernet data.  It sends and receives to the industrial HW on serial in ca. 1 MS; then sends results back on Ethernet.  Tracing shows the TCP/IP stack in a different thread, and I've read that each thread transition waits for a 10-millisecond clock tick.  Hence, the killer problem.

 

Possible solutions?

• I don't think e.g. making my control code "event-driven" would make a difference, but I'm not an experienced C# programmer.  Any way to get either C# (or all-C++ interop code) into the same thread as the Ethernet I/O?  
• I am recompiling the whole software just to include my tiny interop changes.  Is there some build option or high-level code switch to disable the multitasker and just have Ethernet and user code wait for each other?
• If I ping the Netduino Plus2 before the C# program is downloaded, my laptop says it responds in less than a millisecond.  It's that performance I need: 500-1000 packets/second.  I'll happily make a little tweak, but I'll also dump  the whole .Net infrastructure (now that I can use JTAG debug); if that gets the job done quickest.  (For example, just hook the ping code -- the message size is perfect -- directly to my interop control code, and never load a C# program.  
• Or I'll put completely different software on the board,
• Go to different hardware.
• ...

Argument for a tweak (if one is possible) is that bare-metal programming is perishable; in these few months I already had to rewrite my direct hardware control of the Atmel ARM UART in Netduino Plus to the the ST UART in Plus2.  The dotNetMF might be a way to future-proof the application.  However, it first has to work in the present ;-)

 

Suggestions anyone?

 

Howie