Open source PLC hardware

Wow, stay out of work for one sick day and look what happens! :eek:)

I'm just going to reply globally to all of the posts so far...

Here is what I feels strongly about:

- Develop an SPI based rack with electrical and mechanical specifications.

- The rack can be used with a CPU or a communications module (i.e. remoteIO).
* Lets not get too detailed on what these are *Yet* There will undoubtedly be many options here.
* Using SPI as the [rack] bus will allow many options, from completely embedded AVR/Arduino to Marvell processors.

- The rack should be as small as we can make it (This is to compete with the bloated solutions that already exist).

- Make it as inexpensive for basic IO modules as possible. We want to leverage this system to be cheap when you have high IO counts. $50-$100 for 16 bits of IO is very reasonable and achievable in any decent quantities.

I think that developing the IO rack in itself is enough of a project for now. I don't think looking at embedded linux computers is a bad idea at this point because that is where we want to go, but lets not get bogged down with the exact System on Module right now. I think I prefer the modules that are more "stamp"-like since they let you dictate where the front panel connectors (USB, ethernet) will be located on the "carrier" module. We don't want to design a rack based system around one CPU module. The "linux stamp" is such a device, but so far it seems limited to a 200MHz ARM, which should be fine for most things, but not for everything.

I have developed IO boards based on a backplane before and I know some of the problems in doing it on your own. I was able to get it down to roughly a 3" x 3" board size while still using 16 IO points and 24VDC feed. I'd like to do some of the mechanical layout and board design if my "home time" allows for it (I have to young sons, so time is not that available). I've found that DIP devices are very much hard to find in some areas, so working with SMD is almost required. If we keep with 0.050" pitch SMD devices you can still hand solder them and use a 2 layer design.

Bill: I've not used a lot of free schematic/PCB packages, have you considered the Advanced Circuits free PCB tool? It is one of those deals where it is free software if you order the boards from them, but they are one of the cheapest in the USA for prototypes. I know a lot of folks use Eagle, but their board size limitation (for the free version) is limiting. I'll check out the software packages you mentioned.

BTW, the plug computer keeps saying it will be released for $50, but this seems to be a marketing thing for them to demonstrate that you could build a Marvell based "PC" for $50 in quantity. So far I don't know of anyone that is offering anything based on that chip for $50.

BTW, what do you guys think about bussing out the 24V on the backplane as an option? I've seen some of the slice IO guys doing this and it can shave down the front panel connector requirements (and wiring). We could limit the amount of current that the "bussed" 24V backplane could supply for power budget reasons, and anybody requiring more power would have to supply it to the front of the board. Just an option, and I don't think it is critical, but it would be nice to consider up front.

KEJR
 
W

William Sturm

Curt said:  "What I would like to make is a more or less standard PLC. It would have a rack with a Linux processor integrated driving a local bus for the 8 slots. That bus tentatively would be SPI"

I don't see how we are straying from this idea.  USB has been suggested instead of SPI.  I say lets start with SPI, it is simpler.  (although USB enabled microcontrollers are everywhere these days)  I have suggested a local microcontroller based processor board, but that is a completely optional component.  I am actually leaning more towards the Linux SBC concept, as we speak.  Have you seen the boards from Technologic Systems, they have some under 100 USD and they look pretty robust.  I'm not sure how to do a backplane and chassis, but ideas will come.

Bill Sturm
 
In reply to Bill Sturm:

> I don't see how we are straying from this idea.  USB has been suggested instead of SPI.  I say lets start with SPI, it is simpler.  (although USB enabled microcontrollers are <

Simpler is better. I think a USB communication card in place of a CPU would be useful for expansion or remote IO, but not for the backplane interface.

> towards the Linux SBC concept, as we speak.  Have you seen the boards from Technologic Systems, they have some under 100 <

These boards are pretty close to what I'm thinking to try. One of the boards is under 3" across, which would fit nicely in a Chassis even with the hardware. Bottom line is that I think there is a plethora of options here, which is good.

> USD and they look pretty robust.  I'm not sure how to do a backplane and chassis, but ideas will come. <

I have some ideas about backplane/chassis. I think it can be made rather simple but elegant.

KEJR
 
C
Hi Bill

Something I forgot to emphasize, (I was tired). The "big problem" with shop made gear is how to mount and enclose it so you don't just have a pile of boards. That is not derogatory as I have many "piles of boards":^). Here you will have a box the contains inexpensive industrial IO and is usable and presentable to customers, etc. It will be (sounding more committed) using SPI I/O chips from the company that makes PICs. They would be absolutely proud, if instead of a full blown Linux computer, you were to mount a PIC board in the box, and SPI is the native tongue. And so, this would then make a remote rack or whatever you care to do with the PIC. Other personal favorites would also fit, needing only SPI capability, and almost anything can do SPI. Of course, there might be those who would seek to cram in x86 hardware and run Windows, but that can't be helped, people do drive screws with a hammer. This would thus take care of the part of automation hacking that isn't fun. Other backplanes could be done as well, but that would mean all new card designs too. When I think about it, there are a lot of people who could use this as the world end of their special projects. Doing it in an Open fashion will probably mean continued poverty, but it should stand the best chance of making it popular. It's beginning to sound like something that needs to be done :^). When I get a chance I'll see how a sourcing output card would look and post that. Virtual mylar, Rubylith and tape are very inexpensive.

Regards
cww
 
C
A lot of my previous post got cut off. I reposted. I have done a 16 sourcing output card and sent you the .png.

Backplane is pending. I'm leaning towards a skinny backplane, both for cost and to leave space for any other busses. I have inexpensive card guides and panels figured out, but the box would probably have to be fabbed. Don't need it to test. Don't know when I can afford to get a processor board and get cards fabbed, but there's a lot of checking and tweaking to do anyway. And I can draw schematics. They will be in Qcad, which supposedly can transfer to Autocad, but that hasn't been all that satisfactory when I've tried it before.

Regards
cww
 
C
Hi Ken

> Here is what I feels strongly about: <

> - Develop an SPI based rack with electrical and mechanical specifications.
Yep.

> - The rack can be used with a CPU or a communications module (i.e. remoteIO).
> * Lets not get too detailed on what these are *Yet* There will undoubtedly be many options here.
> * Using SPI as the [rack] bus will allow many options, from completely embedded AVR/Arduino to Marvell processors.

Yep.

> - The rack should be as small as we can make it (This is to compete with the bloated solutions that already exist).

Tentatively 3" high, 3" deep and about 14" long.

----- snip -----
> I think that developing the IO rack in itself is enough of a project for now. I don't think looking at embedded linux computers is a bad idea at this point because that is where we want to go, but lets not get bogged down with the exact System on Module right now. I think I prefer the modules that are more "stamp"-like since they let you dictate where the front panel connectors (USB, ethernet) will be located on the "carrier" module. We don't want to design a rack based system around one CPU module. The "linux stamp" is such a device, but so far it seems limited to a 200MHz ARM, which should be fine for most things, but not for everything. <

I am providing for the rack to use the processor of your choice. You can make it anything that needs Industrial IO.

> I have developed IO boards based on a backplane before and I know some of the problems in doing it on your own. I was able to get it down to roughly a 3" x 3" board size while still using 16 IO points and 24VDC feed. I'd like to do some of the mechanical layout and board design if my "home time" allows for it (I have to young sons, so time is not that available). I've found that DIP devices are very much hard to find in some areas, so working with SMD is almost required. If we keep with 0.050" pitch SMD devices you can still hand solder them and use a 2 layer design. <

I would prefer that if you did, you use PCB which is free and runs on Linux for sure and I think Windows. But I have had no trouble sourcing through hole components and they make the boards much easier to build and repair. So far all I've needed are the Microchip MCP23S17 and Allegro 2982, both full production items available from the usual suspects or direct. I have first pass artwork for an input and output card and am starting on the backplane. I have a lot of time.

> Bill: I've not used a lot of free schematic/PCB packages, have you considered the Advanced Circuits free PCB tool? It is one of those deals where it is free software if you order the boards from them, but they are one of the cheapest in the USA for prototypes. I know a lot of folks use Eagle, but their board size limitation (for the free version) is limiting. I'll check out the software packages you mentioned. <

As above, I would prefer PCB because it's free no matter where you get your boards fabbed. I have used Advanced before and they had no problem with PCB Gerbers and drill charts. For any collaborative work, we need a common format and one that is totally unencumbered. All the other freebies seem to want DOS or Windows exclusively. And their libraries don't compare with PCB.

> BTW, the plug computer keeps saying it will be released for $50, but this seems to be a marketing thing for them to demonstrate that you could build a Marvell based "PC" for $50 in quantity. So far I don't know of anyone that is offering anything based on that chip for $50.

> BTW, what do you guys think about bussing out the 24V on the backplane as an option? I've seen some of the slice IO guys doing this and it can shave down the front panel connector requirements (and wiring). We could limit the amount of current that the "bussed" 24V backplane could supply for power budget reasons, and anybody requiring more power would have to supply it to the front of the board. Just an option, and I don't think it is critical, but it would be nice to consider up front. <

I have bulk 24V on the backplane, but so far have only brought out the rail the inputs or outputs work against +24 for sinking input and DC Gnd for the sourcing outputs. The wireclamp terminals are on .2" centers and 17 are all that would fit without bumping the height. I could maybe add some by setting them behind the input row, but that would make it hard to get to the screws. I need to get some samples to see if I can make the terminal strips pluggable. That's handy if you need to change cards.

I have also located a local outfit that makes enclosures and panels and such by "no tooling" forming. Once I have dimensions, I'm gonna see what they say for the card slot panels and a box.

Regards
cww
 
In reply to KEJR:

Marvel makes the chips, not the finished plug computer. They provide a reference design which other people can modify, load a Linux OS (Marvell pay for developing the Linux support for their hardware), add their own software to, and sell as a complete product. Marvell is stating that if you get the hardware made in quantity you can get it for $50.

Your own mark-up would typically be %100 (software development, advertising, cost of sales, etc.) which would result in a final price of $100. That is in fact what companies that are selling "plug" devices are charging for them (the development kits from Marvell are similarly priced). Keep in mind that they aren't selling them as bare plugs. They are selling them as personal Internet file servers, media hubs, and other such consumer goods. You could however simply wipe their software and install your own. Even at $100, that is very cheap, considering that it is a complete packaged system, not just a bare motherboard.

Whether or not this is what you want for this sort of application, it is a good example of what I would call "opportunistic hardware". It is cheap, readily available hardware that uses bog standard interfaces and can be adapted to a lot of applications.

>BTW, the plug computer keeps saying it will be released for $50, but this seems to be a marketing thing for them to demonstrate that you could build a Marvell based "PC" for $50 in quantity. So far I don't know of anyone that is offering anything based on that chip for $50. <
 
W

William Sturm

I also agree that an SPI backplane with DC I/O would be a great start. I could test it with some PIC's that I have laying around. I wonder if a desktop PC running Linux could do SPI through the parallel port?

I like the idea of bussing 24V on the backplane, anything that makes the end users life easier is good.

I have used tinyCAD and freePCB with great success, but they are Windows only and have a bit of a learning curve. FreePCB is especially good at board layouts and it makes Gerber files that can be sent to any board shop. I will look at PCB, as Curt suggested. FreePCB uses some defacto standard netlists from a CAD package, so we may be able to interoperate with various packages. Time will tell...

Open fashion may mean continued poverty, but creating a traditional PLC company would probably make you even poorer these days :) Anyone make money building boards and providing support, if they choose. Much like Linux distributions sell CD's (remember that?) and provide support.

Curt, you mentioned Virtual mylar, Rubylith and tape. Are you planning to make your own PCB's at home? I have usually had some proto boards made, but the $$$ add up.

Bill Sturm
 
In reply to Curt Wuollet: I believe that the Siemens S7-300 series uses a dual backplane. There is one set of signals for basic digital and analogue I/O, and another set of signals for "intelligent" modules. You would probably want to provide for something similar.

I'm not sure where this project is going, but before everyone gets too deep into the hardware you might want to think about what software you are going to use with it. Programming right to the bare metal makes things "simple" from a hardware perspective, but it rather limits what you will be able to do with it. I think you would want to be able to run a standard Linux build on it, (e.g. Debian). That gives you lots of basic infrastructure software which you can run on it, such as http, ftp, ssh, and database servers. It also gives you good quality development tools (e.g. compilers).

If you look into ARM chips, though, you find out there are ARM chips, and there are ARM chips. ARM themselves don't make any chips, they just design them. Various companies license the designs, add peripheral logic and sell the resulting chips. However, different companies have licensed different ARM versions with different features (due to different design generations, or size, or power budgets). This means that software support is quite varied.

What this means is that just because you see that Debian has an ARM build doesn't mean that it will run on all versions of ARM. You also have to worry about whether the drivers are in-kernel, or whether the vendor has carried them as out of kernel patches. I imagine you would just like to load a standard distro, rather than a vendor specific build that uses a 5 year old kernel and doesn't have anything beyond a few basic packages. The situation for MS Windows CE is a lot worse by the way (virtually every board support package is a custom build), but I don't imagine that is any consolation to you.

This isn't specifically an ARM problem by the way. X86 chips have the exact same issues (particularly with the "industrial" motherboards). Some x86 CPUs won't run some software because they don't have some of the newer instructions. You won't run into this if you are using the latest super-turbo CPU with a jet engine on top. Some of the older, low power, or compact chips are only 386 compatible, and won't run software compiled to use the newer instructions. I've seen this happen, so it isn't a purely theoretical problem.
 
W

William Sturm

Curt,

I have hosted your pictures under the pictures tab on my website. Keep 'em coming... I'll start adding some too, soon as I can.

Bill Sturm
Abbeytronics LLC
 
C
Back in the dark ages :^) when chip design was done on huge sheets of mylar and photo-reduced, printed circuit boards were done the same way. You took a sheet of mylar and used black tape strips for the lines and pre-cut dots for the pads. Rubylith was a red film that you applied for a second layer or ground plane. An exacto knife was our stylus. The "tape-ups" were done at 2x to 8x life size to get the precision needed and then photo-reduced and printed. Sometimes we had a draftsman to do these, but I did a lot of putzing with mylar, rubylith, and tape. It's so much more pleasant with layout software. But I still think of it as Virtual Tape. And, no, I have absorbed all the ferric chloride I need for a lifetime. I'll send them to a proto shop and if need be, a production house. But two layouts in two days would have been a very lofty goal the old way :^) It's just my nostalgic sense of humor that confused you.

Regards
cww
 
C
> In reply to Curt Wuollet: I believe that the Siemens S7-300 series uses a dual backplane. There is one set of signals for basic digital and analogue I/O, and another set of signals for "intelligent" modules. You would probably want to provide for something similar. <

Yes, I have that in the back of my mind because the expander chips can use address lines and bus the chip select. But A/D and D/A from the same outfit do not. For now, I'm just going to use wired chip selects for all the slots so that you can put any card in any slot. But it would be nice to be able to address the chips. I could do it with a 1 of 8 decoder, but the software will probably be simpler with just using the GPIO for selects. Also an 8 channel 12 or 13 bit A/D or D/A will require a lot more data to be transferred than the digital IO. If the time to service gets to be where I should wait on an interrupt, I may want to do something else.

> I'm not sure where this project is going, but before everyone gets too deep into the hardware you might want to think about what software you are going to use with it. <
----- snip -----

Rest assured, I have no intention of going back to assembler :^) The boards I have been looking at do run Debian and the latest kernels. The only difference is that it's an ARM Linux like the netbooks. The other difference is the size of course, if you can pay for the storage, it could be self hosted, The only reason to cross compile is that development would be more comfortable on a desktop. If you add a screen, you can run any of the netbook distros. But, the reason for running the flavor they provide is that they have done the driver work to interface to their mix of hardware. This means I don't have to spend as much time in the dark world of kernelspace. With working drivers, you need only open the specialfile and use the read, write, etc. methods the driver provides. I may need to do some work to add the extra chip selects, but once that's done it should be everyday C programming to use the IO. It should be much the same as using any other IO open, read, write copy the buffers, etc. In fact that's why I want to go this route rather than a Rabbit, or PIC, or ? I want to write Linux software in C as it should be:^)

> If you look into ARM chips, though, you find out there are ARM chips, and there are ARM chips. ARM themselves don't make any chips, they just design them. <
----- snip -----

Yes, and I'm only interested in the ones with a MMU so they run a "standard" kernel. You can get the latest kernel from kernel.org, apply the patches. configure it with menuconfig and compile for the AIM version which is an IFDEF in the mainstream kernel. Then you make a UBoot and a kernel image for the flash or SD card. A little different than X86 but, soon AIM will be almost as mainstream as X86. I'm sure they outnumber powerPC, MIPS, etc. already. The people selling these boards are selling a running Linux installed and configured. The SPI is a bit special since there is no way to autodetect what's out there, but they should have it working. We will need to develop the routines needed to configure and interpret what the particular chip needs, but that should be above the driver level. I could just do X86, but AIM offers far more features with far less hardware and a lot less power for a lot less money. From an application level it should be more or less transparent. You write to Linux.

> What this means is that just because you see that Debian has an ARM build doesn't mean that it will run on all versions of ARM. You also have to worry about whether the drivers are in-kernel, or whether the vendor has carried them as out of kernel patches. <
----- snip -----

I had all the same concerns. I am going in with eyes wide open. There is enough factory support and community support where If need be, I could choose a Linux distro and port it to a board. I'd rather not but it makes me comfortable that it's not a single source deal. TI Atmel, Samsung, etal. _want_ you to be able to run Linux because otherwise they don't have an OS or a community. It's hard to sell chips without people to use them. If worse came to worse, you could choose the Beagle Board and TI supports it. That's what makes this exercise practical, if it was iffy before. These are great chips. If I could think of a better overall line of processors for the task, I'd use them. But the value proposition makes it a natural.

> This isn't specifically an ARM problem by the way. X86 chips have the exact same issues (particularly with the "industrial" motherboards). Some x86 CPUs won't run some software because they don't have some of the newer instructions. You won't run into this if you are using the latest super-turbo CPU with a jet engine on top. Some of the older, low power, or compact chips are only 386 compatible, and won't run software compiled to use the newer instructions. I've seen this happen, so it isn't a purely theoretical problem. <

No, but that is the beauty of buying a system with Linux running on it already, to a greater or lesser extent, that's their problem. A mitigating factor with the ARM is that more of the bells and whistles we need for automation are built into the chip. That makes it a lot more sane than a random assortment of chips added on because you know where to find the data. They provide enough where hobbyists can make good use of their products. And at that level, as they say, it doesn't take a rocket scientist anymore. I've done *nix on several processors, I know what I need to run should be portable. And these are all somewhat theoretical problems until someone tries it. But if it doesn't work on one board and port, it's easy enough to swap in one that will work. Netbooks didn't break all the Linux software, so it can't be all that bad:^). They use many different versions of ARM and whatnot.

I really do appreciate your "clued in" concerns though, these are exactly the things that need to be examined. It would be much worse if we were locked into a particular board that made life difficult. But, that's why I am splitting the system at the SPI bus. It's sort of a universal connector, you can plug any controller in with very little work. Even a desktop. It's very low risk at this stage. It's not like I'll get fired if there's a problem or two :^).

Regards
cww
 
In reply to M. Griffin regarding plug computers:

I am aware of the facts you stated, I just wanted to clarify on this list that you can't actually buy a plug computer for $50, and to my knowledge there is not a $50-$100 "system on module" that breaks out SPI, UART, Ethernet, etc for this chip. If anyone knows of one it would be useful.

KEJR
 
In reply to M. Griffin Regarding Linux on ARM and hardware interface:

I have found several ARM SOM projects that incorporate more or less standard linux distros. Now this doesn't mean you can load Ubuntu and start browing the web, but it is undoubtedly enough to start using RTOS and http servers. We would have to pick one that is widely supported. I looked up some details of the linux SPI driver last night, and while I am not an expert it seems to be very well done, allowing you to alter the addresses of your SPI chip selects, or even rewriting the C functions that facilitate the "chip select" setting (this is probably useful if you multiplex your chip selects). We could either recompile the kernel or compile a kernel module for the SPI. It didn't seem like a big barrier at first glance, but some more eyes on it wouldn't hurt! :eek:)

This company claims they can run linux off the shelf with this SOM:

http://www.emacinc.com/som/som9G20.htm

The price isn't too bad for what you get either, and the form factor is great.

KEJR
 
Curt:

I think it is great that you are jumping into this project. I do feel is far too soon to be jumping into FR4 and "virtual mylar" before a signal specification is drafted. Although the SPI bus isn't that demanding why would you layout boards before deciding on what the features were first?

Here are some thoughts I had along those lines, some of which you had mentioned previously:

- Each "IO" slot gets the following signals:

* SPI clock and data lines
* Its own unique SPI chip select (Slot select?).
* 5V, Ground (Need to decide a power budget).
* 24V and Ground (Need to decide a beefier power budget to support driving valves, etc.)

- CPU slot will need similar, but probably wants to pass through the power supplies to the backplane, and needs enough pins for all of the SPI chip selects. I would vote for having at least 24 slot addressing because if the IO slots are small enough you can fit a lot of them into a 18" - 22" long backplane (Anything more is unreasonable in size to fab). We could all argue on the limit of the backplane size, but my point is that lets not limit the addressing capability at an early stage.

* The question is: do we bring out 5 bits of GPIO from the CPU card and have some decoder chips on the backplane, or bring all 20-24 chip selects out through the CPU card's connector? I don't exactly like having silicon on the backplane.

* Alternatively, could we just buss the 5 chip [slot] select "address" lines to each card, and fabricate the backplane in such a way that each IO slot gets its own unique address via "jumper" traces? This imparts some more complexity on the IO card since it needs to compare the two addresses, but for 5 bits this can be done in a PAL or even 74 series without a lot of pain or cost.

I don't think we should worry much about the more complicated IO cards. Reading a 16 channel A/D card will be as simple as addressing that chip select [slot] and reading in 16*16bit words. The controller software will need to have a file (or data structure) describing each slot's buffer size and how many bits [bytes? Words?] to read off of each one. Logically, in software the IO could look like a data structure, and, like MODBUS, it would be up to the program to interpret what the data means. I think its too early to get into this in detail, I just wanted to mention that ADC and DAC cards should be no problem as SPI doesn't define data size going into an out of chips [slots].

KEJR
 
C
Thank you, Bill

Got some preliminary costs, the connectors will be about $7, the chips about $1 each and the resistors $2 for the bunch, metal film, less for 2% carbon film. Boards will be $15-$20 in proto quantities. So figure a couple bucks a point, less in qty. I may have to change to 16 pins on the backplane connector, 14 doesn't seem to be a very common number. And I need to add some bypass caps, etc. But they are still very simple cards because the expander does everything. I may fuse the output card, but the drivers do have current limiting, so it may not be essential. The analog cards will be a little more complicated to add buffering and the standard voltage or current capability.

No hurry on them.

Regards
cww
 
C
Ken,

some of the boards I posted will do those at less than $100. And they will run on a wall wart.

Regards
cww
 
Curt:

Why limit the backplane pinout to 8 slots? Is that just for your initial prototype, or is that the "standard"? I understand it is simpler, but for the added cost of 8 more pins on the CPU board backplane connector there is no reason the bus specification can be extended to 16 slots (or more). You mentioned "Cabling in" the SPI connection from a CPU residing outside the rack. I'd argue to put a connector on the backplane for featuring an "In rack" CPU and then you can either wire it to a "black box OTS" CPU, or down the road someone might integrate a full blown rack CPU or something in between. We can't say that a CPU won't be home grown for the rack, as even a simple to interface AVR MCU has SPI and would make a suitable "extreme low cost" alternative for C programmable controller for hobbyists and simple automation. This would give the project a wider audience. Maybe this would even be a good way to test the rack as Bill suggests (I still favor AVR over PIC, but use what you have :eek:)

I'm a bit confused as to who is doing what and what roles are to be. I would imagine that if you want community support that some common standards might want to be addressed, and it need not be overcomplicated. The goal of an open project like this should probably be to meet the most requirements of the most users without sacrificing too much for cost or complexity.

KEJR
 
C
Hi Ken

> I think it is great that you are jumping into this project. I do feel is far too soon to be jumping into FR4 and "virtual mylar" before a signal specification is drafted. Although the SPI bus isn't that demanding why would you layout boards before deciding on what the features were first? <

Because I don't have to specify anything. The SPI is defined in the expander spec. :^) But I will document the bus layout, and I may juggle things to improve shielding.

> Here are some thoughts I had along those lines, some of which you had mentioned previously: <

> - Each "IO" slot gets the following signals:

> * SPI clock and data lines
> * Its own unique SPI chip select (Slot select?).
> * 5V, Ground (Need to decide a power budget).
> * 24V and Ground (Need to decide a beefier power budget to support driving valves, etc.) <

Yep, See, you really didn't need a spec :^) I am not going to bus 5V though, I'll generate that on the board with a 3 terminal regulator. The high line regulation will isolate input boards from output boards that can actually use substantial power. The current needed on each card at 5V is very low so a TO-66 type regulator cane be used. This also accommodates chips that may want 3.3V or ? I will bus 24V on heavy traces as the output cards can source 120mA continuously on all outs. and up to 350 mA individually limited by dissipation.

> - CPU slot will need similar, but probably wants to pass through the power supplies to the backplane, and needs enough pins for all of the SPI chip selects. I would vote for having at least 24 slot addressing because if the IO slots are small enough you can fit a lot of them into a 18" - 22" long backplane (Anything more is unreasonable in size to fab). We could all argue on the limit of the backplane size, but my point is that lets not limit the addressing capability at an early stage. <

The CPU will not be a plug in card as these are not at all standardized. And others have expressed a desire for processors that won't necessarily meet my needs. There can be slots for board mounting posts. Most of the CPU cards I've seen have peripheral connectors on all four sides so they need to mount flat. Connections to power and the SPI bus will be wired to accommodate any layout.

> * The question is: do we bring out 5 bits of GPIO from the CPU card and have some decoder chips on the backplane, or bring all 20-24 chip selects out through the CPU card's connector? I don't exactly like having silicon on the backplane. <

I will probably bring out 8 chip selects from GPIO. I did want to use the clever addressing on the expander but not all SPI chips support addressing. So, we need a chip select for each slot as you need to be able to plug any card in any slot. I have arbitrarily decided to do 8 slots, that's 128 points. Beyond that, power and scan time begin to be more problematic. You can add a second rack with a dedicated processor acting as a bus coupler speaking any of the comms supported by the main processor. This is the interest of some parties anyway, so by the time we need it they may have a bus coupler figured out:^). By keeping the CPU card unspecified the rack can economically be either a main or remote.

> * Alternatively, could we just buss the 5 chip [slot] select "address" lines to each card, and fabricate the backplane in such a way that each IO slot gets its own unique address via "jumper" traces? This imparts some more complexity on the IO card since it needs to compare the two addresses, but for 5 bits this can be done in a PAL or even 74 series without a lot of pain or cost. <

I am going to bring a chip select to each slot. I'm not going to bring an address bus as that would be redundant. And the address comparison is done against the data sent on the ones that have addressing so an external decoder won't really help much unless we don't have enough GPIO lines available. Then using 3 lines and a decoder would help. But the drivers would need to understand the sequencing. I think the drivers are written to use GPIO one line at a time.

> I don't think we should worry much about the more complicated IO cards. Reading a 16 channel A/D card will be as simple as addressing that chip select [slot] and reading in 16*16bit words. The controller software will need to have a file (or data structure) describing each slot's buffer size and how many bits [bytes? Words?] to read off of each one. Logically, in software the IO could look like a data structure, and, like MODBUS, it would be up to the program to interpret what the data means. I think its too early to get into this in detail, I just wanted to mention that ADC and DAC cards should be no problem as SPI doesn't define data size going into an out of chips [slots]. <

I will be thinking about the analog cards as the driver work needs to accommodate them. But I'm not in any hurry for them. Many of the CPU boards have A/D that can be used in the meantime.

All these points are subject to change for any good reason, but I'm going to shape up the bus in the next few days. The bus connectors on the cards are subject to change to optimize the layout, which is why I haven't generated Gerbers yet. And soon the progress will depend on getting boards made which will cost money that's hard to come by at the moment. But I want to press ahead so this actually happens. I'd rather change things based on a prototype than debate until everyone loses interest:^). The cost to change anything in this modular design will be low.

Regards
cww
 
P
This has been an interesting and thought provoking discussion. It would be fantastic if this could develop to the point where a commercial sponsor was involved, who would be able to offer assembled backplanes and I/O cards.

>cww said:
>Got some preliminary costs, the connectors will be about $7, <

While not a rigid as commercial products with a chassis, perhaps something like a 30-pin SIMM socket would work here. This approach would offer both a low-cost socket for electrical connections, plus a right-angle placement of the I/O board to the backplane. Pins are on 0.1" centers, which is easy for through-hole soldering. A casual search shows that they're available for about $2, though they're old technology and availability may be a concern.

Paul...
 
Top