Re: GPIB bus topology

Liste des GroupesRevenir à se design 
Sujet : Re: GPIB bus topology
De : blockedofcourse (at) *nospam* foo.invalid (Don Y)
Groupes : sci.electronics.design
Date : 07. May 2024, 17:23:13
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <v1dh16$3ankn$1@dont-email.me>
References : 1 2 3 4 5 6 7
User-Agent : Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2
On 5/7/2024 7:16 AM, Chris Jones wrote:
There is a board which you can get made at OSHpark cheaply which adapts the arduino pinout to the connector.
>
What I don't understand is why someone would go to the trouble to make
a daughter card and NOT just add the rest of the necessary components
TO that card and package the whole thing better/smaller!
 It's to go on the back of a GPIB instrument. It doesn't need to be small, but it is no bigger than a normal GPIB connector. It uses a small arduino "pro micro".
My point is more generic than that.  I am often approached by clients
wanting to design a "daughter card" to some existing "module".  But, there
is no *win* to using the module if you're designing (and having produced)
a daughter card -- it's just another dependency (and constraint) that you've
baked into your design.

If someone had intergated all of the components onto the same PCB as the GPIB connector I would have avoided that design.
Why?  Unless you want to be able to salvage the arduino *from* the daughter
card at a later date.  Eschew unnecessary connectors, dependencies, etc.

It is easier to buy an arduino than to build one,
But, did YOU have to build the daughter card?

and probably cheaper too if you only want exactly one of them. The adapter PCB was very cheap and building the whole thing was very quick.
Ah, that answers the previous question.  (I am talking about BUYING
a product that "does it all" instead of hacking something together)

That is what I wanted. I just wanted to back up the SRAM in my DMM before its battery went flat and lost the calibration settings, or before I accidentally erase the SRAM in the process of replacing the battery.
Understood.

OTOH, learning how to miniaturize entire products is a skill that takes
time to learn.  And, anticipating each potential future "shoe-horning"
activity is a challenge (I have a design that fits in WoW characters
but won't fit in Furbys, to my chagrin!)
>
There are relatively cheap connectors without the jack screws and daisy-chaining capability that you can use because you do not require the ability to daisy chain other cables onto the back of your USB adapter.
>
I just used an IDC-terminated connector as my PCB was largeish (old
technology) and didn't want it supported by the instrument's connector.
And, as I said, have tossed the GPIB cables opting for an adapter
per device (I suspect most folks don't really need the ability for
devices to talk to each *other*)
 Yes, and if you're doing that, it is cheaper to use the arduino adapters than National Instruments, software permitting.
Ah, but Arduinos didn't exist in 1988 -- did they?  :>

One shortcoming it has is that it will draw current from the GPIB bus if the USB cable is not powered, but it is easy to avoid doing that.
>
I would eschew anything USB-related; it often requires drivers
and places limits on where the USB host can be located.  E.g.,
I can talk to my adapter from an old SPARCstation, NeXT cube,
cell phone, etc. instead of having to add USB capabilities (and
cable) to each.
 I don't like USB, but a lot of software and hardware is set up to use it, so as
Now.  But not in the past -- or likely in the future.  In much the same
way that printer (and, soon, serial) ports went obsolete, consider how
everything USB-related will fare when The Next New Fad comes along?

long as someone else deals with the details of the USB stack and it works, I won't complain too loudly. If I have to write the low level software I will try to use something else.
I've decided that network interfaces represent the future of most
interconnects.  It's silly to keep reinventing new stacks for each
different (competing) interface.  Better to standardize on an external
interface in a device-independent manner.  Look at the mess it leaves
each time some *interface* is deemed obsolete (just because of the
specific hardware device that required it)...
[I'm looking at an external disk enclosure with three different
interfaces on it when one SHOULD have sufficed.  Or, bare disk
drives with ST506, ESDI, IDE/PATA, SATA, SCSI, Wide SCSI, SCA,
FC-AL, SAS, etc.  Needless variety.  And, that's not to mention
the cabling involved!]

Date Sujet#  Auteur
2 May 24 * Re: GPIB bus topology8Don Y
3 May 24 +* Re: GPIB bus topology2bitrex
3 May 24 i`- Re: GPIB bus topology1Don Y
4 May 24 `* Re: GPIB bus topology5chrisq
4 May 24  `* Re: GPIB bus topology4Don Y
5 May 24   `* Re: GPIB bus topology3Don Y
7 May 24    `* Re: GPIB bus topology2Don Y
7 May 24     `- Re: GPIB bus topology1Jeroen Belleman

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal