As an aside, it may be worth mentioning that async starts to get more finicky the faster you go, that's why many high speed protocols use a synchronous method. You start to get 'bit jitter' due to noise and irregularities in the cable. As the speed increases, this bit jitter starts to become a significant part of the bit time - thus we get errors since our receiver has trouble recovering the data.

A method such as manchester encoding adds the clock to the data stream - this can be recovered at the receiving end. The bit jitter affects both the encoded data and clock so we can synchronise to the recovered clock and get the data. I can't recall the method CAN uses, USB uses bit stuffing. 100mbit & 1gbit ethernet use interesting methods of encoding the data that are worth a read for those interested.

I probably wouldn't use async past about 250k if I wanted to run a significant distance - note DMX512 does this succesfully - DMX512 was the reason for me going to 8051 many years ago!

It can be counter-productive putting many devices onto a RS485 bus (or any bus for that matter) because if a unit fails and kills the bus (75176s like doing this) how do you know what device has failed? Ten devices are easy to isolate, 40 becomes labourious, so rather than pile as many devices onto the one bus, split it up and use a rs485 hub (or design your master to have many drivers). If you put rx & tx leds on each bus, you'll be able to see which one has died quickly and from then isolate the defective slave. I also recommend putting rx & tx leds on the slaves - it helps debug problems quickly. The usual problem is the + & - signals swapped, the rx led stays full on in this instance.