some trouble with a 74LS245 octal bus tranceiver...

Status
Not open for further replies.

snowsh

Well-known member
OK, start at the start....

I have a mixing console that was built in the 80s and uses a z80 to control switching of audio routing, leds and detect button presses.

The console consists of 7 motherboards, each board supports 8 channels. Each channel has 4 CS lines...

I have successfully reversed engineered the data architecture and now have control of this console using for now an arduino Mega 2560 rev3 (i had one here , its 5v pins, lots of pins.)

I will eventually use a teensy, most likely with shift registers to control the 24 5v address/data/control lines.

for now though I have a problem that has been baffling me for a week already. Last night I may have found some clues as to my issue....

Each motherboard, on the data, address, control lines has 3* 74LS245 octal bus tranceivers to buffer the bus to each motherboard. The data bus is different to the address and control bus lines in that it can operate bi-directionally and its dir pin is connected to the RD line. All of this is in place, has been since the 80s and just works fine - with the clunky z80.

The data bus then leads to 3X PIA chip PD71055 Parallel Interface Unit. these give 3X 8bit ports. by default on reset these are set to input so this is why I can read buttons. The setup routine sets some ports to output to enable data to be sent to them. The PIA acts as a latch and holds the values sent to it which then control a whole bunc of 4053s digital switches.

Using the Mega connected directly to the motherboard via a ribbon connector and jumper wires, I can read button events fine. It seems reading from this LS245 is fine. I should note at this point the "Channel" side of the LS245 (b side) all lines are pulled high via a 22k resistor package. Pressing any of the "digital" momentary switches grounds the line and the Mega reads the new value and calculates the button press event. This is all good and works well. Very well. In fact, with my current delay() routines when manipulating the console, 7 motherboards * channels * 16-20 switches are all scanned and read in about 100 milliseconds. Im very happy with that.

The problem I have is when I need to reverse the direction of the LS245 to write data to the bus. When I scope voltage on the Mega side (a) of the LS245 I see the expected +5v or 0v depending on the bit set. However when I scope its corresponding pin on the b side (channel side), it is allways high.

I did allot of reading last night and am starting to buid a picture of what the problem might be. It seems the logic family might be important here. Of course I am changing from a z80 to currently a Mega, eventually a teensy - most likely a 4.1 becuase I want it to do many other things. In fact I may well stick with the mega to read and write to the console, and control that via the teensy.

One post I read last night which was slightly off the topic, but gave me some insight has suggested that the Arduino may not be able to pull the logic of the b side low because of the resistors pulling it high. It might not have enough "grunt"....

I dont want to have to modify the circuit or any components in the existing console.

Does anyone have any insight into this? Looking at the schematics for the Z80 board I am hoping to replace, it connects to the bus using a 74HTC245. I wonder if a simmilar approach for my replacement is a good solution. It will protect the new microcontroller and associated circuit from the rest of the console to a degree.

So the question ultimately is this:

Why wont a mega 2560 rev3 pull the b pins low on a 74LS245 ? :confused::confused:


Why do I want to do this? I want to be able to reprogram the console, add midi and a load of new features. I dont want to mess around with a 40 year old microcontroller or try to learn assembly!
 
Because of a bug?
DIR or OE not used?

We'll never know without code and schematic.

The OE is LOW, and the DIR pin is HIGH.

Schematic for the motherboard is here:

https://drive.google.com/file/d/1qv4...ew?usp=sharing

I am connecting at conn 4 top right. The LS245 in question is IC 6. pin one is the DIR pin and is switched using RD HIGH A-> B

datasheet for the LS245 https://www.futurlec.com/74LS/74LS245.shtml

I have a simple test function to put a pin high low every 2 seconds. It calls the functions that setup the connection to the motherboard. This all works fine. Everything is fine, except setting this ls245 direction to pass from a to b...

Code:
void testPin()
{
  writeBoardAddress(3);                                                               // set the motherbord enable
  uint8_t pin = D7;
  uint8_t PORT = 0;
  //setPiaPort(groupPortReadMap[PORT]);                                       // (uint8_t address)

  setRdHigh();
  
  setWrLow();
  
  digitalWrite(pin, HIGH);
  Serial.println(F("high"));
  delay(2000);
  
  digitalWrite(pin, LOW);
  Serial.println(F("low"));
  delay(2000);
}
Using this I can see the voltage change from 4.9 to 0 - somtimes its around 1v depending on if I have a channel strip plugged into the motherboard. The datasheet says 0.8v max for a low signal. Maybe this is an area I could investigate. Any tips on how to ensure a LOW on a digital out is actual 0v?


I'm after insight really into if there is a reason im missing why this LS family chip maybe cannot pull LOW from a 5v signal from a mega digital pin?
 
Last edited:
Using this I can see the voltage change from 4.9 to 0 - somtimes its around 1v depending on if I have a channel strip plugged into the motherboard. The datasheet says 0.8v max for a low signal. Maybe this is an area I could investigate. Any tips on how to ensure a LOW on a digital out is actual 0v?


I'm after insight really into if there is a reason im missing why this LS family chip maybe cannot pull LOW from a 5v signal from a mega digital pin?

I should make it clear: I can see the voltage change HIGH / LOW on the a side (a0 - a7) of the LS245 which is connected to the mega. The b side (b0-b7) is allways HIGH - dont forget the 22k pullup resistors on that side of the data bus.

links:

schematic

datasheet
 
Maybe I'm missing something but on your schematic DIR doesn't seem to be connected. The /OE on pin 19 is only connected to the resistors and some other ICs. You write that the resistors are pull ups but that would mean that /OE is high? Looks like either the schematic or your text is wrong. I suggest to quickly test the functionality of the 'LS245 on a breadboard to exclude unknowns.
 
Maybe I'm missing something but on your schematic DIR doesn't seem to be connected. The /OE on pin 19 is only connected to the resistors and some other ICs. You write that the resistors are pull ups but that would mean that /OE is high? Looks like either the schematic or your text is wrong. I suggest to quickly test the functionality of the 'LS245 on a breadboard to exclude unknowns.

yes there are some ommisions in the schematic. I have spent weeks noting the circuit and tracing lines. Pin one is connected to RD, and when the motherboard is selected, the OE pin (19) is pulled low via the signal from IC2 pin 19 IC2 is a comparater that sets the motherboard enable. I have the hardware and pins all down, its all good. This particular 74LS245 that manages the data bus is also connected to a resitor pack on the b side to pull all the data lines high. I think this is where the problem is.
 
This will then also pull the resistors on the B side low not high right?

I just double checked the board. The line showing pin 19 connected to the common of the resistor package is an error. It is only connected to pin 19 on IC2, 18 IC1 and IC5 19 The is the motherboard enable line.

The resistor package common is directly connected to 5v.
 
IC2 is used as a 4-bit address comparator I think - and is set by the (jumpers?) you've labelled CON. 2
Until that matches the 245 won't drive anything - is that what writeBoardAddress(3) is supposed to be doing?

Jumpers for 74LS chips should be to ground, not to 5V, and 10k pullups to +5V should be permanently on all the lines.
(Have you traced CON. 2 correctly?)

Directly connecting any 74LS chip input to +5V is risky, as the abs-max on an input is 5.5V (Its 7V abs-mac for power)
this means that although you can drive 74LS from 5V CMOS, its not advised.

If the chips are socketed perhaps you can replace them all with 74HCxx series versions which are happy at 5V and at 3.3V?
 
IC2 is used as a 4-bit address comparator I think - and is set by the (jumpers?) you've labelled CON. 2
Until that matches the 245 won't drive anything - is that what writeBoardAddress(3) is supposed to be doing?

Thats correct. I have removed motherboard id 3 for my bench testing. The jumpers set the address and IC2 is a comparater. writeBoardAddress() does exactly that and works fine.

Jumpers for 74LS chips should be to ground, not to 5V, and 10k pullups to +5V should be permanently on all the lines.
(Have you traced CON. 2 correctly?)

yes conn 2 is set correctly and jumpers set the pin HIGH. RP1 is a 10k resistor package. Common connected to GND
The console was built in 1988. It has worked well for over 30 years.
When the bus is in its default mode, which I have working fine - it scans through eachboard,chip select, port and reads the data bus for button press events, the buttons take the logic LOW of their relevant bit in the 8 bit bus. This allows me some scope for detecting combination presses for my future plans. To reverse this from default state HIGH to Low would mean re-engineering 64Xchannel strips and countless other boards. This is how it has been designed. I dont want to modify the circuits in any way.

Directly connecting any 74LS chip input to +5V is risky, as the abs-max on an input is 5.5V (Its 7V abs-mac for power)
this means that although you can drive 74LS from 5V CMOS, its not advised.

This is getting towards what I was reading last night. I have HC and HCT versions of the 245. They seem to behave the same. I have tried several chips to eliminate the possibility of a bad chip.

If the chips are socketed perhaps you can replace them all with 74HCxx series versions which are happy at 5V and at 3.3V?


Yes l. If I can understand more clearly what logic family is best suited to a Mega or a teensy, it will determine that change.
This is is good idea. Every IC is socketed.
I am wondering if I need to do somthing on the Mega side to make sure this logic sent to IC6 does its job
 
Last edited:
well I think I may have found a solution.

reading this thread using answer #4 from Fungus, this seems to allow me to pass data through this 74LS245

here is my modified function to put data on the bus to follow this advice...

Code:
void writeDataAddress(uint8_t value)
{
  setWrHigh();                                                          // make sure its high to begin

  setRdHigh();                                                          // make sure its high to begin
  
  if (dataBusRead)                                                      // check to see what mode the data bus is currently in read or write. false = write mode
  {
//    setDataBusWrite();                                                // set the pins - not needed now.

    dataBusRead = false;                                                // update our flag
  }

  setWrLow();

  pinMode(dataBus[0],((value & 0b00000001) ?  OUTPUT : INPUT));
  pinMode(dataBus[1],((value & 0b00000010) ?  OUTPUT : INPUT));
  pinMode(dataBus[2],((value & 0b00000100) ?  OUTPUT : INPUT));
  pinMode(dataBus[3],((value & 0b00001000) ?  OUTPUT : INPUT));
  pinMode(dataBus[4],((value & 0b00010000) ?  OUTPUT : INPUT));
  pinMode(dataBus[5],((value & 0b00100000) ?  OUTPUT : INPUT));
  pinMode(dataBus[6],((value & 0b01000000) ?  OUTPUT : INPUT));
  pinMode(dataBus[7],((value & 0b10000000) ?  OUTPUT : INPUT));
  


////  delay(0);                                                             // mode 0 timing SAW = 0ns.
//  digitalWrite(dataBus[0], ((value & 0x01) ? HIGH : LOW));
//  digitalWrite(dataBus[1], ((value & 0x02) ? HIGH : LOW));
//  digitalWrite(dataBus[2], ((value & 0x04) ? HIGH : LOW));
//  digitalWrite(dataBus[3], ((value & 0x08) ? HIGH : LOW));
//  digitalWrite(dataBus[4], ((value & 0x10) ? HIGH : LOW));
//  digitalWrite(dataBus[5], ((value & 0x20) ? HIGH : LOW));
//  digitalWrite(dataBus[6], ((value & 0x40) ? HIGH : LOW));
//  digitalWrite(dataBus[7], ((value & 0x80) ? HIGH : LOW));
  delay(1);                                                               // mode 0 timing WWL = 120ns.
  
  setWrHigh();                                                            // mode 0 timing SDW = 100ns
  
  //delay(1);                                                             // mode 0 timing HWA = 0ns.
  //delay(1);                                                             // mode 0 timing HWD = 0ns.
  
}

Going to see how this goes. I guess maybe this issue was because I am not using direct port manipulation. Maybe I should look into that. Advice and ideas most welcome!
 
This is an interesting project, I have a similar situation with a console from the early 90s that has something similar to this and I would be doing the same thing you are if I wasn't planning on completely rebuilding the whole console. My system does have partial MIDI support though, I say partial because you can't change settings in real time, it only allows you to change 1 of 16 templates/recalls with SysEx messages that you can then choose from in the center section and not every switch/led is controlled either.

My system has 2 "computers" using Z80s, one strictly parses MIDI data and passes it along to the 2nd one that then controls all the I/O on up to 15 daughter cards with 64 I/O each for the whole console. Each of the channels has 12 I/O so every card can control 5 1/3 channel strips and I believe I have 13 cards which is not nearly as much as you have to handle on yours since mine only has 8 address lines (7 are used), 8 data lines, and 2 cs lines (switch or led).

I wish you the best with your project.
 
This is an interesting project, I have a similar situation with a console from the early 90s that has something similar to this and I would be doing the same thing you are if I wasn't planning on completely rebuilding the whole console. My system does have partial MIDI support though, I say partial because you can't change settings in real time, it only allows you to change 1 of 16 templates/recalls with SysEx messages that you can then choose from in the center section and not every switch/led is controlled either.

My system has 2 "computers" using Z80s, one strictly parses MIDI data and passes it along to the 2nd one that then controls all the I/O on up to 15 daughter cards with 64 I/O each for the whole console. Each of the channels has 12 I/O so every card can control 5 1/3 channel strips and I believe I have 13 cards which is not nearly as much as you have to handle on yours since mine only has 8 address lines (7 are used), 8 data lines, and 2 cs lines (switch or led).

I wish you the best with your project.

What console do you have? Im working on a Soundtracs Eric, its quite a beast.
 
Not sure if you have it working or not, but you said Pin 1 of IC6 is connected to RD. You also say you have the Mega connected through Conn 4, RD is not available at Conn 4 rather it's BRD coming from IC3, could there be something there?
 
It genuinely sounds like your problem was just a case of the Arduino not getting told to properly switch the pins from being an Input to an Output that is pulling down. That has to be explicitly told before it does anything. For future reference as explicitly stated when you enter this sub-forum and at the top: "Always post complete source code". Most of the time it genuinely is just a goof in one's code that is causing the headaches and it are outside eyes that spot it.


Now on your question of Direct Port manipulation. It is a good way to get incredibly efficient code, BUT understand that every board and every chip is unique in regards of their GPIO Ports and will almost always necessitate having to figure out the exact pinout of the board and engage in some bitwise operation. The Arduino functions aren't fast, but they do ensure your code works on any arduino (compatible) board you might want to use. If that does not scare you it can be worthwhile to learn the ins/out of one's chip. If one is clever enough you can get your controller to switch an entire bus in one go and achieve speeds you might not have thought possible.

Would give a warning in advance for your plan to substitute the Mega by a Teensy. They are namely 3.3v devices, Not 5V like the Arduino mega.
-For the Teensy 3.2 / 3.5 this shouldn't be a problem as they are 5v-tolerant and the 74LS accepts 3.3v as a "HIGH".
-But the Teensy 4(.1) are NOT 5v Tolerant. They will risk damage without appropriate level-shifting.
 
thanks for the advice Foxhood. In reference to your query if the pin mode was set correctly, I was running a check within my write function to determine if it was in read mode. You will note the commented function call setDataBusWrite(). This and a partner function setDataBusRead() took care of setting the pin mode.

The issue seems to be resolved, but to me it feels odd. I was setting my pins to output, then setting HIGH or LOW using digitalWrite as I can for all the other IC 74LS245 that are not tied HIGH on the b side. The solution is to not even bother with a digitalWrite() rather set the pin modes to input or output depending on the data being sent to the bus. this gives a 0v LOW and ~1.5v HIGH. This is indeed enough to trigger IC6 logic, (of course its the true 0v LOW that is doing the trick) and set the b pins accordingly, however I am only running a few channels in my test bench. Either way its an approach new to me so happy to experiment and learn.

I will certainly look more at the direct port methods, although im not sure the 1980s chips will run as fast! for now this mega is doing the job. I will probably use it as the bus controller and tie a teensy to it to run commands - of course noting any voltage shiift requirements, but thats a way off yet. I now have to map out the addresses for the switches and program the PIA chips to target the relevant PORT in read or write mode.
 
Not sure if you have it working or not, but you said Pin 1 of IC6 is connected to RD. You also say you have the Mega connected through Conn 4, RD is not available at Conn 4 rather it's BRD coming from IC3, could there be something there?

yep its seems to be passing data through now. BRD is already taken are of. the motherboard select bits set all the trancievers to active and the chip select line decoder ICs1 and 5.

Nice console! How come a full rebuild?
 
I say rebuild, but it's more so a whole new custom design just using the chassis and taking inspiration from some of the circuits it already has. Most of the channels need fully rebuilt and new PCBs because the copper traces in some places have bubbled up so it's no longer in good completely working condition.

Rather than try and source original parts I've just decided to design my own with some new functionality and make it a little more modern while removing some parts that are basically unnecessary with what we need the console for in our studio.

Each channel strip is comprised of 3 layers of PCBs, the 1st layer handles all the logic from the computer, the 2nd has all the switches/knobs/leds soldered to it and is just an interconnect for the 3rd which is separate modules for each section of the strip. The Aux section and the Buses sections of the channel strip take up roughly 1/2 of the channel strip. We are connecting each strip as an insert in Pro Tools so all the routing and auxing will be handled there so there's no need for the redundancy of that on each strip and wasting real-estate that could be used for other things.

I haven't completely decided yet but I will be filling the extra space with as much functionality as I can so I plan on selecting a few different racks that we like the sound from and building them in to each strip. I'm also planning on shrinking the circuits as much as I can using SMD parts to fit even more in, I know some people don't like consoles with SMDs because it's harder to fix things, but I have no problems working with and fixing SMD components as it's not really as hard as some may think it is once you get the right tools. That being said I'm also not going to use the absolute smallest parts just so it is easier in the case I have to fix something with just a soldering iron.
 
Status
Not open for further replies.
Back
Top