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.
I recently got a Netduino Plus 2 and I'd like to develop for it with VS 2012 and NETMF 4.3. I installed the NETMF 4.3 SDK and latest Netduino SDK, created a new project and referenced the SecretLabs dlls as required. I can build the source, but when I try to deploy to the Netduino I get an error that says the device has version 4.2 of an assembly while I'm trying to use 4.3. Is it possible to develop for the Netduino Plus 2 using these software versions, or do I need to downgrade to 4.2? Any advice on getting up and running with VS 2012 would be appreciated. I tried to install VS 2010 after installing VS 2012 and ran into some issues, I'd rather not have to use 2010.
At the moment the conventional development path is VS2010 with NETMF 4.2. Support for version 4.3 is on it's way and with that will come support for VS2012.
You can however develop with VS2012 and NETMF 4,2 - this is what I am currently using and I believe this is being used with SecretLabs (Chris has mentioned he has this working). The only trick is the hoops you have to jump through in order to create a new project. Chris documented the steps in this post.
Hi James,
To target .NET Micro Framework 4.2 using VS2012, open up "Project Properties" and change the target framework to NETMF 4.2.
Once we have 4.3 firmware available for Netduino Plus 2, you'll be able to target NETMF 4.3 as well.
Chris
Supposedly, UDP multicast should be fixed in 4.3. Is there a timeframe on 4.3 firmware support? I'm waiting for UDP multicast to support uPnP / DPWS. Thanks!
Supposedly, UDP multicast should be fixed in 4.3. Is there a timeframe on 4.3 firmware support? I'm waiting for UDP multicast to support uPnP / DPWS. Thanks!
We're working on the update to NETMF 4.3, but it will take a bit of time to get up and running; it's a much bigger upgrade behind-the-scenes than 4.1->4.2 was.
I'll post an update once I have good dates.
Chris
Thanks for the reply Chris; looking forward to being able to use the Netduino for my home automation projects. On another note, is OutputCompare-like (GHI) functionality in planning by chance?
Thanks for the reply Chris; looking forward to being able to use the Netduino for my home automation projects. On another note, is OutputCompare-like (GHI) functionality in planning by chance?
With gen2 of Netduino, we have lots of space in flash. This is certainly something we could include.
What are your applications for such a feature? Are you essentially just looking for a long array of clocked signal levels? We'd want to make sure we implemented it in a way that worked well for a large variety of applications.
Chris
What I'm trying to accomplish (I did on the Fez Panda II) is to output a bitstream to an infrared LED. The bitstream uses different pulse widths for 0 (1500ms) and 1 (500ms). So yes, a long array of signal levels, but not clocked, some need other widths, like 700ms. OutputCompare does the job perfectly, but that's a rival platform ofcourse ;-) Does this make sense?
In respect to the netmf 4.3; I'm hoping UDP multicast is fixed so DPWS will finally work on my NP2 :-D
The bitstream uses different pulse widths for 0 (1500ms) and 1 (500ms). So yes, a long array of signal levels, but not clocked, some need other widths, like 700ms.
Perfect, thanks. An array of signal levels with pulse width... Would this type of feature be useful to others as well?
Also...would you want the pulse widths in milliseconds or microseconds?
The tricky part would be working this into the multitasking NETMF framework. Unless a dedicated timer was used to interrupt NETMF to precisely transition the signals, you'd either end up with a potentially long-blocking-function or non-precise timings.
BTW, with 1.5s and 0.5s...those are pretty long pulses. Have you thought of just doing this in C#? It would only take a few lines of code to accomplish this, and you could wrap it up in a simple class. Timings at the microsecond level would require native code.
Chris
Made a mistake in explaining, sorry. The timing would make sense to have in us, and my 0's are 1.5ms and 1's are 0.5ms. The signature of OutputCompare reads:
public void Set(bool initialValue, uint[] timingsBuffer_us, int bufferOffset, int bufferCount, bool bufferRepeating);
I haven't looked at the way GHI has implemented this, but my best guess would be transition to native because of timing.
By my measurements (rough at best), the shortest pulse is around 6uS and the longest is just over 356uS. A full packet consists of 50 transitions, for a total of 1.35ms in transmission time. I'd be totally okay with blocking for that long.
I could write the native code to do this, but I just moved and no longer have access to a scope or a logic analyzer
For a concrete example of the signal I would like to generate, check out this picture, columns E and K. Again, take the values with a grain of salt, they were captured with this code running on a Netduino Plus 2.
E: Good news and bad. Good: I went hunting and managed to dig up an Open Bench Logic Sniffer, so I now have a decent LA to use! Bad news: I think I killed my netduino. (I'll start another thread for that.)
E: Fixed by erasing the app! MFDeploy wouldn't do it, but NetduinoUpdate did it just fine.
To me it looks as if the support for IGMP, which you need to register at IP multicast groups, has been specificly disabled for the Netduino products. Am I right? And if so, when can we expect to get IGMP support in the IP stack to register at IP multicasts groups?
I've been waiting since the early Netduino Plus 1 days to get this feature.... :-(
A few of the lwIP features are disabled either for stability reasons or because they are seldom-required and take up too much RAM.
There's more RAM on Netduino Plus 2's microcontroller (STM32F4) vs. Netduino Plus 1 (SAM7X) so we can revisit this in the future; in the meantime you can grab the source, modify it, and recompile the firmware with the features you desire.
I'm already using a Netduino Plus 2, I just said that I was waiting for the feature since the early Neduino Plus 1 days. Btw, I own a NP1 as well ;-)
You are right, since it's all open source I really could compile my own version of the firmware with my desired features enabled. I'll have a look at it. Thanks for the hint. But it be awesome if it would make it's way into a future official release. Keep up the good work.