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 use these instead of our $2000+ ARM RVICE hardware. It works beautifully and supports quite a few breakpoints. We debug C# code, step into native code (alt+tab) and back and forth. It's pretty awesome.
...
All purchased and on my desk. However, there is a teensy problem. The mini JTAG cable Mouser sent us with the TI MDL-ADA2 JTAG to MiniJTAG adapter is female-to-female, but the mini-JTAG connection on the Netduino Plus 2 requires pins on the connector. Are your mini-JTAG connectors male-to-female, or are you doing something else you didn't mention in your post?
To use Mini-JTAG with the newer hardware, you'll want to solder a Mini-JTAG header to your mainboard.
That is a good question. There's enough space left that you could actually run one app which flashes and loads another app. Not an overnight thing, but we have allocated a little bit of space for future potential on-chip storage...so that might help along the same lines.
The other thing we may be able to do with this board: local deployment/debugging over Ethernet. There were some issues with the lwIP implementation that prevented this, but it may be possible with NETMF 4.2/4.3.
Chris
What about using the SD card for flashing new deployments? If our user code saves the firmware to the SD card and sends a reset signal, could the firmware auto-deploy user code or firmware from that image?
What about using the SD card for flashing new deployments? If our user code saves the firmware to the SD card and sends a reset signal, could the firmware auto-deploy user code or firmware from that image?
You could certainly use a NETMF bootloader to load assemblies from the SD card into RAM and then execute them.
If you check out the Mono bootloader in our Mono forum...it does exactly that.
Brand new to the Netduino stuff - am knocked out by what I've seen so far (Plus2/MF4.2/MF4.3/VS2012). I am going to add the STLink/V2 to my collection. Do you by any chance have a part number for the board-side header itself?
Brand new to the Netduino stuff - am knocked out by what I've seen so far (Plus2/MF4.2/MF4.3/VS2012). I am going to add the STLink/V2 to my collection. Do you by any chance have a part number for the board-side header itself?
You could certainly use a NETMF bootloader to load assemblies from the SD card into RAM and then execute them.
If you check out the Mono bootloader in our Mono forum...it does exactly that.
Chris
I have done a number of upgrades to my software as the product has changed, not to add features, but to cope with the underlying changes as bugs come and go. (By product I am referring to the non-managed code.) Typically I have needed to upgrade everything, starting with using the jumper wire. For example, the most recent change was needed because in the latest OS, analog input pins briefly come up in a low impedance - output mode, rather than a high impedance - input mode as they used to, until managed code can define them otherwise.
Perhaps one day the boot-decompressor and the underlying flash code will be stable enough for loading of managed code from SD to be interesting, but for now I do not see how it would be of much help.
For example, the most recent change was needed because in the latest OS, analog input pins briefly come up in a low impedance - output mode, rather than a high impedance - input mode as they used to, until managed code can define them otherwise.
Very curious. The SAM7X chips on Netduino and Netduino Plus should always bring all of their digital pins up in "input, pull-up" mode. That's hard-wired into the chips. Is that occurring for you on a specific pin? I'm not aware of any changes that would affect the startup state of MCU pins.
On the topic of the thread...the new Netduino Plus 2's STM32 chip has the advantage of starting up all pins in input floating mode.
Thank you for your feedback; we do try to keep things very consistent between releases. The hardware upgrade to Netduino Plus 2 is so major that we may have to tweak a few things to keep behavior consistent (with the one big exception being the default pin state on boot...having them floating by default should be a welcome change for almost all users).
I've got a big problem with the new Netduino Plus 2. The official Arduino wireless, prototyping, Wi-Fi, and ethernet boards all route MOSI/MISO to the ICSP header. It seems like the Arduino team has standardized using the ICSP header for all SPI data. While at the same time, the Netduino team has dropped the classic ICSP for this new mini-JTAG header. And, as far as I know, the only shield that routes those pins anywhere useful is the MakerShield.
If you guys wanted to make an Arduino R3 (1.0) compatible board...I hate to break it to you, but you failed.
I've got a big problem with the new Netduino Plus 2. The official Arduino wireless, prototyping, Wi-Fi, and ethernet boards all route MOSI/MISO to the ICSP header. It seems like the Arduino team has standardized using the ICSP header for all SPI data. While at the same time, the Netduino team has dropped the classic ICSP for this new mini-JTAG header. And, as far as I know, the only shield that routes those pins anywhere useful is the MakerShield.
Thank you for your feedback on this. The ICSP header on some of the new Arduino-brand shields is a bit of a kludgy hack, but it is definitely something we want to support.
Our recommendations for those shields which need to route via the ICSP header is to sandwich a MakerShield in between the shield and the Netduino Plus 2 mainboard. With Netduino Plus 1 the user needed to solder on an ICSP header to use these shields, so hopefully sandwiching an ICSP-routing shield in the middle isn't too much different. If there's enough demand for the newer Arduino-brand shields, we can make a Netduino-brand proto-board with R3 headers which also routes the ICSP header pins for you.
While the new Arduinos leave backwards-compatibility behind in various ways, we believe the balance struck with Netduino Plus 2 should enable compatibility with the widest range of Arduino Shields...while also enabling native code debugging (which was a heavily-requested feature).
Hi guys, I have been looking int netduino for a bit now. I am interested in the new NP2. You mention here in this thread the following. "Netduino Plus 2 has four times the speed (168MHz), six times the code space (384KB), and twice the available RAM (100KB+) of Netduino Plus 1." Yet the main page http://www.netduino.com/ shows it as 1MB flash & 192k ram. Why are the numbers different ?
Hi guys, I have been looking int netduino for a bit now. I am interested in the new NP2. You mention here in this thread the following. "Netduino Plus 2 has four times the speed (168MHz), six times the code space (384KB), and twice the available RAM (100KB+) of Netduino Plus 1." Yet the main page http://www.netduino.com/ shows it as 1MB flash & 192k ram. Why are the numbers different ?
The #s on the homepage are the total chip capacity. The code space and available RAM specs are what is left for your code.
Effectively, the networking stack and .NET Micro Framework runtime take some of the flash and RAM.
For your code, you have 384KB of flash and 100KB+ of RAM.
This is similar to buying a new tablet or phone; for example, a 16GB phone may only have 11GB of free space.
We try to always quote the _available_ space in descriptions, in specs, etc. But we wanted to make sure people knew we were using the 1MB flash STM32F4 chip in the front page banner.
This is really nice.
I own 4 Netduino Plus 1 devices and they are perfect to do little jobs.
The only thing I am missing (a bit) is an onboard date/time.
Are there any plans to include this one day?
I know this will make things bigger, and currently I am using NTP to configure time.
The #s on the homepage are the total chip capacity. The code space and available RAM specs are what is left for your code.
Effectively, the networking stack and .NET Micro Framework runtime take some of the flash and RAM.
For your code, you have 384KB of flash and 100KB+ of RAM.
This is similar to buying a new tablet or phone; for example, a 16GB phone may only have 11GB of free space.
We try to always quote the _available_ space in descriptions, in specs, etc. But we wanted to make sure people knew we were using the 1MB flash STM32F4 chip in the front page banner.
Chris
I thought that's what it was, Thanks for the confirmation.
This is really nice.
I own 4 Netduino Plus 1 devices and they are perfect to do little jobs.
The only thing I am missing (a bit) is an onboard date/time.
Are there any plans to include this one day?
I know this will make things bigger, and currently I am using NTP to configure time.
It's really easy to add something like a DS1307 Real time clock. It's the first thing I add to most of my projects especially when they aren't Ethernet Enabled.
Is the Ethernet speed still 10/100 mbps? New specs I have seen listed as 10 mbps.
hank you.
The physical network interface on Netduino Plus 1 was 10/100, but the actual throughput was much lower (somewhere around 1mbps). Fairly fast for a microcontroller, but not taking advantage of all that a 100mbps connection could offer
The Ethernet on Netduino Plus 2 has an even faster throughput...although we accomplished this in part by moving to a networking chip which runs in 10mbps mode.
So in the end, the interface speed looks slower...but the actual throughput is much higher.
We use these instead of our $2000+ ARM RVICE hardware. It works beautifully and supports quite a few breakpoints. We debug C# code, step into native code (alt+tab) and back and forth. It's pretty awesome.
And for those who want a really really nice Cortex-M4F devboard for C/C++ code...Netduino Plus 2 does that really well too. Arduino shield compatibility is a big bonus there too.
Chris
Hi Chris,
What's the IDE you are referring to that steps from C# in and out of native code? Is it IAR (that you mentioned in another post)? Their free "Kickstart Edition" is limited to 32 KB, which won't compile your platform.
(I was using MS Visual Studio 2010 for .NET MF C#, but I don't think that would support interop native code on ARM.)
What's the IDE you are referring to that steps from C# in and out of native code? Is it IAR (that you mentioned in another post)? Their free "Kickstart Edition" is limited to 32 KB, which won't compile your platform.
(I was using MS Visual Studio 2010 for .NET MF C#, but I don't think that would support interop native code on ARM.)
IAR will debug larger code, although you'll need to compile with GCC or the like.