The Sinclair QL Forum

Martin_Head wrote:But PEEK($18000) don't work, it just returns zero. PEEK_W and PEEK_L are OK. Also PEEK$ returns zeros. I tried PEEKing $18000 in Qemulator under QDOS, and that worked OK. So I don't know if its a SMSQ/E or a Q68 thing.

Sorry had not seen that at first. Only longword access is allowed (same as QL).

Slightly off topic. I spent more time than was really allowed (hello MrsD!) Debugging an interrupt driven I2C app on the Arduino for my next book. This is what I'm up against.

Data from a sensor comes as two bytes, msb first. If I put a "print" statement in my C function to read the two bytes, I get the correct results. If I comment out the "print", I get the two data bytes reversed! WTAF?

Wish me luck. Debugging interrupt handlers is a nightmare.

Please don't reply with suggestions, thanks, I don't wish to drag this topic off the real subject!


Cheers,
Norm.

Good luck! Since my new QL baseboard has an ATMega328P-PU onboard for matrix keyboard handling, Arduino related issues are becoming a bit more relevant for QL style hardware.

If it was any other uC I would say it’s because printf contains a memory barrier.

But my guess is it’s because the default aduino IDE uses an ancient and terribly buggy gcc version.

Thanks Peter, XorA.

The "print" statement is just a "Serial.println()", which is itself interrupt driven in the background. I've tested my code again and printing a single character, doesn't fix the data problem. Printing a few (actual number still to be determined) causes the data problem to vanish. I will not be beaten by a machine! (He said, hopefully!)

Cheers,
Norm.

Fixed it!

It was a timing/coding issue in some library code. It was setting the response to OK when it hadn't yet retrieved the final data byte from the I2C buffer. Because I put some printing in, that gave enough of a delay between the OK status and me dragging the bytes out.

Cheers,
Norm.