Suitable for automated benchmark execution?

[spth]

Hello, I am looking for an SBC that can be easily programmed from a host system and interface with that host system via a serial connection. This should not require any mechanic interaction (i.e. no plugging / unplugging / EPROM insertion, etc).

Basically, I want to use it as one can use modern development boards for microcontrollers.

Will this work with the Z80-MBC2? If yes, is where can I find the relevant documentation?

Background: The SDCC compiler has various backends. To track code size and performance regressions, benchmarks are compiled with new SDCC revisions and executed on STM8 and MCS-51 boards (resulting in the graphs at https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc-extra/historygraphs/).

However, currently no z80-related port is tested that way (despite Z80/GameBoy/Z180 retrocomputing being an important use case for SDCC). So I'm looking for a well-documented SBC that uses a Z80 or related to close that gap.

[spth]

When you call minicom from the bash script the Z80-MBC2 board is automatically reset by the DTR signal. Then the minicom script waits a while just letting the Z80-MBC2 to complete the boot into iLoad, and after the hex file is transmitted.

Doesn't work for me. I don't see the Z80-MBC2 reset when minicom starts. But I can reset it manually using Ctrl-A H from within minicom. Maybe you have a minicom configuration file that does the reset for you? If yes, could you show it?

[SuperFabius]

I haven't any custom conf file for minicom. I've just checked that minicom resets the board when you start it (with the DTR line). Instead if I do a Ctrl-A H nothing happens. Are you really sure to use the right signal (DTR) from the USB-serial adapter?

[SuperFabius]

I've read this from the minicom manual:

So check if you have a non zero value inside minicom for this parameter:

[SuperFabius]

Anyway it works also if set to 0...

[spth]

I haven't any custom conf file for minicom. I've just checked that minicom resets the board when you start it (with the DTR line). Instead if I do a Ctrl-A H nothing happens. Are you really sure to use the right signal (DTR) from the USB-serial adapter?

Looks good to me: I use a C232HD cable, gray wire connected to the pin marked "DTR" on the board, according to the cable manual, gray is DTR.

[SuperFabius]

Just re-checked now with a FTDI adapter using a FT232RL (while yours cable uses a FT232HL):

DTR works as expected (goes LOW when minicom is executed).

This behavior should be with any IC and any terminal emulation SW (e.g. Tera Term under Windows works the same).

I've no idea about your strange behavior... Try to find with a DVM if there is a signal that goes low when minicom is executed (or get a different adapter on ebay...).

PS: I've also used CP2102 and CH340G USB-serial adapter ICs with the same behavior on linux and win.

[SuperFabius]

I usually use a CP2102 based adapter (on both linux and win):

You can find it at about 2$ on ebay.

[spth]

I think my hardware is fine, I'm just fighting with minicom. After all it works with gtkterm (which doesn't have scripts though). I think I figured out the DTR issue: When killing minicom, the serial port was in an unuseable state, so the dtr worked when starting minicom for the first time, but not on subsequent starts of minicom. Now that I know about the issue I can work around it while trying to get a bit further.

So I now do get the reset on minicom start. Next I want to find out how to send the hex file using minicom. For now, I'm trying with a 526 B "Hello, world!" program hex file, which work fine for me when using gtkterm. 1) Manual attempt: I start minicom using "minicom -w -D /dev/ttyUSB1". When the message from the "Intel-Hex Loader", "Waiting input stream..." appears, I press Ctrl+A S, select "ascii" in the menu, select the file in the next menu, press Enter. I get a Window "ascii upload - Press CTRL-C to quit" that displays "0.0 Kbytes transferred at 19 CPS" and no further output on the screen. 2) Script attempt. I start minicom using "minicom -w -S minicom.txt -D /dev/ttyUSB1". In minicom, I don't see the any message from the "Intel-Hex Loader", but I do see "ASCII upload of "out.hex" Line delay: 100 ms, character delay 0 ms" and after a while I get a message about a timeout. minicom won't react to anything, so I have to kill it.

[SuperFabius]

Strange you have all these problems with minicom. If I try to kill minicom closing the CLI window where it runs and than re-open a new one, it works fine. I'm using minicom 2.7.1. on a linux mint 20.2 (Cinnamon 64 bit) system.