Products > Test Equipment
open source GPIB adapter
dazz1:
Hi
I have created a repository on Github. https://github.com/dazz100/UsbGpib
It contains the Kicad PCB design and the firmware for a 2x LED version of the Xyphro USB-GPIB adapter.
My version 2 of the firmware and hardware are compatible with both the Xyphro ver 1&2 hardware and software.
My version 2 is a slightly different flavour of adapter with slightly different design goals.
I have raised a pull request with Xyhpro.
I just need to finish the enclosure.
Kean:
--- Quote from: dazz1 on October 26, 2024, 10:23:26 am ---Hi
I have created a repository on Github. https://github.com/dazz100/UsbGpib
It contains the Kicad PCB design and the firmware for a 2x LED version of the Xyphro USB-GPIB adapter.
My version 2 of the firmware and hardware are compatible with both the Xyphro ver 1&2 hardware and software.
My version 2 is a slightly different flavour of adapter with slightly different design goals.
I have raised a pull request with Xyhpro.
I just need to finish the enclosure.
--- End quote ---
Excellent work. If I hadn't already built a few AR488 boards, I'd make some of these.
https://github.com/xyphro/UsbGpib/pull/67/commits
--- Code: ---119 changed files with 49,735 additions and 97,702 deletions
--- End code ---
Oof... they are probably not going to accept that pull request for obvious reasons.
Xyphro hasn't actually acted on a pull request for a couple of years in any case, and some of those were much smaller.
But at least the pull request can be found by others who may be interested - although I suspect they are more likely to find your repo link from here.
Just some suggestions:
It is best to submit pull requests in small chunks that can be quickly reviewed and ideally also quickly tested.
The white space cleanup is great, but makes the pull request a nightmare to review. Painful, but that would be best separated.
Deleting the older V1 files is not ideal as they are still relevant to others.
dazz1:
--- Quote from: Kean on October 26, 2024, 05:16:51 pm ---
Excellent work. If I hadn't already built a few AR488 boards, I'd make some of these.
--- End quote ---
I can feel my head swelling already :)
--- Quote from: Kean on October 26, 2024, 05:16:51 pm ---https://github.com/xyphro/UsbGpib/pull/67/commits
--- Code: ---119 changed files with 49,735 additions and 97,702 deletions
--- End code ---
Oof... they are probably not going to accept that pull request for obvious reasons.
Xyphro hasn't actually acted on a pull request for a couple of years in any case, and some of those were much smaller.
But at least the pull request can be found by others who may be interested - although I suspect they are more likely to find your repo link from here.
--- End quote ---
OK but not obvious to me. I haven't yet figured out the Github etiquette This was an all or nothing change. I wanted to submit a complete and completed package, not a series of half baked code changes. If Xyphro is not processing pull requests, the point is moot.
--- Quote from: Kean on October 26, 2024, 05:16:51 pm ---Just some suggestions:
It is best to submit pull requests in small chunks that can be quickly reviewed and ideally also quickly tested.
--- End quote ---
The actual code changes are minor. The biggest changes were to the supporting documentation. Most users won't look at the code. They will look at the documentation and are likely to judge the quality of the software and the project as a whole based on the supporting documentation. In too many projects I have reviewed, too much good information is buried in forum posts. So I have made a point of updating the supporting documentation for users.
--- Quote from: Kean on October 26, 2024, 05:16:51 pm ---The white space cleanup is great, but makes the pull request a nightmare to review. Painful, but that would be best separated.
--- End quote ---
OK. I now know that.
My editor highlights redundant white space so it is really annoying to leave in.
--- Quote from: Kean on October 26, 2024, 05:16:51 pm ---Deleting the older V1 files is not ideal as they are still relevant to others.
--- End quote ---
When making a pull request, I was expecting to have the option to mark the files to pull. It seems that the pull request is for the whole of my fork. If there is a way to mark files for pull, I haven't found it yet. I am still on training wheels for Git and Github. So it wasn't my intention that Xyphro deletes the version 1 stuff. When I edited the README file, I did not delete any version 1 stuff.
There is no point in me retaining any Ver 1 stuff in my repository so I have started cleaning it out so it ends up containing only my Ver 2. That will include the README file. The enclosure is the last design work I need to finish. I am learning FreeCAD to do that.
My aim has always been to keep my modifications compatible with the Xyphro versions 1 & 2 hardware and software. Probably need to change my version numbering to something like ver 2e (e=enhanced) to avoid confusion. I have been in communications with Xyphro for a long time so he has already included some of my suggestions in his code and hardware. There isn't that much difference between the two version 2's, which was always the intended outcome. More than that, I was hoping that my contributions would be rolled into the Xyphro project to make my fork redundant.
So naturally I consider my version to be the best version but only because I tweaked the design to match my design goals. :D Someone else might choose another version that better suits their needs. That is the really nice feature about open source designs. It gives people choices.
coromonadalix:
if your design suit your needs :-+ and for sure i would love more leds / indicators
i have 2x of the Xyphro adapters, no complaints ... works fine ... but sometimes i would have loved more leds to get the connection status ...
i hope you'll do some tests with wingpib or other gpib softwares, the id string can play tricks ...
Kean:
--- Quote from: dazz1 on October 26, 2024, 08:09:53 pm ---OK but not obvious to me. I haven't yet figured out the Github etiquette This was an all or nothing change. I wanted to submit a complete and completed package, not a series of half baked code changes. If Xyphro is not processing pull requests, the point is moot.
--- End quote ---
No better way to learn than have a go, and you've proven yourself to be someone that does that.
I'm no expect on Github either, and I've only done a few pull requests. You can make some changes to the pull request once created, either via command line or the web interface - but it will be via changes to your fork. Sometimes the best way is to create a branch for the pull request, which you can delete later.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version