Emilio x64

The "Microsoft Extensible Emulator" is part of the Visual Studio IDE AFAIK. But it is great in allowing you to mimick your end device when you still don't have hardware (I have a design but I am testing some concepts).

The MAX7219 emulator code I wrote myself because I wanted to see the state of the chip during debugging (just as if I had a real emulator pOD on a real device) but I have to fix it based on your comments (the NoOp). However, it goes only as far as keeping track of the register values, state and notifying the UI to update the UI accordingly. It does not include a real 7-segment emulator that would ideally read the status of the A-G,DP segment output pins and display accordingly. Perhaps some day I add it, in the meantimeI have to fix the emulator code and find some suppliers for my 7-segment displays

Thanks for the clarification, I will change my firmware, I guess you recommed doing the Chip Select (SS) manually rather than letting the .NET Microframework's SPI software do it, right?

By emulation I meant the .NET Extensible Emulator where you create a user interface to mimick your device. That's what I did, created a winform to mimick the faceplate of my device where I could interact with buttons (pushbuttons and a dual concentric encoder) as well as a separate winform that would show me in real time the current state of all registers of the "emulated" MAX7219.

I am also using a 7219 but since I don't have hardware yet (waiting for the official 4.3) I have worked with emulation by using the Extensible Emulator. Now I read this so to save me some suffering could you clarify this for me to make sure I got it right?

• I understood from the 7219 that the NOOP was used to shift to the slave 7219 but since it was not explicitely mentioned I was sending the NoOP as the first 2 bytes: (a) NOOP(empty_data) and then ( COMMAND(value). However, reading this thread it seems I had it wrong, so you say IF I want to write to the slave 7219 I would send the COMMAND(value) I need and then follow it by NOOP(dummy)  (two 16 byte transactions but with the NOOP in the 2nd transaction), right?
• Commands are always 16 bits, address plus data, right?
• Emulation is not the same as real hardware, according to what I read here, letting the MF SPI s/w do the Loading won't work in this setup right? so you recommend doing the SS (Chip Select/Load) manually making it active before the 2 bytes are sent and inactive AFTER the two bytes are sent.
• A write to the slave 7219 would require only one LOAD activation/deactivation for the 32 bytes (Command[value] + NoOp[dummy]) OR do it for every 16-bit (2 byte) transaction?

Another problem I just noticed in my setup is that each 7219 drove a 4+2 digit setup (better than 6 individual digits) but unfortunately the 4-digit 7Segment uses 35mA and the 2-digit 7Segment uses 25mA which I guess wouldn't work well with a single Iset resistor (one set would look dimmer than the other). So I will have to probably drive the two 4-digit 7Segments by the main (same current limit) and the two 2-digit 7Segments by the slave 7219 (same current) with the complication that writing a value on either set would require two transactions (one for main to fill the first 4 digits and one for slave to fill the remaining decimal digits) :*(

That's the firmware that is on the netduino device or the one that one installs aside VS.2013 (SecretLabs*.dll) ?

Still having problems trying to get my desktop application's Broadcast UDP packets to be received by the emulated netduino on the emulator. Trying to isolate the problem, are there any known issues like "Emulator doesn't have Ethernet connection" ? Is there a way to simulate ethernet cable (un)plugging in the emulator?