Sgoddy

I have been working on a GoBus 1-wire interface that might do some of what you want.

The GoBus SPI will be handled by a PIC16F1823 on which provides a 3v3 TTL serial bus into a DS2480B which drives the bus with edge shaping for the long lines my application requires. The board also has a battery backed DS2417 RTC which means it can also be used to set the netduino clock on boot.

Rest of the Arduino stuff is out of my area of expertise so I can't help with that. Sorry.

But it is the SPI to TTL serial that you might be interested in.

Hardware design is done. Software is in process. Components are on order for the h/w prototype to test the s/w.

Regards,

Steve the G

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.

Thanks once again for your input.

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?

If I could hijack this thread to post an arguably related follow-on question:

My Microsoft.SPOT.Hardware namespace doesn't have a OneWire class. Which file do I have to reference to pick this up please?

How does the class hook into any specific hardware implementation? Is this done at a low level or via a C# driver? In my specific case I'm talking about Netduino Go.

Ok, that's more than 1 question :-)

Steve the G.

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?

Thanks,

Steve the G