Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Jeroen Belleman Newsgroups: sci.electronics.design Subject: Re: GPIB bus topology Date: Tue, 7 May 2024 17:43:38 +0200 Organization: A noiseless patient Spider Lines: 103 Message-ID: References: <6632ba30$0$8096$882e4bbb@reader.netnews.com> <4Jq_N.40047$Z6Dc.19753@fx04.ams4> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Tue, 07 May 2024 17:41:44 +0200 (CEST) Injection-Info: dont-email.me; posting-host="322ecfb41fba6482df7a21202d6cc2bd"; logging-data="3507466"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18vjc3AOjBWELsl2naEhig5" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cancel-Lock: sha1:5WcsWHLK8C0iO/E/VoKKtt8myKU= Content-Language: en-US In-Reply-To: Bytes: 6104 On 5/7/24 17:23, Don Y wrote: > 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!] > The variety is there because of a long history of changes to induce people to buy new things. Thus it will ever be. Jeroen Belleman