Electronics > Open Source Hardware

Open bus architecture for instrumentation/control (VME, VXI). Feedback wanted

<< < (3/3)

msat:

--- Quote from: T3sl4co1l on November 11, 2020, 08:42:40 am ---
So get a bigger one!  SoM, rPi, etc.  Or any kind of PC, from the same sorts of things to mini motherboards to full boxes. ;D

Obviously as things get bigger, you'll need to manage the higher bandwidth buses and OS stuff.  Which is why PCIe looks attractive, even if just used to route between hubs (more PCIe lanes) and bridges or peripherals (e.g. USB ports, and more hubs from there?).

It's a logistical problem, no matter how you slice it.  I'm not sure what kind of scale you're talking -- how many, and how many kinds of, things you want to use at once, but it starts to sound like coordinating all of them together is your challenge, and the platform and the ratio of hardware to software work required, is just a symptom of that, not the core problem.

Also if you're working with a lot of mechanical stuff, that's a very much solved problem, in everything from industrial automation to hobby CNC.  PLCs are plenty smart these days!  (Again, the amount of solution being in relative terms...)

And there's always the go-to lab options, like National Instruments' DAQ systems.  They've solved it top down bottom up, from GUI interface to hardware.  The price is a tiny fraction of the labor required to recreate it -- very much worthwhile, if you're doing as much work as it sounds like you are.

--- End quote ---

From my understanding, a RasPI (I got one of those tiny ones when they were $5, but I never even powered it up) are not all that great at twiddling bits on their GPIO pins compared to many "lesser" micros. Of course, there are some beefy-ish SoCs from the likes of TI and ST that have additional cores meant for real-time IO stuff.

Don't get me wrong, I think PCIe is pretty amazing. It can support a metric buttload of bandwidth at very low latencies. If you need maximum performance, you won't find it anywhere else, especially considering the hardware is baked in on all modern CPUs, unlike when PCI, AGP etc used to be implemented in a northbridge chip, and translated to whatever bus sat between that and the CPU.

I'm not sure what scale I'm talking about either, lol. What I do know is that I want something that can easily scale with growing requirements for experiments. I think others could find value in that too. I could probably continue to get by with the way I've been doing things, but it does get messy and it bugs me. There's been times when I hacked together a circuit which did the job just fine (if maybe a little delicate) but looking at the damn thing drove me nuts so I went ahead and created an PCB for it. Maybe a waste of time, but it sure does make me feel better!

There is a lot of nice equipment out there that already exists, but I have it stuck in my head that for a variety of functions it would be cheaper to build much of it myself. I'm probably wrong, but I like building stuff!



--- Quote ---
Meh, isolation doesn't bother me anymore.  Avoiding loops is a system level problem, you can only mask it with local solutions.

That said, isolation does happen to be a local solution with unusually high efficacy...  But indeed, it's not the simplest thing to do, in terms of parts required, or cost of modules.

Taking differential measurements is the easiest partial solution, and just avoiding ground loops in the system in general.

Something a PC can be a PITA with, an experience I've already had on my bench.

Most recent example: PC is plugged in and grounded.  USB goes to a hub, to various peripherals, including a serial port and programmer.  These connect to the EUT, a DSP project.  The audio output from which also goes to the PC (sound card).  It's powered by the bench supply (floating), and probed by the scope (grounded).  Well, something about these three paths (USB, audio, scope) leaves a lot of noise, and it's not actually RF interference being detected, it's low frequency (including DC) offsets.  Noise goes away when any of the three is disconnected.  (Best I can tell, it's actually coming from the PC's USB port, but it's weird.)

I solved the noise issue, for testing purposes, by building a differential amplifier on the breadboard.  This reads the audio input's ground reference, and translates the DSP's output level to the new ground reference.  Voila, noise gone.  It happens to be a local solution, but driven all the same by system-level understanding.

And laptops can be even worse, sometimes a buzz or whine comes through the charger so they're quiet when unplugged, but you only get some hours of runtime before you have to plug it back in again.
--- End quote ---

Your method of choice for isolation is certainly valid, but if we're talking about a bus architecture that's intended to communicate back to a computer via USB, then you pretty much have to consider it at the very least on the USB side, especially if you can't have the hardware powered by it. Now, USB3 is differential dual simplex. Looking at the FX3 chip's tech ref manual, it appears that the device attempts initialization via USB3, and if that fails, falls back to USB2 (controllable via software). That makes me wonder whether I could disable all USB2 functionality and also avoid sharing the grounds. Perhaps that's not the best practice, but the question is, how bad of an idea is that?


--- Quote ---

You could easily make (or get) a little dev board that's an MCU and a few ports pinned out, and send e.g. serial commands to it, via RS-232, USB, whatever; more generally, a character-mode interface with internal state.  You have commands to set and read register states, and in turn affect the state of whatever's attached to it.

Then it's just a networking and data collection problem, managing a plurality of such interfaces.  ("Just", he says :) )

Wouldn't be conducive to 50MHz QSPI, no, but... do you really need that?  If you're going to blast a bunch of SD cards or something, just plug 'em into the poor computer in the first place..?!!
--- End quote ---

Not everything would need 50MHz QSPI, no, but some things certainly might! The nice thing is, a device that can do QSPI can also do regular SPI at a variety of frequencies. It's there if you need it, but you don't have to use it. If I could find one, I'd seriously consider a uC that can either do USB2 Hi-Speed or USB3 and have two QSPI hardware peripherals. If it was USB2, I'd power the chip off the bus, and then isolate the SPI side.


--- Quote ---I did this exercise in GPIB, adapting a popular codebase to the platform/interface I opted for; the generalization of that is SCPI, as I understand it?
--- End quote ---

I briefly started looking into SCPI after if got mentioned in the thread Doctorandus_P linked too. I haven't made my way through the whole thread yet, but a lot of my thoughts/concerns had already been brought up there, so I feel like I'm kind of on the right track.


--- Quote ---This is generally how I approach one-offs, demo new peripherals, etc.  I have a serial command line interface I drop into the project, then patch in whatever specific commands I need to play with the device in question.  Then build up more elaborate commands to automate e.g. initialization, read/write cycles, drawing graphics for displays, etc.  Most recently I did this with an emulated (via GPIOs) parallel bus, but also SPI and etc.  Or just twiddling I/O registers directly (or doing some light debugging of the program itself, by viewing/twiddling RAM).

Oh hey I've even got a released example: https://github.com/T3sl4co1l/Reverb

Maybe you'd have to do this anyway, just for starters.  I don't know that you'd be able to avoid this, aside from dropping in someone else's drivers or whatever for some particular device -- in any case, that of course still leaves the next layer up, coordinating everything.
--- End quote ---

I have no real idea how the software side (not related to firmware) is going to work, yet. Obviously, it would be wisest to stick with existing standards where applicable. So perhaps other than standardized USB APIs, I don't want to specify any particular software tools or programming languages.



--- Quote ---

SATA and USB3 would also be options?  I'm not sure how general-purpose SATA is, it's almost always used for drives.  But USB is definitely attractive, and offered by most everything, yeah.

Also, IEEE 1394?  Not even sure offhand if that's an enumerated bus or point-to-point only... I never have to use it. :-DD

Tim

--- End quote ---

So I'm all but dead set on going with USB3. It's widely supported by computers (not so much on micros - just fancy SoCs), and offers a good amount of bandwidth with pretty low latency. At the very least, USB2 Hi-Speed. Avoiding everything else, including ethernet.

Honestly, 1394 wouldn't be that bad. However, it's no longer supported by Windows, meaning there's probably not a single new computer out there that has a 1394 port, nevermind an SBC.

msat:
After a lot of back and forth consideration, and not wanting to back myself into many corners, I realized I can accomplish much of what I want with minimal standardization and do things on an as-needed basis in a way that's most convenient at the time. Really, what this will boil down to is visible cleanliness. So I'll merely be stuffing everything in a 3U subrack with no backplane (at least not a global one). Other than limiting modules to a maximum 100mm height, depth will be variable (up to some maximum, of course). Connections to modules will be made with suitable cables (USB, etc) as needed. COTS parts will be used when possible (USB hubs, dev boards, etc) and either they can be attached to 100mm carrier board, or rails can be 3D printed to accept smaller boards. Faceplates can be 3d printed as well. Not only is this the simplest/quickest, but also the most flexible since probably all of the modules would at least in part be designed by myself anyways. I ended up realizing that the main benefit of standardization is compatibility which is really only important if you're buying rather than making hardware. Since any standard bus I'd create would not have much uptake (and I had no appetite to try to commercialize it), what compatible hardware would there be to buy? So I've come up with a name for my "new" "standard": Low Standards  ;D

wizard69:
When you mentioned that the Home lab is your usage goal, off the shelf solutions are the only choice.   This for easy to obtain software and hardware.   I mean really how many years do you have to write software and and validate hardware.

From my perspective you have two choices to get up and running quickly and that is USB and Ethernet (power of Ethernet being very interesting here).   The nice thing here is the hubs used to support this can go to (wire to) a card edge connector if you want cards mounted in a rack.  The racks card edge connectors can take care of any other signalling you may need.   In either case USB or Ethernet allow going off reservation to more commercial instruments.

Back in the day I worked on machine tools built upon card logic.   In this case they used Euro Card racks with pin and socket connectors.   The racks connectors where wired manual point to point with very fine wire.   I know this due to the fun of doing updates to the machine, back then updates involved soldering irons.   Using such connectors might be one of the better ways to accomplish what you want.   You can then wire every module as you like.

haastyle:
After dreaming myself of inventing some new standard cheap rack/backplane solution for DIY electronics, I quickly came to the same conclusion.
I'm going to just use a standard 3U rack card holder on a standard 19in rack and then connect each card with a USB cable to a USB hub. This is the rack card holder I got:
https://www.vectorelect.com/subrack-eia-snap-in.html
Model CCA13S/90 holds up to 21 cards in a 3U 19in rack and costs ~200USD.
I'll also need a custom backplane to connect other signals on the cards together (for serial UART, clock sync, etc), but that's a pretty easy and cheap board to make. JLCPCB can do boards up to 500mm wide, which is more than the 19in rack.
There's lots of options for the card-backplane connector, but I may just use simple .1in pin headers. They'll do the job, and nothing is cheaper.

I'm curious about exactly what others have done for solutions like this - please share! I couldn't find many of these 19in card rack holders... are they other good choices? Any clever ideas for the backplane or connectors? What about front panels?

wilhe_jo:
Well, one I thought about repurposing hot-swap harddrive cages. However, there's no standard size for this.

Another thing I was considering was designing everything to fit comon pc enclosures...

In the end, I ended using enclosures that just fit....

The modularity would have caused too much overhead.

However, those Sata and sas connectors could be a good fit for you... at least in all these laptops, harddrives are just pushed into their slots.

73

Navigation

[0] Message Index

[*] Previous page

There was an error while thanking
Thanking...
Go to full version