Industrial I/O

One of the reasons I haven't completed my I/O project is because there is a limit to how much you can do with a nest of small test boards hanging off a standard Arduino.

Although I've planned proper boards I don't have the facilities to actually produce them, and the cost of a set of commercially produced one-off prototypes is prohibitive. At a minim there needs to be 1 input board, 1 output board and

1 processor board.

Finally, to get the boards down to a sensible size the opto-couplers need to be surface mount devices, and although my hands are still more steady than many younger people, these old eyes struggle with such small stuff.

Board size would be 89x127 mm and they stack on top of each other.

I would be happy to continue to develop the firmware once I have hardware to test on!

--
W J G

3.5" x 5" for those of us over here ;-) 1) does this new board have to stack on top of an Arduino ? 2) as this is a RasPi group, does does this new board have to stack up on an RasPi ?

If it does not stack up on a Arduino or a RasPi, what does it need to stack up with ?

hamilton

If it is GPL, then why would it need to be reverse engineered?

--

Rick

FHEM is GPL, the hardware and the protocol is not.

Why am I looking for on open source solution? Because we want to share our knowledge and work together on our solutions. Isn't that the reason why we met in usenet here?

H.

The GPL project is reverse engineering the proprietary hardware and protocols.

The boards stack with themselves :)

There is a processor board which has an Atmega328 (programmed in an arduino then popped out), an isolating 24V -> 5V DC inverter, Serial comms, dip switches for baud, ID, timeouts etc. and headers for the actual I/O boards. There is provision for either RS485 or RS232 comms (at build time).

There is support for up to four 32 bit digital I/P boards (isolated or direct), and 1 analog board - the latter can be isolated but then gets very expensive.

Also two 32 bit digital O/P boards (isolated or direct) are supported along with one dual channel isolated PWM analog O/P.

The design includes edge-wise spring loaded connectors for all external connections along with edge viewing status LEDs. Internal board connections are standard short ribbon cables, and spacing between boards needs to be about 20mm. There are four mounting holes for all boards that line up, and also are linked to the internal ground, so screening plates can be added if necessary.

As you may have guessed, I've been planning this for a long time :)

--
W J G

Ok, I get it. The protocols are part of a commercial system. I guess there is some utility to being compatible with commercial hardware. Seems to me it would be better to just roll your own hardware and forget the commercial stuff. People think hardware is hard because it requires building something, but that is not really so true. Hardware can be pretty easy much of the time. The only "hard" part is when you need to meet mechanical specs of some sort.

I am essentially offering to build the hardware if there will be some real utility to it. I'm not interested in starting on a project which will just languish from lack of interest. I have an rPi and would enjoy finding some use for it.

--

Rick

So, how about starting with something like this? Simulate SPI using 3 GPIO pins on the PI. Each IO module would have, say, a PIC chip - some of which support SPI directly. Software on those could be written in GCBASIC, a free compiler. The PIC chips would then handle whatever IO you want. Just send an address to select which one.

Why simulate SPI when the Pi has a perfectly usable SPI interface?

Gordon

Being a synchronous signal I don't believe SPI can handle anything like the range the O/P was talking about unless you're bit-banging at a very slow speed. Much simpler to plug in a USB to RS485 converter.

Also, you still have to provide I/O protection and isolation on the remotes.

--
W J G

'Cos I forgot..... :)

lol

SPI can be very, very fast. The problem is that it's rather limited in distance. If you'd rather go for RS-485 (nice for remote I/O but a lot slower) then why not save the USB and hang a RS-485 line driver on the USART TX/RX pins? You only need a third GPIO pin for RX/TX control then.

I'm still not sure that the Pi is the best idea for a main controller if speed is important anyway. There are far too many ways for linux to introduce unwanted pauses into the operation. Plus, every bit of additional complexity means a bit less reliability. :(

cos *I* forgot :)

However, you have to be careful about that. There can be quite a delay between the time you send a message from your program and the time it reaches the UART! A dedicated RS485 converter thingy does the switch automagically.

On the other end (the microcontroller) it's pretty much immediate.

If speed is really important you should be using a proper RTOS and Ethernet :P

However a surprising amount of factory automation can chug along happily with a latency of 100mS or more, especially when you have valves that take a couple of seconds to open or close.

I would imagine most home automation would be happy with a 10S latency. Even for turning lights on and off 500mS would probably be acceptable.

--
W J G

You're lucky if ordinary heating valves go end to end in a minute, dampers in about twice that. :) 100ms wouldn't be a problem in most cases.

I think there is more to bit banging a serial port of any kind than just how fast the peripheral can respond. With the CPU controlling the low level timing of the port it requires very precise timing control with no large gaps while the CPU is off doing something else. Very hard to do under a complex OS unless you know a lot of details of the OS. Basically you have to write a driver for the port. It is much better to use hardware for this.

Why can't the 485 port be driven off the SPI interface? SPI has a chip select that can be used for controlling the timing of the output enable. It would require a little bit of logic to set up a protocol to control the interface chip, but I think it could be done with a small PAL or a very tiny MCU, one of those 10 pin parts.

--

Rick

Hmmm, Apples and Oranges

RS-485 is a voltage spec for differential signalling.

SPI is a 3 wire hardware transfer register. ( plus ChipSelect if used )

One of these things are not like the other.

Please explain what you mean, thanks.

Isn't the RPi serial port implemented in hardware anyway? Surely there's a way to either implement hardware RTS back to the Pi or to test a flag for busy or something? I doubt if it needs any bit-banging whatsoever - could be wrong, but I don't think so. There may even be interrupts implemented.

If you wanted to let something else control the RS-485 then it would be easy enough to do, I suppose. It could even be semi-intelligent and take quite a load off the Pi. If the remote I/O is semi-intelligent it could even do things like PWM by itself.

UARTs are notorious for not being designed to drive RS-485. The problem is the timing of the output enable. Most if not all are double buffered so that the processor gets an interrupt as soon as the char has been transferred from the holding register to the shift register. There can also be an interrupt when the shift register is empty. But typically these things happen in the UART hardware when the last data bit has been shifted to the output which is one bit too early. The stop bit still has to be sent. So if you use the TxEmpty signal to control your RS-485 driver output enable it can turn off during the final data bit or at best during the stop bit.

There is no information available to the software that is any different.

Of course some UARTs are designed with RS-485 control in mind and remove the output flag at the end of the stop bit which works perfectly... but not many.

--

Rick

I think you are being a bit pedantic. Yes, RS-485 is an electrical spec for a tristated, shared bus but that would be met by using a driver chip and is outside this conversation. Unless stated otherwise, when people talk about RS-485 they are referring to an async protocol. But now that you say that, I realize the SPI interface would not provide for the start and stop bits so that this would not work at all. :)

--

Rick