AR488 Arduino-based GPIB adapter

[WaveyDipole]

I have used a very rudimentary ESP8266 code from here:
https://github.com/roboremo/ESP8266-WiFi-UART-Bridge
Not very comfortable as it can only be configured by changing the source code and you have to find out the dynamically assigned IP address somehow.
I'm not very experienced with ESP8266 programming.
So, a proof of concept! But that's the way I want to talk with my instruments eventually! 

Thanks for sharing your proof of concept experiment. I can't see the numbers on the TO-220 device, but I presume that since the Pro Micro has no on-board 3.3V regulator, that you had to use an external regulator? Do the 4 resistors form a pair of dividers to convert the serial TTL level signal on the Arduino to 3.3V level for the ESP8266? I have used the resistor divider technique to shift the TX signal level down to 3.3V as well, but I then came across these for level shifting:

https://www.ebay.co.uk/itm/5Set-4Channel-Bi-Directional-Logic-Level-Shifter-Converter-3-3V-5V-SP-es/392511885681

Cheap enough and they have the advantage of shifting the 3.3V signal transmitted from the ESP8266 back up to 5V for the Arduino. For Bluetooth I needed 3 channels so this little board with 4 channels came in handy.

I have for some time been working on my own version of the TCP to UART concept and given your interest in the ESP8266, was thinking that this would be an opportune time to share this work-in-progress version of the sketch. You can set either a static or DHCP IP address and also configure WiFi via a simple web based interface. You can use the programmed ESP8266 as a stand-alone WiFi AP or connect it to an existing WiFi network. You can choose which port to use for both the web interface and the bridge terminal. It works for most part but is not quite complete yet. For example, saving to EEPROM is not yet implemented and there is no proper security. I have tested using Firefox and Chrome/Chromium, but not yet on Internet Explorer/Edge or Safari. I would be interested in any observations you or anyone else may have. If you have a chance to try it, then let me know what you think.

Note: Attachent now removed.

[tom_iphi]

@ WaveyDipole

I can't see the numbers on the TO-220 device, but I presume that since the Pro Micro has no on-board 3.3V regulator, that you had to use an external regulator?

Indeed, it is a LF33 3,3V regulator for the ESP8266.

Do the 4 resistors form a pair of dividers to convert the serial TTL level signal on the Arduino to 3.3V level for the ESP8266?

Not quite. Two of them are pull-up resistors as two of the ESP8266 inputs need to be pulled up, e.g. the reset input.
The other two are 470 Ohms serial resistors in the RX and TX UART lines. These are indeed for overvoltage protection of the 3,3V ESP driven by the 5V Arduino.
They just do current limitation. Voltage limitation is achieved by the input clamping diodes inside the ESP chip. As I never know, which line is actually the 5V line that needs the limitor resistor, I simply add a resistor to each line to be on the safe side. It won't do any harm if it is not needed. It is the simplest way of level adaption. Btw, it is safe to drive a 5V input with 3,3V as the switching threshold is 2,5V, giving 0,8V of margin which I consider as sufficient.

I have for some time been working on my own version of the TCP to UART concept...

This sounds like a very comfortable solution. I would be very interested to give it a try. Where can I find the code?

And another thing:
May I propose a small update to the Mega32U4 config code:

Code: [Select]

/*** MEGA 32U4 based boards (Micro, Leonardo) ***/
#elif __AVR_ATmega32U4__
  /*** Board/layout selection ***/
  #define AR488_MEGA32U4_MICRO
  /*** Serial ports ***/
  // Comment out if using RXI, TXO pins
  #define AR_CDC_SERIAL
  // The Mega 32u4 default port is a virtual USB CDC port named 'Serial'
    #ifdef AR_CDC_SERIAL
      #define AR_SERIAL_PORT Serial
    #else
      #define AR_HW_SERIAL
      #define AR_SERIAL_PORT Serial1
    #endif

The added preprocessor code simplifies switching between CDC and HW serial, so acutally commenting out the indicated line will suffice to switch.


@ Gerhard_dk4xp

Hi Gerhard, nice to hear from you again.
I hope, the Jalapenos grow well on your new balcony.

Best regards,
Tom

[tom_iphi]

@ WaveyDipole

Ah, found the ESP code attached to your post. 
Many thanks! 

[tom_iphi]

I have just run a test with AR488-wifi, so far without GPIB adapter.
I could flash the code but I did get a strange error message after flashing was complete:

esptool.py v2.8
Serial port COM5
Connecting....
Chip is ESP8266EX
Features: WiFi
Crystal is 26MHz
MAC: bc:dd:c2:47:40:6b
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 1MB
Compressed 318336 bytes to 223301...

Writing at 0x00000000... (7 %)
Writing at 0x00004000... (14 %)
Writing at 0x00008000... (21 %)
Writing at 0x0000c000... (28 %)
Writing at 0x00010000... (35 %)
Writing at 0x00014000... (42 %)
Writing at 0x00018000... (50 %)
Writing at 0x0001c000... (57 %)
Writing at 0x00020000... (64 %)
Writing at 0x00024000... (71 %)
Writing at 0x00028000... (78 %)
Writing at 0x0002c000... (85 %)
Writing at 0x00030000... (92 %)
Writing at 0x00034000... (100 %)
Wrote 318336 bytes (223301 compressed) at 0x00000000 in 23.7 seconds (effective 107.4 kbit/s)...
Traceback (most recent call last):
  File "C:\Users\baier\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.6.3/tools/upload.py", line 65, in <module>
    esptool.main(cmdline)
  File "C:/Users/baier/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/esptool\esptool.py", line 2938, in main
    operation_func(esp, args)
  File "C:/Users/baier/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/esptool\esptool.py", line 2398, in write_flash
    res = esp.flash_md5sum(address, uncsize)
  File "C:/Users/baier/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/esptool\esptool.py", line 104, in inner
    return func(*args, **kwargs)
  File "C:/Users/baier/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/esptool\esptool.py", line 691, in flash_md5sum
    timeout=timeout)
  File "C:/Users/baier/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/esptool\esptool.py", line 369, in check_command
    val, data = self.command(op, data, chk, timeout=timeout)
  File "C:/Users/baier/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/esptool\esptool.py", line 347, in command
    p = self.read()
  File "C:/Users/baier/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/esptool\esptool.py", line 292, in read
    return next(self._slip_reader)
  File "C:/Users/baier/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/esptool\esptool.py", line 2045, in slip_reader
    raise FatalError("Timed out waiting for packet %s" % waiting_for)
esptool.FatalError: Timed out waiting for packet header
esptool.FatalError: Timed out waiting for packet header

What does this want to tell me?

I'm not sure I fully understand what should work already and what shouldn't work yet.
I could connect in AP mode. The configuration pages are extremely nice! 
When this is fully functional, it is definitely going to be my favorite! 
I could only connect to port 80, but not to port 8488. I'm using YAT as TCP client.
I could not send anything over from YAT to the UART monitored with the Arduino serial monitor.
Is the bridge function already working?
I could not switch to station mode. The chip continued to stay in AP mode.
When I toggled switches, went to another tab and returned, then the switch settings were in default position again.So, it seems changes are not accepted yet.

Any hints are welcome.

[WaveyDipole]

I would like to support something like this at the USB level in the 32u4 version (so it appears in dmesg and lsusb listings) , though that's not trivial as the current USB driver doesn't support custom names.

If I did that, should it hang off the proposed ++id idea or should it be yet another level of naming ?

Looks like this can be done by programming the FTDI firmware with a program called FT_Prog (formerly Mprog):

https://forum.arduino.cc/index.php?topic=50607.0

I haven't found anything equivalent for the CH340 clones, but I did find some references to programming this on the Teensy 3.0:

https://forum.pjrc.com/threads/23523-Change-device-name
https://forum.pjrc.com/threads/23796-How-to-change-Teensy-3-0-PRODUCT_NAME

I have not come across any information regarding programming this for the Arduino CDC yet, but if the current USB driver doesn't support custom names then that probably explains why. In any case it seems that such a change would need to be programmed into UART firmware or at compile time so implementing it into a runtime command may not be feasible. It is an interesting idea though and I will keep an eye on developments.

[WaveyDipole]

I have just run a test with AR488-wifi, so far without GPIB adapter.
I could flash the code but I did get a strange error message after flashing was complete:

esptool.py v2.8
Serial port COM5
Connecting....
Chip is ESP8266EX
Features: WiFi
Crystal is 26MHz
MAC: bc:dd:c2:47:40:6b
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 1MB
Compressed 318336 bytes to 223301...

Writing at 0x00000000... (7 %)
Writing at 0x00004000... (14 %)
Writing at 0x00008000... (21 %)
Writing at 0x0000c000... (28 %)
Writing at 0x00010000... (35 %)
Writing at 0x00014000... (42 %)
Writing at 0x00018000... (50 %)
Writing at 0x0001c000... (57 %)
Writing at 0x00020000... (64 %)
Writing at 0x00024000... (71 %)
Writing at 0x00028000... (78 %)
Writing at 0x0002c000... (85 %)
Writing at 0x00030000... (92 %)
Writing at 0x00034000... (100 %)
Wrote 318336 bytes (223301 compressed) at 0x00000000 in 23.7 seconds (effective 107.4 kbit/s)...
Traceback (most recent call last):
  File "C:\Users\baier\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.6.3/tools/upload.py", line 65, in <module>
    esptool.main(cmdline)
  File "C:/Users/baier/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/esptool\esptool.py", line 2938, in main
    operation_func(esp, args)
  File "C:/Users/baier/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/esptool\esptool.py", line 2398, in write_flash
    res = esp.flash_md5sum(address, uncsize)
  File "C:/Users/baier/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/esptool\esptool.py", line 104, in inner
    return func(*args, **kwargs)
  File "C:/Users/baier/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/esptool\esptool.py", line 691, in flash_md5sum
    timeout=timeout)
  File "C:/Users/baier/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/esptool\esptool.py", line 369, in check_command
    val, data = self.command(op, data, chk, timeout=timeout)
  File "C:/Users/baier/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/esptool\esptool.py", line 347, in command
    p = self.read()
  File "C:/Users/baier/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/esptool\esptool.py", line 292, in read
    return next(self._slip_reader)
  File "C:/Users/baier/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/esptool\esptool.py", line 2045, in slip_reader
    raise FatalError("Timed out waiting for packet %s" % waiting_for)
esptool.FatalError: Timed out waiting for packet header
esptool.FatalError: Timed out waiting for packet header

What does this want to tell me?

I'm not sure I fully understand what should work already and what shouldn't work yet.
I could connect in AP mode. The configuration pages are extremely nice! 
When this is fully functional, it is definitely going to be my favorite! 
I could only connect to port 80, but not to port 8488. I'm using YAT as TCP client.
I could not send anything over from YAT to the UART monitored with the Arduino serial monitor.
Is the bridge function already working?
I could not switch to station mode. The chip continued to stay in AP mode.
When I toggled switches, went to another tab and returned, then the switch settings were in default position again.So, it seems changes are not accepted yet.

Any hints are welcome.

That looks like the write did not complete for some reason. One thing I noticed is that your esptool.py version is later than mine - I have version 2.6 vs your 2.8 - so I presume you are using a later version of the IDE than me. I was using version 1.8.9 of the IDE, 2.5.2 of the ESP8266 library and I'm working on Linux Mint 19. Being curious about this problem, I updated the ESP8266 module library to version 2.6.3 and this invokes esptool.py version 2.8 - but it was now broken! I don't even get any percentage of upload, just similar error messages to the ones you are getting and the final one:

Code: [Select]

esptool.FatalError: Failed to connect to ESP8266: Timed out waiting for packet header
esptool.FatalError: Failed to connect to ESP8266: Timed out waiting for packet header

I thought that I had messed up my NodeMCU module, but I tried reverting the library back to version 2.5.2 which fortunately is quite easy to do in Board Manager, and found that the sketch uploaded just fine again. I then checked version 2.6.0 which comes with esptool.py version 2.7 and this gave the same errors, so I think there is a problem with the later version of esptool.py. I reverted back to 2.5.2 and uploaded again and am relieved to find that my NodeMCU ESP8266 is still working OK!

The switches and the pass-through should have been working. Pass-though is initially disabled but can be enabled with the slide switch and then clicking Apply. I will check the switching between station and AP mode. Although it had worked when tested previously, I guess it is possible that some change may have broken it.

[tom_iphi]

I have hooked up the GPIB adapter to the ESP and changes made in the AR488 tab appear to go into the adapter and are being reported back correctly.

A manual function there to enter a string and send it to the adapter and see the answer would be handy for trouble-shooting.

And one more suggestion: It would be useful if you could check a GPIO pin upon power up and depending on its level force the device into AP mode. One could then add a little push-button to the hardware to use this function.

Pass-though is initially disabled but can be enabled with the slide switch and then clicking Apply.

I assume this is the "GPIB Pass" switch on the General tab. I can switch it on, but there seems to be no effect. Leaving the tab with the switch in ON state and returning back will show the switch in OFF state again.

I was using version 1.8.9 of the IDE, 2.5.2 of the ESP8266 library

I'm using Arduino 1.8.10 on Win10, ESP library 2.6.3.
I will revert to ESP library 2.5.2 and report my findings

[tom_iphi]

I have downgraded to ESP library 2.5.2.
The upload log looks very different now, lots of hex code, I just include the end:

    e72c44891aed2416 55398a91cdbea4a0 | .,D...$.U9......
    703642490fb0860d f0bc0d4f96963568 | p6BI.......O..5h
    1dac81a9610df396 b286831ed6f0ff16 | ....a...........
    3007c807cab900e5 0280722540f12740 | 0.........r%@.'@
    f118a0f80cd0392b dee0331d4f000088 | ......9+..3.O...
    4baf88c0                          | K...
TRACE +1.839 Read 1 bytes: c0
TRACE +0.000 Read 8 bytes: 0111020000000000
TRACE +0.010 Read 1 bytes: 00
TRACE +0.000 Read 2 bytes: 00c0
TRACE +0.000 Received full packet: 01110200000000000000

Wrote 324640 bytes (225952 compressed) at 0x00000000 in 25.5 seconds (effective 101.9 kbit/s)...
TRACE +0.000 command op=0x13 data len=16 wait_response=1 timeout=3.000 data=0000000020f404000000000000000000
TRACE +0.000 Write 26 bytes:
    c000131000000000 000000000020f404 | ............. ..
    0000000000000000 00c0             | ..........
TRACE +1.729 Read 1 bytes: c0
TRACE +0.000 Read 8 bytes: 0113120000000000
TRACE +0.380 Read 1 bytes: 42
TRACE +0.000 Read 18 bytes:
    afae3076ff198867 57751062f1424e00 | ..0v...gWu.b.BN.
    00c0                              | ..
TRACE +0.000 Received full packet:
    0113120000000000 42afae3076ff1988 | ........B..0v...
    6757751062f1424e 0000             | gWu.b.BN..
Hash of data verified.

Leaving...
TRACE +0.009 command op=0x02 data len=16 wait_response=1 timeout=3.000 data=00000000000000000040000000000000
TRACE +0.000 Write 26 bytes:
    c000021000000000 0000000000000000 | ................
    0000400000000000 00c0             | ..@.......
TRACE +0.000 Read 1 bytes: c0
TRACE +0.000 Read 11 bytes: 01020200000000000000c0
TRACE +0.000 Received full packet: 01020200000000000000
TRACE +0.000 command op=0x12 data len=4 wait_response=1 timeout=3.000 data=01000000
TRACE +0.000 Write 14 bytes: c0001204000000000001000000c0
TRACE +0.010 Read 1 bytes: c0
TRACE +0.000 Read 11 bytes: 01120200000000000000c0
TRACE +0.000 Received full packet: 01120200000000000000
Hard resetting via RTS pin...

Looks like the upload was successful. But no change to functionality.
Changes on tabs General and wifi do not take effect.

Please let me know if I can do further tests at this point.

Best regards

[WaveyDipole]

I have downgraded to ESP library 2.5.2.
The upload log looks very different now, lots of hex code, I just include the end:

....

Looks like the upload was successful. But no change to functionality.
Changes on tabs General and wifi do not take effect.

Please let me know if I can do further tests at this point.

Best regards

Since you got to the 'Hard resetting via RTS pin...' bit, this looks like the upload process did indeed complete successfully. It seems that we both have problems with the later versions of the library. That is interesting to note and it appears that an issue has been logged on the esptool.py Github project page. I have added my own observations to this issue:

https://github.com/espressif/esptool/issues/509

Regarding the hex data in the output, this will be because you have verbose mode on. Go to File | Preferences and find 'Show verbose during:'. Now have a look at the compilation and upload options. Unless you need them on for debugging, these can be turned off. The output will then be much shorter:

Code: [Select]

Sketch uses 320212 bytes (64%) of program storage space. Maximum is 499696 bytes.
Global variables use 51956 bytes (63%) of dynamic memory, leaving 29964 bytes for local variables. Maximum is 81920 bytes.
esptool.py v2.6
2.6
esptool.py v2.6
Serial port /dev/ttyUSB2
Connecting....
Chip is ESP8266EX
Features: WiFi
MAC: cc:50:e3:55:db:52
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 4MB
Flash params set to 0x0340
Compressed 324368 bytes to 225898...

Writing at 0x00000000... (7 %)
Writing at 0x00004000... (14 %)
Writing at 0x00008000... (21 %)
Writing at 0x0000c000... (28 %)
Writing at 0x00010000... (35 %)
Writing at 0x00014000... (42 %)
Writing at 0x00018000... (50 %)
Writing at 0x0001c000... (57 %)
Writing at 0x00020000... (64 %)
Writing at 0x00024000... (71 %)
Writing at 0x00028000... (78 %)
Writing at 0x0002c000... (85 %)
Writing at 0x00030000... (92 %)
Writing at 0x00034000... (100 %)
Wrote 324368 bytes (225898 compressed) at 0x00000000 in 19.9 seconds (effective 130.2 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...
You can, of course, turn them on as and when needed.

Regarding the functionality of the WiFi module, I am perplexed, but I will investigate. Might I ask what browser and version thereof you are using please and whether this is on Windows, Mac, iOS, Linux or Android? Also can I confirm that you do have JavaScript (not Java) enabled in the browser?

[tom_iphi]

Regarding the hex data in the output, this will be because you have verbose mode on.

Ah, yes, thanks for the hint! I remember having switched it on a while back when debugging a program.

Might I ask what browser and version thereof you are using please and whether this is on Windows, Mac, iOS, Linux or Android? Also can I confirm that you do have JavaScript (not Java) enabled in the browser?

I'm working on a Windows 10 Professional x64 system. My browser is Firefox 72.0.2 (64-Bit), but changing as I have activated auto-update, so always the latest version. And yes, javascript.enabled is set to true in my FireFox. I'd have assumed so as the AR488 tab does react properly.
I do have Microsoft Edge installed, too, but I usually don't use it.

I also have a virtual Ubuntu running if you think this may make any difference.

P.S. I have just tested on Microsoft Edge. Exactly the same behavior as on FireFox.

[WaveyDipole]

Thanks for taking the trouble to provide the requested information. I thought that JavaScript was probably working as you would probably have had more difficulties than were reported, but just wanted to be sure. I will hopefully get some testing done over the next few days. In the meantime, I have discovered that esptool.py version 2.7, 2.8, as well as 3.0 downloaded from their GIT work fine when called manually from the command line. It is first necessary to export the compiled binary (Sketch | Export Compiled Binary in the IDE), place the exported file in the same directory as esptool.py and then on my Linux machine I just needed to do:

Code: [Select]

./esptool.py --port /dev/ttyUSB2 write_flash 0x000000 mybinary.bin

On a Windows machine you would probably need to do something like:

Code: [Select]

python esptool.py --port /dev/ttyUSB2 write_flash 0x000000 mybinary.bin

I'm not sure why it fails when run inside the Arduino IDE, but I have raised the question on the Arduino forum.

If you decide to try this on Ubuntu, then disable the modemmananger service. It may have been enabled by default and probes serial ports for the presence of a serial modem. Unfortunately, it also interferes with uploads, causing them to fail. In the rare event these days that someone may have a serial modem connected to a serial port on their PC then it might be useful, but otherwise this service is unlikely to be needed and can be safely disabled.

[WaveyDipole]

I have uploaded version 0.48.08 which now includes updated support for auto-configuration of the Bluetooth HC05 module as well as tom_lphi's suggested amendment to the 32u4 configuration section in AR488_Config.h. Thanks tom.

[WaveyDipole]

I have just run a test with AR488-wifi, so far without GPIB adapter.
I could flash the code but I did get a strange error message after flashing was complete:

Tom, the folks at the ESP8266 GitHub suggested to delete (or rename) the arduino15 directory and install the ESP8266 library from scratch.

On Windows this will be in User -> AppData\Local\Arduino15

On Linux is was in ~/.arduino15

After this, IDE preferences are lost, the AVR libraries will need updating and the ESP8266 library can be re-installed from scratch. Not ideal and the re-install will take a few minutes, but after I did that on my computer, the upload completed without any errors.

UPDATE: a further test showed that is sufficient to delete /.arduino15/packages/esp8266. At least that way, you don't loose preferences and your other boards.

[tom_iphi]

I have uploaded version 0.48.08 which now includes updated support for auto-configuration of the Bluetooth HC05 module

Many thanks! I may find some time tomorrow afternoon to test (if I find aHC-05 in my junk box).
Btw, do I find current connection info for the HC-05 to the Leonardo in the package Bluetooth document?

UPDATE: a further test showed that is sufficient to delete /.arduino15/packages/esp8266.

I have just done this and reinstalled ESP8266 2.6.3 package from scratch.
I still get the same error message at the end of the upload process:

esptool.FatalError: Timed out waiting for packet header

[tom_iphi]

I have uploaded version 0.48.08

I have tested the new version and normal operation modes work well with my Leonardo, both CDC and hardware serial.
As I have no HC-05 (on order, will probably arrive by end of coming week), I have hooked up a USB to serial converter.
In BT mode, I can see that your are firing out AT commands. The HC-06 doesn't understand these as it doesn't like CR+LF terminators.

Btw, where should I connect the BT control pin to my Leonardo? As far as I can see, all port lines are occupied by GPIB. There are only two free board pins, which are RST and RAW. I assume RST goes to the reset pin. Can this be reconfigured as port line / GPIO? What is the RAW pin?

Best regards.

[artag]

I don't see any gain in using a Leonardo for a bluetooth version (except, of course, it might be what you have to hand). The advantage of the Leonardo is that you have native USB, so to ignore that and connect serially to a bluetooth device seems a waste.

RAW is unregulated input (6-10V in) and can't be a digital pin. Reset doesn't appear to be configurable on the 32u4. The only spare pins seem to be those driving the RX and TX Leds and you'd have to wire them out yourself and modify the arduino library to make those available as outputs, though merely setting them to input mode (and wiring) can make them available as inputs.

If you want a bluetooth GPIB adapter, I'd think an ESP32 or https://www.amazon.co.uk/Keywish-Bluetooth-ATmega328P-Micro-Controller-Compatible/dp/B07QPFDDPY/ref=sr_1_1?keywords=Keywish&qid=1580657669&s=computers&search-type=ss&sr=1-1 would be good.

[tom_iphi]

Thanks for the info on Leonardo pins.

I don't see any gain in using a Leonardo for a bluetooth version

Well, ultimately I want wifi and not Bluetooth. I just wanted to test the new firmware.
But anyway, there is a big advantage of using a Leonardo and hooking up a Bluetooth or wifi module to the hardware UART.
You can reconfigure it any time to work via native USB without having to change the hardware. You just throw a software switch and reflash via USB.

Taking this further: It shouldn't be too hard to make the firmware work simultaneously with both interfaces, i.e. accepting incoming messages from both channels CDC USB and hardware UART and sending outgoing messages to both simultaneously. In this case, reconfiguration would be unnecessary altogether.

But cool, an Arduino with integrated Bluetooth. I haven't seen that before.

Btw, another thing:
I found this extremely nice design on the web:
https://sigrok.org/wiki/File:Ar488-artag-pcb-top.png
Do you happen to be the designer? If so, would you share the design files?

Best regards.

[artag]

There's a link further back in the thread - https://eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/msg2728010/#msg2728010

Some related PCBs here :

https://oshpark.com/profiles/artag

(the v3 board does the same thing but the cable exits in the other direction. However I haven't had these made yet so they're not completely guaranteed to work).

You can download gerbers from the oshpark link and have them made somewhere else if you want, but if you want to modify it just ask me for the kicad sources.
 

[WaveyDipole]

Btw, do I find current connection info for the HC-05 to the Leonardo in the package Bluetooth document?

Btw, where should I connect the BT control pin to my Leonardo? As far as I can see, all port lines are occupied by GPIB. There are only two free board pins, which are RST and RAW. I assume RST goes to the reset pin. Can this be reconfigured as port line / GPIO? What is the RAW pin?

Best regards.

I haven't worked with the Leonardo yet and don't have one of those to hand, so there is no info in the supplement yet, but from what I can see looking at the image of a Leonardo board, it has a layout that is very similar to the Uno and has the same pin numbering. The Uno layout has two pins spare (6 and 13) and I used pin 6 in my tests early on. The more recent tests were done on the Mega 2560. I am curious which layout you used for the Leonardo? The Micro Pro has rather different pin numbering so some modifications would be necessary to allow the current Micro Pro 32u4 layout to work on the Leonardo. I would be happy to add a Leonardo layout that matches the Uno one to the sketch but would need to study the datasheet in more detail. Would you be willing to test it?

UPDATE: a further test showed that is sufficient to delete /.arduino15/packages/esp8266.

I have just done this and reinstalled ESP8266 2.6.3 package from scratch.
I still get the same error message at the end of the upload process:

esptool.FatalError: Timed out waiting for packet header

Curious that this is still happening. The issue I logged with the ESP8266 library developers is here:

https://github.com/esp8266/Arduino/issues/7050

Perhaps you could add your comments and output containing the errors to that issue or log a new one yourself? Since I am using a NodeMCU development breakout board, whereas you seem to be working with a generic ESP8266 module the cause may be related, or it may be different. They should be able to help with resolving this.

I don't see any gain in using a Leonardo for a bluetooth version

Well, ultimately I want wifi and not Bluetooth. I just wanted to test the new firmware.

Agreed WiFi is likely to be more useful. Bluetooth wasn't that difficult to work with so it didn't take too long to add something back in the 0.46.xx versions. The change in Architecture in 0.47.xx meant that I had to temporarily remove it, but now it has been adapted and tested, I have added it back in for what its worth. I appreciate that not everyone wants wireless signals around their instruments so it has been included in a way that is optional and disabled by default so can be just ignored if not required.

WiFi is much more complex and I have been working on that for some time. The fundamentals are there but it clearly needs more work and testing which I intend to crack on with now that I have got other outstanding bits out of the way.

Taking this further: It shouldn't be too hard to make the firmware work simultaneously with both interfaces, i.e. accepting incoming messages from both channels CDC USB and hardware UART and sending outgoing messages to both simultaneously. In this case, reconfiguration would be unnecessary altogether.

Yes it can be done and I have put together some code that can do that for hardware ports but not got as far as including CDC or SoftwareSerial ports yet. I wasn't sure how much value this would be to this project, although I had thought that such a capability might  be useful for diagnostics.

[tom_iphi]

@artag

but if you want to modify it just ask me for the kicad sources

Yes, please. I want to add a second PCB stack for a wifi chip and I would like to avoid re-inventing board outlines and the connector footprints.
I'm glad you are using KiCAD, too. KiCAD files of ar488promicro would be highly appreciated. Thank you very much!

@WaveyDipole

The Uno layout has two pins spare (6 and 13) and I used pin 6 in my tests early on.

Indeed, the Uno has spare ports. The Leonardo Pro Micro has exactly 16 port lines (+2 serial hardware lines), so the HC-05 will not work on the Pro Micro as no spare line for the control pin.

The Micro Pro has rather different pin numbering so some modifications would be necessary to allow the current Micro Pro 32u4 layout to work on the Leonardo.

This may be a misunderstanding. For me, the Pro Micro and the Leonardo are the same board. I only have an At32U4 Pro Micro board here which is detected as Leonardo by the Arduino IDE. So, I assumed this is synonymous.
I do also have an Uno board, so I may still test the HC-05. But I haven't currently wired it up to a GPIB connector.

    Taking this further: It shouldn't be too hard to make the firmware work simultaneously with both interfaces, i.e. accepting incoming messages from both channels CDC USB and hardware UART and sending outgoing messages to both simultaneously. In this case, reconfiguration would be unnecessary altogether.


Yes it can be done and I have put together some code that can do that for hardware ports but not got as far as including CDC or SoftwareSerial ports yet. I wasn't sure how much value this would be to this project, although I had thought that such a capability might  be useful for diagnostics.

I think this is not only usefull for diagnostics, but also for the final combined wifi+USB product, taken that the data throughput will not suffer too much. But maybe I'm a special case.

I will look again into the ESP upload issue and try to file my finds.

Best regards.

[WaveyDipole]

@WaveyDipole

The Uno layout has two pins spare (6 and 13) and I used pin 6 in my tests early on.

Indeed, the Uno has spare ports. The Leonardo Pro Micro has exactly 16 port lines (+2 serial hardware lines), so the HC-05 will not work on the Pro Micro as no spare line for the control pin.

The Micro Pro has rather different pin numbering so some modifications would be necessary to allow the current Micro Pro 32u4 layout to work on the Leonardo.

This may be a misunderstanding. For me, the Pro Micro and the Leonardo are the same board. I only have an At32U4 Pro Micro board here which is detected as Leonardo by the Arduino IDE. So, I assumed this is synonymous.
I do also have an Uno board, so I may still test the HC-05. But I haven't currently wired it up to a GPIB connector.

Sorry, yes I think there does seem to be some confusion over terminology. I assumed the term Leonardo to apply to the larger Uno-like board. However, doing a bit of Googling, I see that the term is applied by some outlets and sources to the Pro Micro. Nevertheless, thanks for the clarification. Indeed the small form factor Micro Pro board does not have any spare pins so the Bluetooth module would need to be configured manually or have some push switch or something to apply 3.3v to the enable pin on the HC05 for 60 seconds or so until the LED blinks once then 3 times. Then it is configured and theoretically only needs to be done once or if it looses its config. probably just as easy to configure it manually.

BTW, made spent a few hours and made some progress on the WiFi code yesterday. My apologies, but it looks like two of the Apply buttons were not working, i.e those General Settings and WiFi, so the settings were not getting applied. There were other things to tidy up as well. I still have one functional thing to sort and then I will post it again.

[WaveyDipole]

tom_iphi, I think I have sorted the remaining functional issue. Still plenty of work to do on it but hopefully this version will work OK.

EDIT:
Attachment removed. Latest version here:
https://github.com/Twilight-Logic/AR488/tree/master/src/AR488-ESP8266-addon

[tom_iphi]

Many thanks for the wifi firmware update!
I could only do a quick test.
GPIB pass through works nicely, now.

I still cannot switch it to client mode. If I do, the AP mode is switched off but reactivated quickly again.
And I'm also having an issue of frequent disconnects, when the ESP module is hooked to the AR488. But this may be rather an issue of my hardware that with the firmware.
In the programming adapter I obtain stable AP connection.

Btw, I'm using this combo of ESP-01 and USB-to-serial programming adapter:
https://www.amazon.de/AZDelivery-ESP8266-ESP-01-USB-Adapter-Arduino/dp/B078J7LDLY

Best regard.

[WaveyDipole]

GPIB pass through works nicely, now.

Good to hear that.

I still cannot switch it to client mode. If I do, the AP mode is switched off but reactivated quickly again.
And I'm also having an issue of frequent disconnects, when the ESP module is hooked to the AR488.

Could I ask whether it actually connects to your WiFi network with a live IP address?

The sketch is designed to fall back to AP mode in the event that it cannot connect successfully to a WiFi network as a client. This is so that it leaves the ESP8266 in an accessible state although it does take a couple of minutes to get there as the WiFi stack has to go through two restarts. If it connects successfully, then it should be possible to reach the status page via its new IP address and the connection should be stable. I tested with mine connected to the house WiFi for over an hour today and could still access it.

Currently, each time that the ESP8266 module is power cycled or reset it will revert to the default default AP mode SSID and IP address. This is because at present, nothing is being saved to EEPROM yet. Sorting that is next on my list.

I also discovered that there have been reports of this happening because the module is going to sleep to save power although I'm not sure how long it takes to kick in. I have found a means of disabling it which I have done in the attached.

Finally, if its crashing for some reason or something is causing a reset then it will revert to default settings.

You can enable debugging in the Arduino IDE. In tools under the ESP8266 board options set the debug port and debug level. You then have to recompile and upload. After that, in serial monitor it will show some event numbers which might provide a clue (or not). I have found the meaning of the WiFi ones here:

https://github.com/esp8266/Arduino/blob/master/libraries/ESP8266WiFi/src/ESP8266WiFiType.h#L51

I will have to have a search for the others. You may have to disconnect from the Arduino for this.

Btw, I'm using this combo of ESP-01 and USB-to-serial programming adapter:
https://www.amazon.de/AZDelivery-ESP8266-ESP-01-USB-Adapter-Arduino/dp/B078J7LDLY

Not used one of those but see no reason why an ESP-01 shouldn't work.

EDIT:
Attachment removed. Latest version here:
https://github.com/Twilight-Logic/AR488/tree/master/src/AR488-ESP8266-addon

[tom_iphi]

Hi, I have just tried your new firmware version with the debug switches on.
Funny thing: As soon as I activated the debug switches, the upload errors disappeared.
But I'm afraid still no connection to my home AP.
Also, I fear I cannot read anything from the debug log.
I attach it in hope that you may learn something from this.

Btw, my password is quite long. In fact it is longer than the input field. Is there a limit on the length of the password?
I assume, WPA2 should be no problem as the simple bridge code I initially used, did connect to my home AP.

And just to be sure I do not make a stupid mistake:
I switch wifi mode to client.
I activate DHCP for automatic IP address assignment.
I enter the SSID of my home AP into the ESSID field.
I enter the password of my home IP into the Password field.
I hit the Apply button.
That's where the log starts.
The log ends, when the ESP falls back to AP mode.

Best regards.