Introducing Netduino Go
#21
Posted 04 April 2012 - 07:24 PM
#22
Posted 04 April 2012 - 07:29 PM
That's the good thing of IO virtualisation; every module could, in theory, contain as many analog inputs as you want. For example the shield base module has 6 analog inputs.
Also, since the analog value is read out on the module itself, and from that point translated over a digital layer, you won't be bothered by the resistance of the cable to the Netduino Go! nor other influences from outside.
Ahh ok. So if I understand this correctly, the analog capabilites of the main board don't come into play. It's all on the remote "smart" module. Interesting.
In my mind, I'm seeing a fair bit of logic out on those modules. Is there an in-field update mechanism that is end-user friendly?
Pete
I work for Microsoft. Opinions expressed here are my own and do not necessarily reflect those of my employer,our partners or customers.
#23
Posted 04 April 2012 - 07:32 PM
If you build your module, and you use a chip that can handle 64 outputs, you'll be just fine!Can I virtualize outputs? Lets say I want to drive an 8x8 grid of leds - can I generate 64 outputs somehow? (Noob question , I'm sure)
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs
#24
Posted 04 April 2012 - 07:34 PM
You're understanding this correctly. I strongly believe this is a big thing.Ahh ok. So if I understand this correctly, the analog capabilites of the main board don't come into play. It's all on the remote "smart" module. Interesting.
Every module gets it's own "co-processor" taking care of very specific tasks, and then communicates with the main board. So the speed of the main board isn't even that relevant anymore.
There's an update mechanism on the socket connector, as I demonstrated in this thread.In my mind, I'm seeing a fair bit of logic out on those modules. Is there an in-field update mechanism that is end-user friendly?
Eventually there will be software that can flash firmware of modules over the Netduino Go! board (so using just your Netduino Go! board and a Micro USB cable)
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs
#25
Posted 04 April 2012 - 07:38 PM
#26
Posted 04 April 2012 - 07:49 PM
Using multiplexing (matrix) will require just 16 outputs (8 rows + 8 columns), Charlieplexing even less (9 pins can drive 9*(9-1) = 72 LEDs). However, the LED maximum peak current can be an issueLets say I want to drive an 8x8 grid of leds - can I generate 64 outputs somehow?
#27
Posted 04 April 2012 - 08:27 PM
#28
Posted 04 April 2012 - 10:19 PM
#29
Posted 05 April 2012 - 04:04 AM
#30
Posted 05 April 2012 - 04:34 AM
#31
Posted 05 April 2012 - 06:09 AM
PenZenMaster
#32
Posted 05 April 2012 - 07:27 AM
#33
Posted 05 April 2012 - 07:47 AM
#34
Posted 05 April 2012 - 08:28 AM
This is awesome, cant wait to get one
Should also make board design somewhat easier rather than having to deal with the annoying arduino header spacing.
One question did JTAG headers make it into the board layout?
Im no authority, but it looks like from the .BRD that J10, just to the right of the big button in the middle, is for the mini-Jtag header. From the picture, it looks like just the 10 pads are there, that they didnt populate a jtag header for production units (which makes sense) but it should be easy to solder one on... Maybe they will give us some advice as to what tools they used to debug. The spec says:
"Serial wire JTAG debug port (SWJ-DP)
The ARM SWJ-DP interface is embedded, and is a combined JTAG and serial wire debug
port that enables either a serial wire debug or a JTAG probe to be connected to the target.
Debug is performed using 2 pins only instead of 5 required by the JTAG (JTAG pins could be
re-use as GPIO with alternate function): the JTAG TMS and TCK pins are shared with
SWDIO and SWCLK, respectively, and a specific sequence on the TMS pin is used to switch
between JTAG-DP and SW-DP.
Embedded Trace Macrocell™
The ARM Embedded Trace Macrocell provides a greater visibility of the instruction and data
flow inside the CPU core by streaming compressed data at a very high rate from the
STM32F40x through a small number of ETM pins to an external hardware trace port
analyzer (TPA) device. The TPA is connected to a host computer using USB, Ethernet, or
any other high-speed channel. Real-time instruction and data flow activity can be recorded
and then formatted for display on the host computer that runs the debugger software. TPA
hardware is commercially available from common development tool vendors.
The Embedded Trace Macrocell operates with third party debugger software tools."
#35
Posted 05 April 2012 - 09:28 AM
#36
Posted 05 April 2012 - 09:44 AM
#37
Posted 05 April 2012 - 09:50 AM
#38
Posted 05 April 2012 - 12:26 PM
#39
Posted 05 April 2012 - 02:14 PM
#40
Posted 05 April 2012 - 02:38 PM
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users