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.
We're working on it, and hope to have it fixed in v4.1.1 alpha 4 (by the weekend).
Yipee, the weekend is soon! In my mind I imagine this release will solve all my problems... but I know it won't so here is my Wish List! Others can feel free to post their own!
Wish List (in order of my priority):
NetBios support
One-Wire support
Prevent Outputs from cycling at startup; All Outputs should remain off until set to on (true)
Utility Function to Set System TimeZone
Add a Math.Log function
More of the .NET Micro Framework (maybe we could have 2 firmware versions (small and big)
Fix for the .NET MF Garbage Collector that leads to the OutOfMemory Exception
Prevent Outputs from cycling at startup; All Outputs should remain off until set to on (true)
-Valkyrie-MT
I second the idea to disable GPIO's set to high (true) when starting the Netduino device and instead have the option to have them set low (false). This will save me from adding a bunch of PNP transistors.
I have got to throw my vote on the Misc. Bug fix.
Not being able to unplug and plug in the ethernet port on the N+ is a MAJOR show stopper in my book. Until this and other significant networking/general bugs are fixed the rest of it is just academic in my opinion.
Seriously, I know it's great to have more memory, new features, etc.... I myself have even pushed for a few, but at this point, I think it is most important to put more development time into getting the features we already have working, and working correctly.
Our internal focus right now is on fixing a few bugs in the .NET MF core and Atmel port...and integrating a few new features.
The current roadmap for v4.1.1 is:
- Variable-bit SPI -- done
- I2C internal address (repeated start bit) support -- done (coming in alpha 4 this weekend)
- Bugfixes (SPI/D2 glitch, lwIP, garbage collector)
We're also getting v4.1.1 posted in an online repository.
Next on the short list are:
- BitBanger
- OneWire
- PWM enhancements
- Etc.
Chris
Our internal focus right now is on fixing a few bugs in the .NET MF core and Atmel port...and integrating a few new features.
The current roadmap for v4.1.1 is:
- Variable-bit SPI -- done
- I2C internal address (repeated start bit) support -- done (coming in alpha 4 this weekend)
- Bugfixes (SPI/D2 glitch, lwIP, garbage collector)
We're also getting v4.1.1 posted in an online repository.
Next on the short list are:
- BitBanger
- OneWire
- PWM enhancements
- Etc.
Chris
No progress at all on the Ethernet pore disconnection problem? Seriously, I can't even disconnect my laptop from it and leave it running for a while - It will crash the moment I reconnect it.
No progress at all on the Ethernet pore disconnection problem? Seriously, I can't even disconnect my laptop from it and leave it running for a while - It will crash the moment I reconnect it.
Hi Charles,
We're working on it for you... The networking ("lwIP") code was written by Microsoft, Atmel, and the lwIP open source project (and it's pretty huge). Community member Pascal has been working on a few fixes too, which we're hoping to integrate soon.
I agree with Charles, Not being able to unplug and plug in the ethernet port on the N+ is a MAJOR show stopper.
So my vote is the Misc. Bug fix.
While you are at it, perhaps you could re-think your test cases for the Plus? There are probably lots of "edge conditions" like ths where the networking on the plus could fail. I don't know if you are setup to do automated testing (including regression testing) when you make changes (of any kind, hardware, firmware, MicroFramework etc.). Test driven development can really pay off in the long run, even if it does take a little longer to get a new feature out the door.
Odd that you care so much about the NetBios name. It's just a name, it takes up space and it's somewhat redundant if you use a static IP. Meh.
Anyway I just want to add my 2 cents: Adding custom functionality to the Netduinos seems very tempting at first glance. The more the marrier. But you should be careful with this line of thinking. Custom useful code for Netduino will profit us/you in the short run. And most netmf manufactors are doing just this, these days. (Creating a better, more useful platform for their own customers.) In the long run however, this will create a diverted netmf. Perhaps even branched. Which in turn will eventually break down the netmf and thereby also the Netduinos.
The additions such as One-Wire, Math.Log etc. are great though. But they should be commited to the netmf 4.2 repository as primary goal. As secondary goal we could discuss whether they also should be added to the Netduino 4.1 or if you should offer a premature version of the netmf 4.2. A premature 4.2 would be interesting anyway and it would fit nicely on your wish list
My personal wish list:
- Ethernet bug fixing
- "Option 3" for saving custom data on board. (Yeh I know, this is custom non netmf functionality as well.)
- More of the .NET Framework. (Whatever that is.)
Illishar,
We've actually been working with Microsoft on standardizing some of the add-on features of various .NET MF boards. There's a whole commitee involved and hundreds of e-mails going back and forth about PWM alone
The one thing we've been very consistent about is contributing bugfixes and enhancements back to the .NET MF core where possible. As for add-on features, they're open source so other board manufacturers are welcome to adopt them as well.
Chris
Sounds very reassuring. I thought GHI was responsible for the PWM though. (But perhaps that's the reason for all the angry mails? ;p
I've considered joining as well. I guess I could take the time to implement a few small functions or overloads. Eg. Math.Log, Math.Sin, System.BitConverter, the non allocating overload of the UTF8Encoding etc.
I've considered joining as well. I guess I could take the time to implement a few small functions or overloads. Eg. Math.Log, Math.Sin, System.BitConverter, the non allocating overload of the UTF8Encoding etc.
Hold off on the Math.Log... I found some GREAT public domain stuff that I thought did not work, but it turns out it does in the emulator, but not the netduino. You might want to start with this first.
1. Bugfixes. (ethernet disconnect/reconnect. ).
2. More memory.
3. More framework(I can live without most of the .net framework functionality. A function here and there would be nice.)
How about a math library compromise...
Create a miniature math library with only a few key math functions that is included in the actual firmware. Then create a complete math library that adds all the missing functions but as a DLL that can be added to projects as needed bud doesn't eat the flash space if it is not.
Could that be done?
I agree - Could someone please explain what exactly the advantage of NetBIOS support would be?
I am working on a project that could be sold to consumers without any IT knowledge. Your everyday consumer doesn't know anything about static IP addresses or DHCP. Let's say my product uses a Netduino Plus with DHCP. That's nice, but how is the consumer going to find out the IP address of the device if the device's only user interface is a web page it hosts? You and me might log into our routers and look up the DHCP IP address assigned to the router, but that is over the heads of most consumers.
Now let's say that you have Netbios implemented and you give the Netduino Plus a name (e.g. "SuperWidget"). Then in your setup instructions or manual you can tell the consumer to open their Internet browser and go to the website "http://superwidget/index.html" to configure or use the device. In my case giving the product a Netbios name is fine because there will only be one of these devices on a LAN inside a house.
Create a miniature math library with only a few key math functions that is included in the actual firmware. Then create a complete math library that adds all the missing functions but as a DLL that can be added to projects as needed bud doesn't eat the flash space if it is not.
Could that be done?
Ditto. That is definitely a good way of doing it. Exactly like you said, just make a new project of type Class Library and target the .NET Micro Framework version you want to target. Let's say you call the project "MathLib". Slap in your code and then build. Then whatever project you want to use that "MathLib" library in, you'd just add a reference to "MathLib.dll" in your project.
It's probably best done this way instead of putting it in the firmware. Otherwise it would eat up space and not everyone needs it included in their projects.
My personal wish list:
- Ethernet bug fixing
- "Option 3" for saving custom data on board. (Yeh I know, this is custom non netmf functionality as well.)
- More of the .NET Framework. (Whatever that is.)
The one thing we've been very consistent about is contributing bugfixes and enhancements back to the .NET MF core where possible. As for add-on features, they're open source so other board manufacturers are welcome to adopt them as well.
Chris
