the way I'm doing my t/m remote control stuff is now focused on wifi REST calls for simple gets and sets. for that, you dont need esp32, esp8266 is more than enough. the only reason I'd HAVE to use a 32 is if I went with bluetooth for some reason. some lower cost meters use BLE as their remote control and for that the esp32 would be ideal.
Well, if you look at the espressif website, they recommend migrating from the ESP8266 to the ESP32-C2... so I'd call this EOL/obsolete...
the meters I'm more interested in are those that have serial interfaces. for that, software serial is more than enough for an esp class chip.
But that's a totally different usecase to the AR488, right?
AR488 is about controlling IEEE488 aka GPIB... that's a multi-drop bus with interrupts, byte-wide data bus and handshake signalling.
no usb wanted or needed. certainly not 'real' usb. usb-serial would be sort of ok, but micros usually cant do usb inputs, they are uart focused. so having serial wrapped in usb is overkill and not useful to me.
Are you sure? My boards programm via USB (just press a button to switch to the preprogrammed internal usb-bootloader), get power via usb and use usb for comms. That's just 1 single cable that can get extended with ease using active cables (I've done 10 without any issue in my 3d print farm).
for streaming output, websockets are fine. espnow is also fine for some things (esp to esp comms).
but mostly I'm using just 'curl -s' to get and set things. start polling, stop polling, get values, set config, restore config, etc.
I have power supplies, meters, dc loads and planning other things that use this method of config/control.
(in my last several jobs, I got into the json religion and never looked back. connectionless fetches via REST are so simple and so fast, I dont see much need for other forms of remote control anymore)
Well, GPIB isn't really something you want to use in an connectionless environment.
You're better off blocking any but one concurrent connection!
At some point you'll try to run 2 tests using the same equipment by accident, and you'll mess up you readings... that's when you start to lock equipment carefully.
BTW. that's exactly what GPIB does. You lock the local "UI" when you control equipment via the bus.
I run a pre-compliance EMC lab with quite some equipment.
For my testing, I have created a Qt6 application (there are some UI things that are missing... but there are plans to get it published as open source) that abstracts the workflows, test equipment and (bus) interfaces.
In fact, the workflow doesn't bother whether I use my PMM 9060 receiver, or my trustworthy Advantest R3271 via an Arduino AR488, my ESP32-S2 AR488 or some old galvant GPIB dongle.
Just replace the receiver in the measurement chain, and you're good to go.
The abstraction is done in software, and not on the interface to the hardware.... but again, different usecase...
Additionally, I don't want wireless comms to my equipment. Again, I run a EMC lab, and I have situations (eg. getting the radiation pattern of an antenna) where my EUT would kill any wifi comms, and I don't want any other active transmitter to have a clean reading... again, special usecase...
So there's a very, very good reason why USB is a good thing to control instruments.
Yes, Ethernet might be also an interesting solution, but getting POE right, tiny and reliable is way more difficult than "just" have a USB cable connected to 2 pins
I've been working on an api infra for all this so that the user only has to write a few lines to get all that up and running.
I do plan to release to my github but its not there yet, still under devel. but its been running for a while now (years) and its proven itself in my labs.
Been there, done that... still not ready for publishing after 3 years of constant development... the problem is to make the UI.
Just a script-set isn't really what you want/need... maybe as a start, but at some point, you want to have nice graphic.
Then, you want to do protocols right in there, because why would you keep the protocol separate from the measurement, right?
After a while, editing the (json) config files gets boring, so you need some sort of config-dialogs.
It's endless....
73