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.
A module builder asked for some clarification on which GPIOs (or other microcontroller peripheral features) should be exposed as Virtual I/O, so we've added some early guidelines to the GoBus 1.5 spec (see pages 22-23).
Many modules will use GPIOs or other peripheral features internally which would not be appropriate to expose as Virtual I/O. A good example of this are GPIOs which select the digit on a 7-segment display thousands of times per second; these GPIOs are not exposed to the NETMF driver or to the user, so they're not exposed via the GPIO profile.
On the other hand, the upcoming RS232 module exposes a SerialPort to the user. So this is wrapped inside the UART profile. The RS232 module driver also exposes a SerialPorts enumeration, and the user simply writes code like this:
NetduinoGo.RS232 rs232 = new NetduinoGo.RS232();
SerialPort sp = new SerialPort(rs232.SerialPorts.COM1, 115200);
sp.DataReceived += sp_OnDataReceived;
sp.Open();
I see lots of mention of developing go modules etc but what about other microcontrollers HOSTING modules in the same way as the netduino go itself? Lets say as an arduino shield or something (I would think something more powerful would be needed)
I see lots of mention of developing go modules etc but what about other microcontrollers HOSTING modules in the same way as the netduino go itself? Lets say as an arduino shield or something (I would think something more powerful would be needed)
That's one of the big benefits of having the open protocol. If someone wants to develop a shield for Arduino, to support GoBus Virtual I/O...it's definitely possible. Same goes for Raspberry Pi, BeagleBone, etc.
If you're interested in GoBus support on other platforms, just let me know and we can get that conversation started.
When might I be able to start using GoBus 1.5? In the original post it sounds like its soon was just wondering if I could get some clarification as to when I might be able to use it.
Over the coming weeks, we'll be updating Netduino Go and the Shield Base to GoBus 1.5. We'll also be sharing a fully-C# implementation of the GoBus transport layer which can be used on regular Netduinos.
When might I be able to start using GoBus 1.5? In the original post it sounds like its soon was just wondering if I could get some clarification as to when I might be able to use it.
Shield Base will be the first module to get the GoBus 1.5 upgrade. We're testing it now and should have the first beta release posted by the end of this week.
Didn't think about it in my previous post but will the shield base support SPI now as a part of this?
We're testing the Shield Base on the GoBus async transport first (using UART), but will be moving it to SPI soon. We want to make sure the async transport is performing well first.
...for reasons that will become obvious this weekend
P.S.
Because GoBus 1.5 is asynchronous in nature (i.e. has callbacks), we've been able to add InterruptPort support on the Shield Base. This also gives us the foundation we need to add SerialPort virtual i/o support (which should be ready soon as well).
New firmware, Shield Base assembly, and source coming this week.
Chris
UPDATE: firmware, assembly, and source now posted!
Edited by Chris Walker, 25 September 2012 - 02:12 AM.
I've been reading this spec in support of a GoBus module that I'm playing with (at the design stage).
I have a couple of questions that could go in the spec (or maybe answered here):
1) Some speed guidelines would be nice. While I realise that the bus is variable speed and no doubt configurable by the driver, there is probably some sort of default, or max possible, that a module (particularly a logo-compliant module) should be able to support. A previous question has mentioned timing diagrams or example transfers. In addition, information such as the gap between each byte of a transfer would help.
My rationale behind asking this question is that the module s/w design needs to know this info to help with choosing clock speeds for the h/w etc, as an arriving SPI data byte must be read out, stored and the outgoing byte loaded in to the SPI buffer, all before the next byte starts clocking in/out. I may have to trade off complex s/w and h/w design that runs at 20Mhz against something really cheap and easy that can only go at 100KHz.
2) <old man dodgy memory alert> I vaguely remember reading somewhere that to be Go logo compliant, modules must support in-situ flash reprogramming. Even if this memory is wrong, you have mentioned that the STM reference s/w could be ported to other cpus, (I think you mentioned AVR, NXP, Cortex....). [Coincidentally, the s/w I am designing is not STM]. How are these other cpus going to interact with this in-situ reprogramming? While most of them have some sort of serial mode, there are possibly other constraints (such as weird programming voltages, difficult algorithms....) that might make this compliance difficult to achieve. Does that mean that a non-STM GoBus Module cannot be logo compliant?
Hi Steve the G,
Great questions.
GoBus starts out at around 100 kbit/sec, to negotiate valid speeds with the module. It can run as fast as 21 mbit/sec. Or as slow as ~100 kbit/sec. If a certain speed fails, the mainboard simply cuts the speed in half and tries again.
We've worked out a tentative re-flashing mechanism for AVR-based devices, but have not built any AVR-based modules to implement and test it yet. NXP Cortex wouldn't be a problem, since they us UART reflashing--although you'd need to provide a flash app for the mainboard (or we'd need to incorporate the functionality into the core).
Timing diagrams are a good idea. The bytes are currently rapid-fire, but we can certainly tweak the SPI transport to delay between bytes for low-end modules.
Chris
Thanks for that prompt and comprehensive reply, Chris. The speed halving is a nice touch.
In my case, I'm looking at PIC as the GoBus module host. <pause until everyone stops laughing>. OK, I'll explain.
I'm a long-time C# software guy who dabbles in hardware, so I like to keep the circuity bits small. I'm a hobbyist and not a commercial organisation. I know PIC, have the software and programmers and I don't know STM. My initial GoBus circuit used an 8 pin PIC as the interface CPU, though I have now upped this to a 14 pin one as the 8 pin didn't have any spare lines for the GPIO and I would rather have the interrupt notification than polling. Yeah I have used PICs up to the 40-48 pin flavours, but it seems overkill to use such a large chip (even something like a 28 pin) for such a small application. Don't know STM8s but I think they're 28+ pins? To me, that's big AND unknown.
The PICs support serial programming. I haven't looked too hard at the algorithm, as I just plug the cpu into the programmer or plug the programmer into the header. So this serial programming isn't something I have looked into in detail either in terms of voltages or algorithms. I think you need 12V for the first time around and then subsequent ones can be sent through at lower voltage.
The current h/w design brings the programming pins to a header where the programmer gets plugged in. This is bog-standard PIC practice. It would be nice to get the circuitry right to allow serial programming to be added in the future using the GoBus serial lines once the s/w allows it though obviously it would be wrong to add support specifically for any one cpu, whatever the variety.
Regards,
Steve the G.
P.S. I'm aware that this post is drifting the thread off topic. Apologies. Maybe this should be a new thread?
Hi Steve the G,
Ooh, PICs! That sounds like fun.
We've deliberately focused in on STM8S and STM32 initially to make sure that we can deliver a good experience there for now, but we did architect the SPI-transport GoPorts around flashing NXP-Cortex-based and AVR-based modules in-place as well.
A few things for your research list:
1. The PIC will need to run at 3.3V, or otherwise use 3.3V I/O signals. GoBus's SPI transport uses 3.3V logic levels.
2. Does the PIC have a hardware bootloader mode? If so, you'll want to attach its BOOT pin to the /IRQ pin on the GoPort connector. You'll also want to pull up/down that pin to the state it needs to be in for normal boot. Netduino Go powers up all modules with the /IRQ pin floating. If the PIC doesn't have an integrated ROM bootloader like this, you'll need to put a custom software bootloader in your PIC's flash.
3. Once in bootloader mode, does the PIC use a custom bit-banged protocol or a UART-based protocol with loose timings? If it's a custom bit-banged protocol, things get a bit trickier. If it's a UART-based protocol with loose timings, then you'll be able to flash the module from the mainboard and possibly in-place via hubs as well.
Chris
Yes, I understand about the STMs/NXP/AVRs. There are way too many microcontrollers out there to be able to support all of them and whatever ones you pick, there will always be people who want their favourite added. I'm ok with all that and I'm happy to go ahead with 1st prototype without this in.
Although I'm new here, I have been reading the forums for a few weeks. I spotted the 3V3 issue a week or so ago and the PIC I'm looking at has no problems at that voltage. Also have the 5V remaining circuitry interfaced nicely.
The rest of your post drives off the cliff of my knowledge. I doubt there is a bootloader (There are some PICs with them but I've never used them). Think I'll need to read up on the specs I've downloaded.
You can currently use one Shield Base with Netduino Go. We are working on some new software that will enable multiple shield bases simultaneously...but I don't have a release date for that yet.
