Hi Chris,
AFAIK, the Programming pin is tested after EVERY instruction (and maybe also during a PAUSE). So if you insist on pulling the SerIn pin high during "normal" operation then you can't use a RECONNECT, because the PICaxe will just keep waiting for a new download (and start running from the start when/if Serin goes low).
However, if you want to use a "long" push of the button to re-enter programming mode, then you could simply issue a RECONNECT command after the appropriate delay and then ensure that the program does NOT issue another DISCONNECT.
I'm surprised that you have space for the Programming socket, but as you do, note that it has two internal switches. One switch is connected to earth and becomes open-circuit when the plug is inserted. I don't know of all your constraints, but the solution I would use is to connect that switch to a spare PICaxe pin (which could even be the Serial-Out pin if really necessary). The pin would be pulled low when the Programming plug is disconnected, so the program can enable the internal weak pullup resistor for that pin and periodically test it to see when the programming plug is re-connected (i.e. pin high). Then it can issue a RECONNECT, after a suitable time delay if necessary.
Cherrs, Alan.
Hi Alan,
I was anxious to give you an immediate reply but I wanted to get all my ducks in a row first.
I really do like your idea of using the programming jack's switch contact, though I wouldn't use it as you described. After multiple failed attempts at structuring a bomb proof Reconnect procedure, which always culminated in requiring a Hard Reset procedure, I stumbled upon a statement found in one of the PDF help files that triggered a "Eureka!" moment for me. Unfortunately I don't remember which manual or page number. Anyway, this brief blurb stated that when a Reconnect command is executed it automatically issues a chip Reset! This explains why absolutely all my test code failed to Reconnect. It didn't matter if I placed Reconnect in an endless loop with no exit procedure. As soon as Reconnect was executed my chip would exit the loop and branch to the start of the program that contains the Disconnect command. The chip would then fall back into my main program loop and NOT look for the Break signal on the programming pin!
Solution: After realizing the Reset issue involved with the Reconnect command it became obvious that the logic of my code needed to be reversed. Instead of issuing a Reconnect and hoping the chip will catch a Break signal from PE6 I changed my code to look for the Break signal and have the Break signal trigger Reconnect. So far, I've tested it 10 times and it's working flawlessly. I can't express enough how pleasing it is to NOT see a PE6 error message of "Download Failed! MCU or ComPort not found"!
The Reconnect code below is a secondary loop outside of my main program. The main program branches to this loop when the Axe027 mini plug opens the GND contact on the programming jack.
Code:
Do
'Reconnect 'DON'T DO THIS!!!
High C.4
Pause 100
Low C.4
Pause 100
If PinC.5 = 1 Then 'Break Signal Detected
Reconnect 'Eureka! This Works!
End If
Loop
I think it's worth noting that the PE5 & PE6 simulators do not simulate Reconnect properly. While Reconnect also issues a Reset on the chip it's not executed in the simulator! Can it be I'm the first to have discovered this?
When a Reset is explicitly used PE6 will place a separator line directly below it. This lets the developer know that nothing below that line will be executed. I think Reconnect should be handled and displayed the same way.
BTW, I'm not sure I have the real estate to use the typical Picaxe (Con039) programming jack on my bike horn. There's no room to put it on the PCB and I was planning to use a small stereo panel mount connector by drilling a hole in the case. If I can fit it I did find panel mount versions of the Axe Con039 (with switch contacts) on Ebay.
Cheers,
Chris