Excellent video, Thanks for sharing, When I work with serial port and programming, I use this powerful free tools: http://www.der-hammer.info/terminal/ Pascal

Excellent, I really like the form factor. Pascal

What about a mesh of Netduino Mini paired with Atmel ATMEGA128RFA1s? And maybe 6lopan?

Chris

I see a lot of discussion arround IOT about one MCU versus two MCU on a single node. Like Ethernet Shield, we can use one MCU as the main brain, and the other for networking communication.
On a wireless node, we are very concern by the low power consumption. And some people can be say, why use a ARM MCU in this case and don't use the AVR for sensor communication also (probably enough in most of case) ? By using two MCU, you need to update two firmwares also.

But it can be a easier first step

Though ?

Pascal

My dream could be a mesh of Netduino Mini associated to ATMEL AT86RF231, all accessible over Internet by a NetduinoPlus/AT86RF231 as a bridge It should be a real Internet of Things revolution ... Pascal

Hello Szymon, ATMEL provide very nice and sheeper chip for 802.15.4. I personally use AVR-RAVEN DevKit. But 802.15.4 is only for layer 2. 6lowPAN is a IPv6 stack which can work over 802.15.4, because it change header of IPv6 by a compressed version. So, with 6lowPAN, you must use IPv6. What's the relation with uIP ? uIP is the smallest IPv6 stack and it's certified by "IPv6 ready". lwIP is not certified, bigger and only experimental. Now, why we need IP and why is better than other wireless technology. A good start for this reflexion would be IPSO Alliance white papers : http://ipso-alliance.org/ Hope your help, Pascal

Hello Netduino Community, Some information about uIP, uIP is a very small open-source TCP/IP stack written by Adam Dunkels from Swedish Institude of Computer Science. Same author as original lwIP. This stack can run also on 8 bits MCU. The official uIP web site: http://www.sics.se/~...x.php/Main_Page This site is dedicated to the first version uIP and it support IPv4. In parallel, Adam Dunkels work on a mini OS named Contiki: http://www.sics.se/contiki/ In this mini-OS, you can see a more up-to-date version of uIP stack for IPv4 and IPv6. This stack is IPv6 ready. Compare to IPv6 support on lwIP which is experimental. It doesn't support Dual Stack, so you need to choice between IPv4 and IPv6. uIP can be used without Contiki. Here is a example of porting IPv6 uIP on Arduino without Contiki using a enc28j60 chip: http://sites.google....ipv6ethershield A little question to Netduino Community : What's your priority regarding porting IPv6 or IPv4 ? Regarding this, one very important information: If you plan to use low-power wireless like 802.15.4, IPv6 can be a good choice because of 6lowPAN. 6lowPAN use header compression to be compatible with 802.15.4. The dream is to be able to communicate with all devices, wire and wireless, simply by using IP. IPv4 over 802.15.4 is impossible due to low MTU size of 802.15.4 frame. Pascal

On the topic of EEPROM--are you wanting actual EEPROM (read/write tons of times) or just a few KB of on-board storage for ocassional use?

Chris

Chris, when you say that, do you plan to use other feature than ExtendedWeakReference ?

A faster processor would be nice. After reading CW2's writeup about how it's currently not quite fast enough to really do all the one-wire stuff (among others) even in C++ native code. Come on, you guys can beat the FEZ can't you?

For my point of view, OneWire issue is not related to processor speed. It's more related to C# latency inducted. So, the solution, like other vendors, is to provide a OneWire feature in native code and a library in C# to use it.

I use onewire with a AVR 328p at 8 Mhz !!!

My 0.2cents,
Pascal

On the topic of EEPROM--are you wanting actual EEPROM (read/write tons of times) or just a few KB of on-board storage for ocassional use?

Chris

In my case, currently, it's just to have persistant information like IP address ... So just a few KB of on-board storage would be suffisant.

Pascal

Hello Netduino community, I search for a more powered device needed for a new project (IPv6 network project), I would like to use multiple netduino (when it will be ethernet ready), and one of that device, Here is the needed features : - .NET micro framework ready - 1MB of flash or more, same for RAM - Firmware open source, because I need to write some native code for performance and low level network features. - Ethernet, enc28j60 prefered, because of lwIP compatibility I found a lot of devices, but I don't know if the firmware are open source or not Thanks in advance, Pascal

I will admit I'd love to see a small EEPROM. The rest I don't think are really necessary (I mean the netduino already has a crapload of memory and flash compared to the arduino) not that I'd say "no" if there's more - more is (almost) always better! Onboard ethernet I think is unnecessary as long as its supported in the firmware - there are too many projects that won't use ethernet to warrant having it on the board. As long as its in firmware it can be "aftermarket".

However, if you are seriously considering an "ultra" style board I wouldn't say no to more GPIO pins.

Considering Ethernet feature is already avalaible on the ship ... Why not to have the possibily to use it ? Perhaps, to be open, just make the pins available to connect a magjack in case of you want to use it and the corresponding firmware.

Pascal

Perhaps we should build a Netduino "Ultra" with MBs of on-board RAM/FLASH and on-board Ethernet?

Chris

It would be perfect !!!! + EEPROM

Escpecialy if the Ethernet is compatible with lwIP,

Pascal

Hello, After some research, for me, your issue is more related to transactionID than ClientHardwareAddress. But it can be related to both in this case. ClientHardwareAddress is present in DISCOVER request. Usualy, a DHCP server remember each request by using the transactionID. But, it's seems that lwip change this option and use a different transactionID for DISCOVER and REQUEST. So, normaly, the DHCP server already have the ClientHardwareAddress because of DISCOVER request. But in this case, it can't because the transactionID was changed. For the server point of view, it's a new request. So, I think that it works with Microsoft DHCP server, because it use MAC Address at MAC level if the ClientHardwareAddress is not available. After some look at dhcp.c source, I also see that transactionID is change only after a multiple tries. So, I need to debug more to understand why multiple tries occurs in a normal situation. When I receive my JTAG interface, I will modify lwip to not change the transactionID between DISCOVER and REQUEST (if I found a way to do it). And I will send you a firmware to test. Pascal

Hello,

I have tested the last version with this code :

NetworkInterface[] networkInterfaces = NetworkInterface.GetAllNetworkInterfaces();
networkInterfaces[0].EnableDhcp();
networkInterfaces[0].RenewDhcpLease();

Netduino is already configured to use DHCP, the first request works fine. But, the renew doesn't works.
I'll wait for debugging capability to do more testing,

Also, I made some tests to evaluate the posibility to implement a little TCP/IP stack completly in managed code. It would be a good way to learn more by a easier way. The only bad effect would be the performance. Regarding FLASH/RAM use, it probably near the native code size. First implementation will be for the enc28j60 chip.

I'll let you know about it ...

Pascal

Hi Pascal,

yepp, seems that it is working with Microsoft DHCP server. I tried it with the AVM box as well as another Linux box and had no luck. Not sure who could give a try to add this option, should not be a big deal.

Can you do another test? What if you try to renew the lease in your application? Think of a module that you will plug to different networks while it is running. Is this working? I have configured the IP to 0.0.0.0, then I get an IP address from my DHCP... then I disconnect from network... connect again and renew the lease and get 0.0.0.0. :-(

Michael

Hi Micheal,

Unfortunatly, I'm traveling this week. Without possibility to test. I will try next week-end if anybody have done it before.

Pascal

Seems that the clientID = 1 is missing in the REQUEST (step 3). I have monitored other DHCP requests and all are sending clientID = 1 which means that the DHCP server should take care of the MAC address (as far as I understand the DHCP protocol).

Michael

Hi Michael,

You probably right concerning clientID, but it works fine with my Windows Server 2008 R2 DHCP server. And I use a reservation to fix my NetduinoPlus address.

Another strange behavior is that DHCP request take the configured static IP address to forge the IP packet. In case of this ip address use another subnet, it could be a issue. So, I have define 0.0.0.0 for static IP, subnet and gw.

If we definitly conclude that ClientID must be set, it probably not a big deal to fix it.

Pascal

Hello Chris,

Next week, I will receive these components :
http://www.coolcompo...uksdbumahtmuqg5
http://www.coolcompo...?products_id=83

W5100 is very nice, but limited (only ipv4, only 4 concurrent connexions ...),
Enc28j60 is more low level, only MAC, but we can use lwIP.
But, lwip seems to be to big to run on Netduino. I will work on uIP instead of lwIP and see if it's possible to run on .net MF ...

My first issue is to be able to compile the firmware. I currently use a eval version of RVDS 4.1 with success, but it's a eval version. With GCC, we probably raise a out of flash memory very quickly

Pascal

I just receive an offer for MDK, Keil, 3900 euros without taxes !!! Is RVDS cheaper ?

Pascal

Thanks EdO!

I was under the impression that the analog pins were "general purpose", as far as them being able to act as digital? Was I mistaken?

The "brick shield" im using makes it pretty obvious that mapping the LCD pins to the analog ports pretty obvious. I'll check the "other" pins and try going all digital for the next round of testing.

I don't know with netduino, but on arduino you can use a analogue pin as a digital pin,
I often use it when no free digital pins,

Pascal

As requested, we have been working on a few Ethernet options for the Netduino here at Secret Labs.

One of these that's in development is support for the Wiznet W5100-based Ethernet shields. A few forums members indicated that they've also started writing code for it. I'd like to see if we can get everyone on the same track so we can leverage each other's efforts.

I don't have any data on the stability of the chip for networking. I can say that we have completed the first portion of the support--but are still fleshing out the TCP and UDP support.

Here's what user setup code looks like so far (I just tested it on my home network):

// configure our wiznet chip
SecretLabs.NETMF.Net.WiznetChip wiznet = new SecretLabs.NETMF.Net.WiznetChip(Pins.GPIO_PIN_D10);
// configure our IP settings
NetworkInterface networkInterface = NetworkInterface.GetAllNetworkInterfaces()[0];
networkInterface.PhysicalAddress = new byte[] { 0x01, 0x23, 0x45, 0x67, 0x89, 0x01 };
networkInterface.EnableStaticIP("10.0.1.12", "255.255.255.0", "10.0.1.1");

Pretty simple, and compatible with the .NET MF networking object model.

Please note that this is all beta, subject to change, subject to abandonment, etc. We only want to ship things that are stable--and we're not far enough along to make that call yet...

Chris

Hello Chris,

Next week, I will receive these components :
http://www.coolcompo...uksdbumahtmuqg5
http://www.coolcompo...?products_id=83

W5100 is very nice, but limited (only ipv4, only 4 concurrent connexions ...),
Enc28j60 is more low level, only MAC, but we can use lwIP.
But, lwip seems to be to big to run on Netduino. I will work on uIP instead of lwIP and see if it's possible to run on .net MF ...

My first issue is to be able to compile the firmware. I currently use a eval version of RVDS 4.1 with success, but it's a eval version. With GCC, we probably raise a out of flash memory very quickly

Pascal

Regarding more pins...we're working on something(s)

One of the other big unique advantages of the Netduino is that it's 100% open source--hardware and software. You can erase the Netduino and compile the actual source code from scratch. In fact, we contributed much of the source back and bug fixes back to Microsoft--so it's included in the core .NET Micro Framework codebase for the benefit of all .NET MF products.

We're all about building community and giving our users the freedom to unleash their creativity. Netduino is only five weeks old and you folks have already created some pretty fantastic drivers and projects.

Thanks for being members of the Netduino community,

Chris

P.S. Oh, and we have some more surprises in store.

This is a key point. It was the main feature when I decided to purchase a Netduino. Without firmware source, I can be limited in future. And what about using multiple type of board and sharing a maximum of code ... I also purchase a Tahoe II board for the same key point. But it's not the same market. For my point of view, selling a .NET micro framework board with a proprietary firmware can be a good way to create a captive market ... not good for us.

Great idea, thanks to work on it ... Very interested for Netduino Plus ... Pascal

Just a little check. Often, installer use the EV ProgramFiles to know where it is. So, open a cmd and type : echo %ProgramFiles% You should see F:\Program Files in your case. If not, you probably found what's happen, Pascal

3 or more you've got a couple choices - you can use I2C to do it and give each a different address or you can use ethernet.

Personally, as a network engineer I'd say ethernet but there aren't any ethernet drivers for the netduino (yet!).

+1 for Ethernet.
It's seems that I2C .net MF implementation (like SPI) is always master. So, we cannot use I2C to cummunicate between 2 Netduino(s). Or we need to write another driver.
And I2C is very slow for that distance.

Pascal

The I2C on the ARM7X chip is master-only. We'll see what we can do on speeding up Ethernet support...

Chris

I2C master-only is a limitation of ARM7X or .NET micro framework ?
Perhaps I'm wrong, but when I read the datasheet, it's seems that the ATMEL used on netduino support both mode, no ?

Pascal

Hello, I use this shield with arduino with success: http://www.nuelectro...1&products_id=4 May I use this shield with netduino ? My question is essentially regarding hardware, For the software, I have already see that lwIP have some enc28j60 driver, Many thanks for all, Pascal I'm currently waiting to receive my netduino, somewhere between Canada & France ....