Recent content by danners430

No, not as yet - I currently don't have the facility to do so (hopefully soon!) so have been drawing on past experience of using LDRs and PICAXEs

That makes sense - I'll stick to 8-bit values... at the end of the day, it's not like I need ridiculously accurate readings! I'll go ahead and start prototyping and testing... none of the trackwork on the layout is complete yet, but I'm sure I can wire something up provisionally to do some...

OK, I've taken what's been done and developed it further somewhat... As I don't know how many LDRs will be connected at any one time, I'm designing the program to be portable between the three X2 SMD chips. As I'm custom designing a PCB, it's completely free to have footprints for all three...

Aye, with the updated table values it runs perfectly fine in the simulator too... Just (morbidly) curious to see what the "old" code would do!

so... I wonder what happens if you load it onto a chip...? Unfortunately I can't test it just now... UPDATE: ran the simulation again, and can confirm that stepping through crashes the simulator - not PE6 itself, you can still scroll etc. but the simulation side of things is stuck... Trying to...

Yet it compiles and simulates correctly without change... 🤔 Methinks this bug might be a butterfly...

Theoretically, the simple fix would be to replace the pin numbers with the ADC numbers in the Table at the beginning of the program - and for clarity comment the pin number beside it. Mind you, it does compile and simulate on PE6...

Well, it's taken me until today to finally get my head around it, but I've finally understood the code... (whoever invented the common cold has a lot to answer for!) I'm assuming that the four #DEFINE statements in lines 39-42 could easily be re-written as a multi-line macro for readability...

ooooh! Now that I didn't know! I just assumed from previous experience that pre-processor and compiler directives shouldn't be mixed... even more optimization possible then.... With the new knowledge from Aries as above, that definitely makes more sense :D

OK, I've changed the Main procedure with the following. I wasn't able to change the init procedure as this uses a set of symbols to set the "default" brightness level, again for ease of programming. But this seems to work... Do varOffset = var0 #IF number = 1 for i = 0 to 0 #ELSEIF...

(In fact, having a quick scan of the code, it wouldn't even be that hard... as long as my scratchpad entries are always 5 bytes long, it would be a simple case of incrementing two addresses then repeating........) be right back!!

The reason behind using the directives is (in my mind at least) a simple one - I'm only going to have a certain number of sensors connected at any one time, with multiple installations each with differing numbers. Using the directives allows me to *very* quickly only program the code needed for...

OK, I spent the weekend developing some firmware - it seems to work in the simulator, and simply requires the "master" device to poll it over i2c every so often. Any thoughts on the attached?

Precisely my discovery :) As I said, it's not much of a problem for myself, as I've found the solution, but as it doesn't seem to be documented elsewhere this thread will hopefully prove to be useful to other beginners who make the same mistakes

I've just discovered a strange oddity - I can't seem to use the colon (:) to merge multiple lines of code into one, curly brackets to "group" pieces of code in the editor, or use comments on the same line when using preprocessor directives. The following doesn't work: #IF number > 1: put...