Recent content by amdunn

How we got started on this is that the compiler also doesn't report that correctly, or at least not in a way that's meaningful to the programmer. It appears the compiler only reports memory used for TABLE when you actually include those bytes in a TABLE statement. So in the example where you...

Yes I very much like that diagram... it covers the difference in layout between the families of parts. But here's the part causing confusion. In the X2 diagram above, it LOOKS LIKE there is a variable amount allocated to the table (diagonal line), and that variable amount is deducted from...

I've never seen a 4.0 compiler available for download for Linux. The ones on the download page are December 2014 version 3.1

Not using the PE because I only have a Linux environment... opposite of your situation. So I don't know what the PE would show.

The program uses exactly 68 bytes of TABLE... and I would assume (although one shouldn't assume) that those bytes are calculated in the "Memory used = 3890 out of 4096 bytes" in the first (working) example, since the exact same TABLE statements are in both cases. So I guess the answer may lie...

That's a pretty big "anomaly"... to suddenly lose your last 200 bytes (that you thought you had) of program memory is concerning! Is there a way to confirm that's really what is going on... ie. that it isn't a compiler bug or something similar? If it's really true, there's a LOT of code...

I've got a fairly large program that I'm downloading into a 20X2 using the command-line Linux compiler, version 3.1 If I download the program with a small amount of code commented out, I get the following: DOWNLOADING R01.bas PICAXE-20X2 Compiler Version 3.1 Copyright (c) 1996-2014...

And that could finally make sense as to why the resistor makes a difference... I'm going to swap out the last inverter for a 2N2222 driver and see what effect that has. The serial gate/opto chain works fine and returns a good, clean, square round trip signal all the way down the line... but...

Some clarifications on points raised above. First it is not a battery operated project, so the power issue wasn't considered. Also, it's only a partial circuit diagram. All device inputs everywhere are terminated correctly. There are no unused gates as the extras are used for other...

Opto pull-up is 10K. A simplified version of the circuit schematic is attached (there's also a bunch more I/O - sensor inputs, output LEDs, and so forth... but they're not even exercised in my testing so far). The intent is that every 20X2 in the chain receives what the PC sends (as long...

Yes, there is decoupling on each opto, per the datasheet.

It is "series wired" not "parallel wired"... but It's not a daisy-chain where each node retransmits... the goal was to not have every board having to retransmit everything. Each board in effect sees what the PC transmitted... just buffered further down the line (more gates and optos). The...

Power and ground check out fine. I've only tried with one 20X2 target (I've only wired up one) but I have wired up a string of the gates and optos to simulate the environment the 20X2 would be in with multiple real boards... and to see how the signal looked at the end of the chain (and it...

I have checked it with a scope. Clean, square, symmetrical waveform. And the PC that is injecting the data at the start of the train of gates can correctly read the data that comes out the other end of the chain. Think a single long serial chain like this: PCTX - opto - 3 gates - opto - 1...

I initially thought it was random garbage... but then discovered the pattern noted above that the mis-reads are always the same data. When 41 hex ('A') is mis-received it is ALWAYS mis-received as hex D0. When 43 hex is mis-received it is ALWAYS mis-received as hex A1. The super-fast...