Products > Test Equipment
open source GPIB adapter
julian1:
--- Quote from: alan.bain on November 21, 2023, 10:53:38 am ---Thie attachment shows the ethernet to GPIB adaptor that I use (sitting ontop of the inevitable HP box). As you can probably see this one was hand soldered (!) The central LQFP-144 is the STM32F439ZET6 and the SOICs to right the bus drivers. Voltage regulators on left and the ethernet PHY chip is on the underside.
--- End quote ---
This looks pretty interesting.
What part was used for the two transceivers? I count 20pins so perhaps 75ALS160/75ALS161 for 48mA drive and electrical compatibility with the ieee-488 standard.
Was the code ported from the AT-megato the stm32f4?
Perhaps the schematics/ footprints are hosted on github/gitlab?
dazz1:
My version of the GPIB USB adapter, based entirely on the Xyphro project, has two LEDs (red and green) but remains fully compatible with Xyphro firmware. The firmware only lights up the RED led.
the Xyphro version 2 adapter now has two LEDs on the same pins as my design. In addition, Xyphro has grounded pin xx to allow software detection of whether the hardware is 1 or 2 LEDs.
I have chosen to use two separate LEDs for Red and Green because they are readily available and cheap. My PCB design includes a footprint for a surface mounted bi-colour LED. This gives the option of two styles of LED, but not both installed.
My plan is to modify the firmware to accommodate two LEDs, while maintaining backward compatibility with the one red LED versions.
I am a "C" programming virgin, but I have done something in C-like languages.
My plan is to incrementally develop the software.
* Include a compiler switch to select 1 or 2 LEDs mode at compile/build time.
* Use a bit of the eeprom to select 1/2 LEDs mode. This would allow a user to select 1/2 LEDs.
The compiler switch is the easier option and also has the advantage that I don't have to test the LED mode in run time, that would lead to delays.
I plan to maximise use of interrupts to switch the LEDs, but I will still need to do some bit bashing in run time.
My first problem has been to setup the development environment.
With some guidance from here and running Ubuntu: https://community.platformio.org/t/can-i-create-a-platformio-avr-project-from-existing-code-including-the-lufa-library/42538/2
Install GCC:
--- Code: --->sudo apt install gcc-avr avr-libc
--- End code ---
Clone the LUFA repository into the git folder:
--- Code: ---git clone https://github.com/abcminiuser/lufa
--- End code ---
It should end up in the
--- Code: ---/home/user/git/
--- End code ---
folder. The repository will be called
--- Code: ---LUFA
--- End code ---
Clone the UsbGpib.,,,,,repository into the same git folder :
--- Code: ---git clone https://github.com/xyphro/UsbGpib.git
--- End code ---
. It should end up in the
--- Code: ---/home/user/git/
--- End code ---
folder. The repository will be called
--- Code: ---UsbGpib
--- End code ---
I then renamed the
--- Code: ---LUFA
--- End code ---
folder to
--- Code: ---LUFA_repository
--- End code ---
From the LUFA_repository folder, I moved the LUFA folder into the ~/git/UsbGpib/ folder.
From the
--- Code: ---~/git/UsbGpib/SW/MassStorage
--- End code ---
folder run
--- Code: ---make
--- End code ---
That will build the bootloader.
If you look on my Github repository here https://github.com/dazz100/UsbGpib
You will find a Linux script in the SW folder that compiles the code, then loads the firmware onto the usb-gpib adapter.
There is also a Windows batch file that just loads the firmware onto the adapter.
Both would need to be modified to match your directory structure.
I am going to edit this post as I progress to building the app.
dazz1:
Hi
I have successfully modified the firmware for 2x LED (Red and Green) operation.
After some experimentation, I think I have arrived at a user friendly signalling system.
* Slow flashing red LED = no GPIB device connected or connected but no power.
* Steady green LED = GPIB device connected, switched on, but not active.
* Fast flashing green LED = GPIB device communicating over the bus.
Simple and easy to interpret.
I have failed to figure out how to do a pull request to Xyphro's github site. Reading the instructions doesn't help. Only used Github to download files. Never used it for code development. Also my first ever crack at "c" code. Lots of opportunity to get it wrong. So although I may have messed up with Github, the code is working.
I have attached the upgraded 2x LED firmware to this post if anyone would like to try it out.
Kean:
--- Quote from: dazz1 on October 23, 2024, 02:33:49 am ---I have failed to figure out how to do a pull request to Xyphro's github site. Reading the instructions doesn't help. Only used Github to download files. Never used it for code development. Also my first ever crack at "c" code. Lots of opportunity to get it wrong. So although I may have messed up with Github, the code is working.
I have attached the upgraded 2x LED firmware to this post if anyone would like to try it out.
--- End quote ---
I'd suggest forking the xyphro code base and applying your changes to your own repo. Then link to the repo here. If Xyphro is interested, it is easy to create a pull request from your fork.
PS. you didn't attach anything. As I mention, a link to your forked repo might be better.
dazz1:
--- Quote from: Kean on October 23, 2024, 10:51:50 am ---
I'd suggest forking the xyphro code base and applying your changes to your own repo. Then link to the repo here. If Xyphro is interested, it is easy to create a pull request from your fork.
--- End quote ---
I figured out I forked a fork of xyphro so that messed things up. I have deleted to forked fork from GitHub and directly forked xyphro.
--- Quote from: Kean on October 23, 2024, 10:51:50 am ---PS. you didn't attach anything. As I mention, a link to your forked repo might be better.
--- End quote ---
I am aiming to put the modified code on my fork then request that Xyphro pull my version.
I have used compiler directives to produce ver 1 or ver 2 firmware from the same source code. Any updates to the single source code will compile for ver 1 or ver 2.
For ver 2, the red LED is only on when green is off. I found that both-on doesn't look good and is confusing. The slow flashing red LED is proof of life.
The green LED is toggled by an interrupt driven timer only when there is data transfer. The green flashes indicate activity and not quantity. A single instruction toggles the green LED only on timer ticks and only for data. Near zero added processor load. I think the RED/GREEN led pair is easier to interpret.
Next task is to get the modified firmware into my fork of Xyphro.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version