Well, I've managed to make parts of the bitlevel routines work, here's a PTI screenshot demonstrating. The leftmost calc is receiving, the middle one is monitoring, and the rightmost is sending.
Let's start with the calculator on the left, the receiver. The second line of dots indicates the data and clock line statuses. Fair enough; the clock line is blinking away (tip), while the data link is mostly steady (ring). The third row shows how far into the code it's getting before it fails: to the first recbyte call. The top row, with the pixel at right on, indicates that it's generating a force collision event.
Now, the right or sending calculator. The leftmost pixel on the top row means it's seeing the collision generated by the receiver and aborting transmission. The second row shows it seeing both clock and data as logical 0 (+5v) when it's in receive mode, as it should, since nothing's trying to send to it. The middlish pixel in the third and final row means it's actually reaching the sendbyte routine in the first place.
So, work continues on figuring out why the collision is occuring.
Let's start with the calculator on the left, the receiver. The second line of dots indicates the data and clock line statuses. Fair enough; the clock line is blinking away (tip), while the data link is mostly steady (ring). The third row shows how far into the code it's getting before it fails: to the first recbyte call. The top row, with the pixel at right on, indicates that it's generating a force collision event.
Now, the right or sending calculator. The leftmost pixel on the top row means it's seeing the collision generated by the receiver and aborting transmission. The second row shows it seeing both clock and data as logical 0 (+5v) when it's in receive mode, as it should, since nothing's trying to send to it. The middlish pixel in the third and final row means it's actually reaching the sendbyte routine in the first place.
So, work continues on figuring out why the collision is occuring.