Current State of features
#1
Posted 10 December 2011 - 10:59 AM
A few months ago I was finishing a robotics project and ended up hitting pretty hard limitations on the Arduino platform, I switched to a Netduino, and life was good... other than minor issues I came across at the time.
I have a similar situation now with a different project, it started with Arduino and I am thinking about moving over once again. I just wanted to get a heads-up on what the current state of the platform is.
So, if anybody could help with a couple of questions, here they go!
-Can I communicate though USB? I am storing information in an SD card that I would need to read, it used to be that the USB(digital 0-1) were only for debugging, is that still so? I am using all pins on the Arduino, I won't be able to use the second UART for sending data over.
-I remember some conversation on low-power modes, but it all seemed on the air (waiting for 4.2 and so). Is there anything working today? My application is fairly power-critical (big batteries but must last for months), I could trigger a hardware interrupt if that's needed
-I might be producing a few tens of devices in the next six months or so, how well does the Netduino/MCU scale in terms of production? (I am thinking chip availability, bootloading, etc) In the Arduino you can buy a blank chip, program it and have it running on a custom PCB in no time
-I have found some cases for the Arduino (I particularly like the one Adafruit has), is there any that's Netduino-friendly? Netduino having the usb plug in a different location and so...
thanks a ton!
#2
Posted 11 December 2011 - 05:35 AM
#3
Posted 11 December 2011 - 07:24 AM
There is no low power mode today, although it could be implemented via firmware. You'd need to remove the white LED though
Even detaching the led, placing in sleep both the MCU and the Ethernet chip (if applies), there is a waste of several mA.
This flow is due by the power regulators, the SD (if present), the OPAMP for the USB power, and some minor parts.
This applies *only* for the Netduino itself, but most of the time there is an extra hardware connected to the board, which requires energy to work as well. This can't estimated, though.
In addition, the user will lose the warranty (if someone cares).
So, this approach forces you to hack the board, hack the firmware (which is pretty hard to perform), and in any case you won't reach a decent result.
IMHO, the best bet to achieve a "surrogate-of-low-power-mode" is using an external timer (e.g. 555-like), to cyclically power the entire circuit for a while, then switch it off. By varying the duty-cycle, you can reach very low energy consumption, without actually touching anything of your Netduino.
Cheers
#4
Posted 12 December 2011 - 11:18 AM
USB is for debugging (with certain advanced exceptions), although we're hoping to open it up to bi-directional communication in the future.
I guess this stays the way it used to be then, which leads me back to the pin count issue, I am wondering... could I use the digital 0 and 1 for communication using an external UART->USB chip (or alternatively do the same with 2-3 and leave 0-1 as normal digital in/out)?
I know you guys are working on a better solution, but I'd need to make a decision with what is available (and proven) today
I really like the idea of powering the whole board off, as Mario suggests, as I'd need to collect data only every so often. The issue is that there's an UI that requires fast-enough response, as I current have with event handling, but was wondering if it could also recover a deep sleep...IMHO, the best bet to achieve a "surrogate-of-low-power-mode" is using an external timer (e.g. 555-like), to cyclically power the entire circuit for a while
I wouldn't mind having a few mAmps of usage (even if I have to disconnect a LED), it all depends on how many. My guess is that anything around 20 would be okay, maybe the Netduino Mini has lower power reqs?
I could always go for the SAM7X directly on-PCB, but I'd rather do the first hundred or so units with an already-available MCU board than having to integrate it in the design... Mostly as I feel that integrating the SAM7X would be way harder than integrating a, say, 328. (I would need a SMD-friendly programmer to add the Netduino bootloader to the chips, am I right?)
thanks for your help guys! The community rocks
#5
Posted 12 December 2011 - 01:08 PM
#6
Posted 12 December 2011 - 01:28 PM
#7
Posted 12 December 2011 - 02:10 PM
The issue is that, if switching off the whole board, the Netduino wouldn't be able to wake up on time for the UI to flow nicely.
Have you measured the total time for your application to start from a cold boot? I am curious as I would have thought that it would be possible to get that into an "acceptable" range.
As for handling the keyboard and display, why not use a really low power chip (like perhaps the $4.30 TI MSP430 board) to handle that and cause the Netduino to boot as required (like when a key is pressed).
#8
Posted 12 December 2011 - 08:41 PM
Have you measured the total time for your application to start from a cold boot? I am curious as I would have thought that it would be possible to get that into an "acceptable" range.
As for handling the keyboard and display, why not use a really low power chip (like perhaps the $4.30 TI MSP430 board) to handle that and cause the Netduino to boot as required (like when a key is pressed).
Jonny,
Nope, I haven't really measure it, but the response should be fast enough to feel fluid, probably less than 30ms from button to UI response, that's, I think' way out of any MCU league (other than hardware-interrupt wake up). That aside there are also menu entries displayed that would need updating every second, seems to me like quite a bit of the time for sleep would be spent waking up in such a scenario.
I have thought about having an extra MCU (msp430, atmega328) dealing with the menu/UI side of things, the problem is that it gets more complex both software and PCB-wise, and more expensive to manufacture.
The menu display does require some access to much of the rest of the code. In that sense, for the rest of what the code is doing right now the extra added complexity wouldn't make sense, it would just make sense to simply put the whole code in the msp/328 instead.
#9
Posted 12 December 2011 - 08:44 PM
#10
Posted 13 December 2011 - 04:35 AM
Not sure what's the problem. If you're thinking to a FTDI chip, wired as the Boarduino does, I guess there's no problem.Does anybody have any thoughts on my idea of using UART-to-USB in pins 2&3 and leaving 0&1 as input/output? or using 0&1 with an off-Netduino UART-to-USB chip?
However, that will be an USB slave, not master.
Cheers
#11
Posted 13 December 2011 - 03:54 PM
Not sure what's the problem. If you're thinking to a FTDI chip, wired as the Boarduino does, I guess there's no problem.
However, that will be an USB slave, not master.
Cheers
Precisely, I was thinking on using digital 0-1 (or 2-3) as RxTx for a FTDI chip. So what you mean is that it is possible, as long as I don't use the native Netduino USB part. Am I right?
Does your last comment mean that the Netduino's USB can act as USB master? Can I theoretically talk to a slave device such as an iPhone or an Android tablet?
#12
Posted 13 December 2011 - 04:31 PM
#13
Posted 14 December 2011 - 10:44 AM
I believe you can use this http://forums.netdui...tion-using-usb/ for basic communication if you plan on having a custom app on ur desktop.
I'm currently using it for transfering a configuration .ini file and storing it in the SD card.
That could possibly do the trick.
Thanks for the tip!
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users