Bridging Serial to another Micro

I'm using a 20mhz avr to act as a bridge between a windows host and an older microcomputer. The micro is interfaced with a couple of shift registers accessed by busout() and busin() routines.

The AVR can see the micro writing to one of two ports via a couple of pins on portd: 0x40 going low means the micro is writing something to the shift register and if 0x04 is high it means that that data is meant for the PC (otherwise the AVR just clocks the shift register out on the SPI bus).

I have made this work very reliably for output from the micro to windows but it involves the AVR sitting in a tight loop with interrupts disabled. It's a bit complicated because the data's not stable until the 0x40 bit goes high again so i have to grab the 0x04 bit in the interim and test it later.

I've been trying to send data back from windows to the micro but i can't make it reliable enough to be useful. My latest attempt involves the micro sending control characters: 0x00 means it wants to read from the host, 0x12 means it wants to know if host data is available. To avoid problems it can send 0x27 to escape the following character.

I've experimented with various interrupt schemes but i think i need a better idea. Sorry to make you look at my code, i'm including it for completeness;

  digitalWrite(CLRsw,HIGH); //take the micro out of reset
  state1802=running;
  cbi(TIMSK0,TOIE0);
    while(true){ //loop for 1802 program output
    noInterrupts();
    while (PIND&0x40); //wait for SPI signal to go low
    pindsave=PIND; //grab the n0 line while it's valid
    while (0==(PIND&0x40)); //wait for trailing edge - signal goes high again
    interrupts();
    if (pindsave&0x04){ //if it's for me  ** have to test this now
      char1802=busin(); //grab the character and clock the SPI bus
      if (escmode==1){//escaping this character
        cout<<_BYTE(char1802); //send it to the host
        escmode=0;
      }else{
        switch(char1802){
          case 0x12: //querying for avail characters
            busout(Serial.available());
            break;
          case 0: //wanting host characters
            busout(getch());
            break;
          case 0x27: //escape next character
            escmode=1;
            break;
          default:
            cout<<_BYTE(char1802); //send it to the host
        }
      }
   } else{ //not for me, have to do this fast
      justclock(); //just clock the SPI bus
    }
  }
}

olduino - an arduino for the first of us

bill2009:
I'm using a 20mhz avr to act as a bridge between a windows host and an older microcomputer. The micro is interfaced with a couple of shift registers accessed by busout() and busin() routines.

Sorry but I can't make any sense of your description and especially I can't relate it to your title.

If you want a serial link to another microprocessor why not use the Micro's Serial1 USART?

...R

Robin2:
Sorry but I can't make any sense of your description and especially I can't relate it to your title.

If you want a serial link to another microprocessor why not use the Micro's Serial1 USART?

...R

Sorry for the lack of clarity. The other micro doesn't have a UART it has parallel out to a parallel-in shift register and parallel in from a serial-in shift register both controlled by the AVR, The AVR can tell when the micro has written to the output shift register and can read and write both registers but otherwise there's no handshaking.

Maybe the simplest thing is to post a link to the datasheet for this other microprocessor.

Or if you are trying to interface with a piece of software running on that microprocessor then a link to its communication specification.

I understand now that you need some form of non-USART communication but I can't get my head around the system that can be used. For example when you say parallel, do you mean you need 8 connections between your Micro and the "other micro" in order to transmit a byte?

A diagram of the connections (NOT Fritzing) may help.

...R

The schematic is here but it's a bit complicated, there's a block diagram below. the 1802 data sheet is here but you can think of it as any old school micro like a 6502 or z80 etc.

The 1802 uses two shift registers as an SPI interface - a 74165 for output and a 74595 for input. The AVR serves to clock the shift registers on demand from the 1802 and to interface with the host over UART.

I think the key thing is the interface between the 1802 and the atmega. The OUT2 line does a negative pulse of about 1.5 uS when the 1802 writes to the 74165 shift register - the data is stable after the end of the pulse. During the low on OUT2, N0 will be high if the data is intended for the host.

So the AVR is spinning with interrupts disabled waiting for OUT2 to go low then high again. While it's low it samples the N0 line. If N0 was high, it clocks the data in and sends it out to the host over windows. If not, it just clocks the shift registers and some other SPI peripheral reads and writes it. This works great for output to the host and for reading/writing from other SPI peripherals at 4 mhz.

I have this limping along for small, slow transmissions (9600 baud, 32 bytes) but it's not reliable enough for xmodem. I keep thinking there's some software magic i could use but maybe i need some sort of semaphore flipflop so the AVR doesn't have to run with interrupts disabled and readable by the 1802 so it can tell when the AVR has dealt with the data. If this part is solid, the AVR can manage the rest by communicating in-band with the 1802. As an add-on I could have a data-available signal from the AVR to the 1802 to save it from constantly querying for availability.

Sorry if I seem dense but I am still struggling to understand the context of all this.

In your drawing which parts are the "old device" and which parts are you adding?

Back in the day when the "old device" was new how was it used? What was it connected to?

What does the "old device" do?

You say "The 1802 uses two shift registers as an SPI interface " which leads to the obvious question, why not use SPI to communicate with the 1802?

Maybe it would be quicker just to build an Arduino / Atmega based device to replace the "old device" ?

...R