Introduction

In the last post Using the serial port - part 1.5 - bitbanging I was trying to bitbang a clock to be used as the transmitter clock for the serial port built into the Alphatronic P2. However, the clock accuracy is not good - as expected from such an high level language like Java, where you are not able to exactly control the timings.

But there might still be a possibility…

New Idea

The new idea is: Why don’t we send continuously a specific byte that ends up in a repeating pattern of 1s and 0s? And that byte is actually 0x55. Together with the start bit and the stop bit, we can put out something, that is a normal clock with 50% duty cycle. And we don’t need to control the timings by ourselves, it will be done by the serial chip.

Assuming that the next byte is sent immediately after the stop bit, then there will be no gap between the sent bytes and the clock is really continuous:

             S 1 0 1 0 1 0 1 0 S S 1 ...
space "0"   ┌─┐ ┌─┐ ┌─┐ ┌─┐ ┌─┐ ┌─┐
            │ │ │ │ │ │ │ │ │ │ │ │
mark "1"  ──┘ └─┘ └─┘ └─┘ └─┘ └─┘ └─...

Serial sends LSB first. That means, the bits are: 0101 0101 -> 0x55.

With that, we get a accurate enough clock. Clock frequency is half the baudrate, as two bits together form one period of the clock. So we need to send at @2400 to get a 1200Hz clock.

Since baudrate needs to be double as the clock, so we probably need two USB serial adapters: one for clock generation and one for receiving at a different baudrate.

That means, no Arduino for bitbanging is needed with Max232 - which would also be basically an additional serial adapter - meaning two hardware thingies that we need to combine.

Java Program

I’m still using the library jSerialComm. But the program is now much simpler:

public class JavaSerialClock2 {
    public static void main(String[] args) throws InterruptedException {
        SerialPort commPort = SerialPort.getCommPort("/dev/ttyUSB0");
        System.out.println("commPort = " + commPort + " (" + commPort.getSystemPortPath() + ")");

        int baudrate = 2400;
        commPort.setBaudRate(baudrate);
        commPort.setParity(SerialPort.NO_PARITY);
        commPort.setNumDataBits(8);
        commPort.setNumStopBits(SerialPort.ONE_STOP_BIT);
        commPort.setFlowControl(SerialPort.FLOW_CONTROL_DISABLED);
        commPort.setComPortTimeouts(SerialPort.TIMEOUT_READ_BLOCKING, (int) TimeUnit.SECONDS.toMillis(30), 0);
        commPort.openPort();

        System.out.println("Starting clock with " + (baudrate / 2) + "Hz");
        byte[] buffer = new byte[20];
        Arrays.fill(buffer, (byte) 0x55);
        long start = System.currentTimeMillis();
        while (System.currentTimeMillis() - start < TimeUnit.SECONDS.toMillis(100)) {
            commPort.writeBytes(buffer, buffer.length);
        }
        System.out.println("Clock done");
    }
}

It’s sending repeatedly 20 bytes filled with 0x55 for 100 seconds.

A baudrate of 2400 generates a clock with 1200 Hz.

You can download the code from github: adangel/alphatronic-code.

Summary

This approach will generate a accurate enough clock to be used. Then the clock is not to blame, if the experiment still doesn’t work - meaning: the Alphatronic P2 still doesn’t send any data out of its serial port.

One interesting fact: I experimented a bit with the baudrate, and when I set it to 150 in order to generate a 75 Hz clock, I end up with 414Hz. So, it depends on the the USB Serial Adapter, which baudrates are actually supported. This explains, why the bitbanging was working better with 1200 Hz. It seems the lowest baudrate supported by this adapter is 200.

The actually clock speed shouldn’t matter much, so that the Alphatronic P2 can send the bits. It only matters, if I additionally want to receive it.

One more question: Can we use one adapter only? We would send our 0x55 bytes and at the same time, we would receive. The BASIC program can be changed, but the supported clock factors are only 1, 16 or 64. We would need a factor of 0.5: The clock is at 1200Hz, but the baudrate would need to be 2400. That’s not possible. So we really need two adapters: One for sending the clock signal and one for receiving any data.

But whether this works, needs to show a new experiment.