Using a PICAXE as a UART for a simple computer?

I

Iain_C

Member
Hi all,

I'm having a lot of fun with a homebrew TTL CPU. However, I'm not having fun using a UART to give it serial comms. My homebrew architecture is extremely simple and although I'm comfortable with driving UARTS having built a Z80 machine, the usual suspects (8250, 16550, SCC2691) are out in this case because of interfacing and config difficulties in the face of the fact that my architecture doesn't include such niceties as a way to do a bit test :)

I'm wondering therefore if a PICAXE would be fast enough to act as a very simple, non-configurable UART for the machine. I would have 8 bidirectional PICAXE pins connected to my data bus, and 2 PICAXE pins for the serial IO. An additional pair of PICAXE inputs, A and B, would allow the computer to tell the PICAXE what to do.

The PICAXE would need to monitor the serial port in order to buffer a single incoming character, as well as monitor these two inputs. If input A goes low the PICAXE should grab a byte from the bus and send it out over serial. It input B goes low, it should place any received character on the homebrew machine's bus, or place a zero on the bus if no character was currently buffered.

- I don't need any flow control on the serial side
- The clock speed of the homebrew computer will be 1MHz
- Hardward 8-N-1 at 9600 would do just fine
- I can live with only a single character of buffered serial input

Given these constraints, could a PICAXE keep up with this task? And if the answer is no, could a PIC?
 
I

Iain_C

Member
nick12ab said:
Will the data bus also be expected to work at this speed? The PICAXE won't be able to respond to multiple bytes in a row at this speed.
Click to expand...
Hi Nick,

Good point... the data bus will run at this speed but no more than 1 in every n messages would be for the PICAXE.

I think subsequent bytes is a different problem really; I could either implement a "ready for another byte?" query to the PICAXE, or ensure I don't send bytes to it too frequently.

The main question is, will it able to respond to the "grab a byte" signal and have time to actually grab the byte from the bus at this bus speed, and conversely to respond to the "dump your byte" signal and have time to place the byte onto the bus..
 
N

nick12ab

Senior Member
Iain_C said:
The main question is, will it able to respond to the "grab a byte" signal and have time to actually grab the byte from the bus at this bus speed?
Click to expand...
I doubt that PICAXE will be fast enough to get bytes from the data bus at 1MHz. If you want to use PICAXE, then you might need to use a FIFO buffer IC.

The "ready for another byte" idea sounds reasonable however the PICAXE may not be fast enough to respond to the request signal and pull-down or pull-up resistors will be required on the data bus to make sure that the master doesn't falsely read a ready signal.
 
I

Iain_C

Member
nick12ab said:
I doubt that PICAXE will be fast enough to get bytes from the data bus at 1MHz. If you want to use PICAXE, then you might need to use a FIFO buffer IC.
Click to expand...
- Hey, that's cunning! So I could have a pair of 74HC40105, memory mapped, on the data bus. A PICAXE could constantly poll this, and shift a byte out at a time and bung it down the serial port. That's the output sorted!

For feeding data from the PICAXE onto the databus a memory-mapped shift register might be the way to go... hmmmmmmm, you've got me thinking now :D
 
A

AllyCat

Senior Member
Iain_C said:
could a PIC?
Click to expand...
Hi Iain,

Very probably Yes! For simple bit/byte operations, the interpreted Basic in a PICaxe runs between 100x and 1,000x slower than PIC assembler (IMHO it's nearer to the latter figure). But you'd need a PIC Programmer and to be reasonably "comfortable" in working with PICs at a low level (and/or using the appropriate tools) in preference to the above "hardware-assisted" solution.

Cheers, Alan.
 
I

Iain_C

Member
Alan, thanks very much. I'll keep that as an option; I don't know PIC assembler but I love excuses to learn new architectures.

For now I've actually found (not my own work) a really elegant way to synthesise bitwise AND from arithmetic ops. In C it looks like this for signed 16-bit integers using two's complement (as my arch uses):

Code: 
int16_t BitwiseAND(int16_t a, int16_t b) {
	int16_t c = 0;
	for (int x = 0; x < 16; x++) {
		c += c;
		if (a < 0 && b < 0)
			c++;
		a += a;
		b += b;
	}
	return c;
}
Takes ~120 of my homebrew machine's instruction cycles, each of which are 7 clocks; but hey, my traditional UART will now speak to me :D
 
Last edited:
You must log in or register to reply here.
Top