Designing a UART register file.

[paulca]

On one side I have a 68000 - ultimately, but for today I have a digital discovery pattern gen.

On the other side I have an STM32F411.

The plan is to use the STM32 to present a UART or two as a standard memory mapped register file.

I have met a few real ones in my time, so I picked the "bare minima" to start from.

0x0 CONFIG - TxEnable | RxEnable | Dont care
0x1 STATUS - TxReady | RxReady | Dont care
0x2 TX
0x3 RX
Channel B is 4-7.

3 bits (of 7) of the reg select consumed.  7 because 68k, from its point of view they are 0, 2, 4, 6.....

The idea is that the MCU firmware will proxy these to real configured UARTs.

V2 then would probably add FIFO awareness?  Maybe baud select?

0x0 CONFIG - TxEnable | RxEnable | BAUD_DIV[0..3] | Dont care
0x1 STATUS - TxReady | RxReady | TxFifoFull | RxFifoEmpty | Dont care

Interrupt control... I have not considered that and it's why posts like this exist.

V1 can be interrupt less.
V2 at least needs an Tx/Rx Ready interrupt.

There are only 2 bits left in Config.  So they all gone now with RxInt, TxInt.
If I wanted to add "Half Fifo Interrupts" from the STM32 I would need more bits.

It matters when you define the addresses for the UART above... so maybe I block out later options at the cost of some bits?

UART Channel A:
0x0 -> 0x3 used
0x4 -> 0x8 reserved.
Uart channel B:
0x09 -> 0x0C used
0x0C -> 0x0F reserved.


What else am I missing that will hurt later?

[Doctorandus_P]

Maybe you can do something with satoshinm
It's a project on gitlab that makes 3 uarts on an USB port with an stm32f103.

[bobxyz]

Error status (parity, framing, overrun)?  Or will that be handled externally?

[free_electron]

you said 68000 . That's a 16 bit databus. If you don't want to use the byte select signals you may want to work on boundaries. some 68K have an A0 , some do not... so that's the first thing you need to settle.

use the LSB of the address bus to toggle between Readable and writeable registers.

0 : TX (writeable)
1 : RX (readable)
2 : Config (writeable)
3 : intstatus (readable)

and so on.

[paulca]

you said 68000 . That's a 16 bit databus. If you don't want to use the byte select signals you may want to work on boundaries. some 68K have an A0 , some do not... so that's the first thing you need to settle.

use the LSB of the address bus to toggle between Readable and writeable registers.

0 : TX (writeable)
1 : RX (readable)
2 : Config (writeable)
3 : intstatus (readable)

and so on.

Nice tip on the LSB address line.  I like it.

That would be A1 on the CPU side.  There is no A0 on my model.  The gating will be "F" in top 4 address lines = IO region. (74H*138 with bit 23 and _AS as enables)  That region select is then gated with LDS.  If you don't assert LDS you get nought.  If you do whether you ask for byte, word of long, you are getting the lower 8 and like it.  It does create a mental extra step to model as the ASM code sees the registers number even, 0, 2, 4, 6, but the MCU sees the them as 1, 2, 3 (or 0,1,2).

I did consider multiplexing read and write registers.  Write to RxTx and it's Tx, read from it and it's Rx.  But I figured that would just add work down the line and I am not short of address bus.

On the MCU side, just to have some fun.. A1-A7 map to RegSel0->6.

The end game circuit gives the MCU the full 256/128 actual register addresses.  For it to be a IO cameleon.

Didn't get to set up the LA and Pattern Gen.  Instead I did the DTACK flip flop so it releases on AS deassert which the MCU isn't fast enough to do. (Well maybe, but why bother playing ISR golf when you can use a flip flop).  Then I spend an hour looking for inverters the bot told me where 74HC06's.  Which sounded so familar and obvious I actually looked and didn't check.  Maybe tomorrow night.

Oh... this signal timing test is heavily reduced as the Digital Discovery only has 16 DIO output channels.

[Renate]

I'm so confused. How is the STM32F411 supposed to be doing this? With bit-banged memory interface?
The 411 doesn't have the FMC (Flexible Memory Controller).
Maybe even use some dual port RAM?

Why wouldn't you make the registers (somewhat) compatible with the MC68681 DUART?
Which also begs the question, why not actually use one?

[free_electron]

Why wouldn't you make the registers (somewhat) compatible with the MC68681 DUART?
Which also begs the question, why not actually use one?

He probably wants to do CDC over USB to a parallel uart. the 68000 doesn't have a uart, so doing parallel databus to uart to usb is kind of unwanted conversions (and bottlenecks).

I would slap on a FT245 or any other FTDI chip that can do the 245 mode (there's plenty). FIFO's, buffer fill flags .. it's all there. 8 bit interface. and it can go full throttle. the FIFO's are pretty deep too. you could even write the printf handler to do a kind of DMA.

https://www.futurlec.com/Datasheet/USBMOD245.pdf
i beleive the orignal ft245 in tqfp is obsolete but the FT240 can do it and is very cheap (2.5$). comes wirth all kinds of drivers. i wouldn;t bother with a processor that needs firmware , that needs debugging , and comes with operating system quircks. FTDI : plug and play. works

[paulca]

I have an MC68181 Dual UART from the CPU's family.

However, the purpose of the MCU is not "just" UART.  The real thing is big enough with enough pins to take the full CPU bus.  It can and will also hold "RESET and HALT" controls.  ie.  "Supervisor".

In that position, it should be cable (circuits still pending), be able to overrule the rest of the board and "Hold DTACK" so it can sample the address and datalines to memory.  This allows me to "STOP" and "Dump the last N bus transactions to UART (or an LCD)"

Beyond that, the MCU can also present a register file for 2 UARTs... at least one SPI and at least one I2C.  Possibly even an SDCard "disk abstraction".

I have already stopped myself adding MORE mcus to the board.  For example.  I wanted to add a "tri-color POST LED", still do want to add it, but I was actually tempted to drop an STM32F030 to handle it.  Rather than a bunch of 74 series gates.  The challenge is actually the F030 doesn't have the speed to sync a status word off the bus and signal DTACK, not without at least it's full address decode done in hardware.  Which is a bunch of gates.

At the same time i do not want to over do the existing MCU and make it a lot of complicated hanging all and sundry features off it.  This is a simple, one off build, so costing having 2 or 3 MCUs and an FPGA and resulting in a board that cost as much as an Amiga 500+ fully built.. is fine.  (and no.  It will not be Amiga compatible).