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.
Trying to blink Cpu.Pin.GPIO_Pin13 (13) isn't working for me when using the shield as a standalone netduino (without the Go).
Cpu.Pin.### are built-in NETMF enumerations which refer to the physical pins on the chip itself. That pin 13 would be pin PA13 on the Shield Base, which is the IO pin for JTAG/SWD.
What are the proper pin definitions for D0..D13 and A0..A5 for using the bonus 512K shield base as a separate netduino? Where are these defined? Is there a good place to look in the shield base firmware?
There's no official pin definition file for the Shield Base, although it would be fairly straightforward to make one. The schematics for the Shield Base are available from the "Attachments" pull-down on top of the Shield Base wiki page: http://wiki.netduino...hield-Base.ashx
Here are the pin assignments for you... You can use the (Cpu.Pin)0x## assignments in your code directly--or wrap them in a Pins enum.
I have few couple question.
Does the ShieldBase currently support I2CDevices and SPI devices? If not, will there be an updated driver coming out soon? Base on the pinout of the ShieldBase, which headers would I connect a I2CDevice to that of PIN_A4/PIN_A5 or that of SCL/SDA?
Thanks,
Kirk
Does the ShieldBase currently support I2CDevices and SPI devices? If not, will there be an updated driver coming out soon? Base on the pinout of the ShieldBase, which headers would I connect a I2CDevice to that of PIN_A4/PIN_A5 or that of SCL/SDA?
The Shield Base doesn't support SPI or I2C in its standard configuration quite yet. We're getting close to SPI and UART; I2C will come soon after--and you'll be able to use pins A4/A5 or SCL/SDA. They're mirrored.
SPI is currently supported if you deploy code directly to the Shield Base. It's baked into the Shield Base's NETMF firmware...we're working on the transport to shuttle the data between mainboard and shield base now.
Maybe this has been posted somewhere else but been searching for days on it. Still somewhat new to the microcontroller world (seasoned C# developer though) so may just be searching wrong.
In regards to the shieldbase and ICSP Headers. I don't mind hacking around a bit so is it possible or is there a mapping between the shield base and these? (Arduino Ethernet board is the target. I realize it says wait for the ethernet go module, but not sure how much time that is going to be and I've got a prototype to build.
Thanks for your help, sorry if a repeated or dumb question.
Maybe this has been posted somewhere else but been searching for days on it. Still somewhat new to the microcontroller world (seasoned C# developer though) so may just be searching wrong.
In regards to the shieldbase and ICSP Headers. I don't mind hacking around a bit so is it possible or is there a mapping between the shield base and these? (Arduino Ethernet board is the target. I realize it says wait for the ethernet go module, but not sure how much time that is going to be and I've got a prototype to build.
Thanks for your help, sorry if a repeated or dumb question.
We removed the ICSP headers from the Shield Base, adding MiniJTAG in its place ( a much more useful feature ).
You can add the "ICSP" headers by stacking a MakerShield or similar on top of your Shield Base. It will map the SPI and RESET and power pins to the proper place.
The first Ethernet module samples are scheduled to arrive next week. If they pass our tests, they'll immediately go into production. We already have parts ordered, to be delivered to us on 8-August
For Ethernet support in a rush, you can also pick up an ENC28J60 SD+Ethernet Gadgeteer module from Sytech and use Valkyrie-MT's mIP network classes (requires 4 sockets). Or wire up an ENC28J60 module to a socket on your Netduino Go and use the same.
The Ethernet module will be the easiest and best solution. I'm really looking forward to testing the samples out next week!
We removed the ICSP headers from the Shield Base, adding MiniJTAG in its place ( a much more useful feature ).
You can add the "ICSP" headers by stacking a MakerShield or similar on top of your Shield Base. It will map the SPI and RESET and power pins to the proper place.
The first Ethernet module samples are scheduled to arrive next week. If they pass our tests, they'll immediately go into production. We already have parts ordered, to be delivered to us on 8-August
For Ethernet support in a rush, you can also pick up an ENC28J60 SD+Ethernet Gadgeteer module from Sytech and use Valkyrie-MT's mIP network classes (requires 4 sockets). Or wire up an ENC28J60 module to a socket on your Netduino Go and use the same.
The Ethernet module will be the easiest and best solution. I'm really looking forward to testing the samples out next week!
Chris
Logging in tonight to check this message, I happened to hit the first page of said thread and felt like an idiot. But at least got some additional info on the ethernet module.
Oddly enough, I happen to have all the parts necessary readily available. Not sure if that's a good thing or a bad thing. Only been doing this a couple weeks.
Thanks for the advice, I'll let you know how it goes. (Translated to "hey... what the f*c* am I doing wrong?")
Logging in tonight to check this message, I happened to hit the first page of said thread and felt like an idiot. But at least got some additional info on the ethernet module.
Oddly enough, I happen to have all the parts necessary readily available. Not sure if that's a good thing or a bad thing. Only been doing this a couple weeks.
Thanks for the advice, I'll let you know how it goes. (Translated to "hey... what the f*c* am I doing wrong?")
Precisely. You may need to jumper a cable between the IOREF pin on the Ethernet shield and the IOREF header on the Shield Base...if it's used by the Ethernet shield.
Quick note: the virtualized SPI feature of the Shield Base beta firmware is currently under development. You can deploy code directly to the Shield Base (using it as a Netduino mainboard instead of as a go!bus module)...but you'll need to wait a little bit to use the SPI feature via proxy (from the go! mainboard).
Precisely. You may need to jumper a cable between the IOREF pin on the Ethernet shield and the IOREF header on the Shield Base...if it's used by the Ethernet shield.
Quick note: the virtualized SPI feature of the Shield Base beta firmware is currently under development. You can deploy code directly to the Shield Base (using it as a Netduino mainboard instead of as a go!bus module)...but you'll need to wait a little bit to use the SPI feature via proxy (from the go! mainboard).
Chris
First thing you said about jumpering the IOREF pins/headers. Got it. Not pretty, but acceptable.
However, would you mind making the quick note a little bit longer? I understood some of the words, just not all together.
However, would you mind making the quick note a little bit longer? I understood some of the words, just not all together.
The .NET MF firmware on the Shield Base is production quality and full-featured, but when you use it from the Netduino Go mainboard (as virtual IO) only some of the features have been enabled. We're enabling one feature at a time.
So far we've enabled InputPort, OutputPort, TristatePort, AnalogInput, and PWM. We're now working on SerialPort and SPI. We will have updated firmware in the near future enabling these last two needed features (and then I2C).
The .NET MF firmware on the Shield Base is production quality and full-featured, but when you use it from the Netduino Go mainboard (as virtual IO) only some of the features have been enabled. We're enabling one feature at a time.
So far we've enabled InputPort, OutputPort, TristatePort, AnalogInput, and PWM. We're now working on SerialPort and SPI. We will have updated firmware in the near future enabling these last two needed features (and then I2C).
Chris
Alright. I have a lot more reading to do I believe. But just to make sure I have this correct.
Input/Output Ports - Simple Low/High bit of 3.3/5v (using a 'pull resistor' built into the board that drops the voltage?)
Tristate Port - same as above but also has a 0v level?
Analog - Varying voltage depending on movement
PWM - Power Module of some kind (continuous?)
What exactly is the difference between Serial and SPI?
Now to the crux of the questions.
The .NET MF firmware on the Shield Base is production quality and full-featured, but when you use it from the Netduino Go mainboard (as virtual IO) only some of the features have been enabled. We're enabling one feature at a time.
Ok. So the ShieldBase is effectively a NetDuino with some support of being controlled by a NetDuino Go? However at this time since some things are not supported through the virtual I/O (I'm guessing this is the communication between the Go! and the ShieldBase?) Does this mean I have extra steps in both deployment and development? How seamless is my connectivity between my Ethernet Shield, Go Shield, and Go. Just wrapping my head around it.
May have figured out what you were talking about through experimentation. Here's a picture of what I'm working with right now. The Touch Display by nwazet is pretty awesome with just it's demo and ease of setup. Add in the JavaScript editor and package it for 70 bux and it's a winner. That aside.
One of the features of the display is to both read and write to the SD card in order to save calibration settings and store some images to read and display on the screen.
As you can see I've got my Arduino Ethernet Shield Sandwich hooked into Socket6. Powered up and RX/TX are flashing, showing 100M link, etc. I'm hoping that means I didn't mess anything up in creating this and my rookie soldering skills. LCD Display on Socket1 [I believe I read that 1-4 = 1 Channel, 5-8 another. Can't remember what type of channel it was, may not even be related.] but figured keep them far apart, reduce chances of issues. BTW, Is this where virtual I/O comes into play?
When attempting to read or write to the device it gets a general exception. I'm not sure if this is related to the un-implemented I/O options you have not implemented, the proxy between shield and Go. etc. Or I'm attempting to do too much (reading the SD card of the arduino). Forgive my babbling.
Going to experiment with a few things and see what I come up with.
When attempting to read or write to the device it gets a general exception. I'm not sure if this is related to the un-implemented I/O options you have not implemented, the proxy between shield and Go. etc. Or I'm attempting to do too much (reading the SD card of the arduino). Forgive my babbling.
Going to experiment with a few things and see what I come up with.
The SPI feature on the Shield Base (and in particular the SPI-SD driver) aren't yet enabled on the Shield Base when used in this configuration. If you deploy NETMF code directly to the Shield Base (using it as its own Netduino) you should be fine...but right now I'd recommend either hooking up an SD breakout directly to the pins of a go!bus socket on your mainboard or waiting for the SD go!bus modules (which should arrive within roughly two weeks).
Ok. So the ShieldBase is effectively a NetDuino with some support of being controlled by a NetDuino Go? However at this time since some things are not supported through the virtual I/O (I'm guessing this is the communication between the Go! and the ShieldBase?) Does this mean I have extra steps in both deployment and development? How seamless is my connectivity between my Ethernet Shield, Go Shield, and Go. Just wrapping my head around it.
Right now, the SPI virtual IO feature is not enabled on the shield base. Once it's enabled, it'll be completely seamless for you.
In the meantime, if you want to tinker with that feature you can deploy code directly to the Shield Base. But you'd need to write your own comm to talk between it and the mainboard via UART (basically running two applications in parallel).
We're working on the virtual SPI feature now, and plan to have it ready very soon (for an updated beta firmware for the Shield Base).
Considering the bang for the buck you get with the shield, especially if its true that you can use the base shield independantly, will the MSRP for the shield base increase post-beta?
Considering the bang for the buck you get with the shield, especially if its true that you can use the base shield independantly, will the MSRP for the shield base increase post-beta?
There is currently no plan to increase the MSRP for Shield Base post-beta. We do plan on switching the MCU to the smaller 128KB chip post-beta.
There is currently no plan to increase the MSRP for Shield Base post-beta. We do plan on switching the MCU to the smaller 128KB chip post-beta.
Chris
In the OP of this thread, you mentioned the switch to 128KB was this summer. Does that mean the Shield Base's resellers currently have with the beta feedback sticker are the original 512KB MCU's still, especially considering how the base is still in beta? Maybe it's time to buy a few extra shield base modules if so.
In the OP of this thread, you mentioned the switch to 128KB was this summer. Does that mean the Shield Base's resellers currently have with the beta feedback sticker are the original 512KB MCU's still, especially considering how the base is still in beta? Maybe it's time to buy a few extra shield base modules if so.
We're making the last batch of Shield Bases with 512KB chips next month. It's a big batch so it should last a few months...but later production batches will start using the 128KB chips instead.
Thanks for your help, sorry if a repeated or dumb question.
