Bluetooth serial programming

[GTBecker]

Sorry of this has been covered. Has a Bluetooth serial adapter been identified that can toggle DTR sufficiently quickly to control and program a ZX-24?

[GTBecker]

Ah. The "ATN" character method should work. I'll try that tomorrow.

[GTBecker]

Don, I am having some difficulty understanding the distinction between #ifdef x and #if defined(x). Can you clarify that, please?

[dkinzer]

the distinction between #ifdef x and #if defined(x).

There is no functional difference. The former is the original way of determining if a C preprocessor symbol is defined. The latter was introduced later to facilitate testing multiple conditions, e.g.:

Code: Select all

#if defined(abc) && defined(def) && (DEBUG != 0)
<something>
#endif 

The only way to test multiple conditions with the original syntax is to nest the conditionals, e.g.

Code: Select all

#ifdef abc
#ifdef def
#if (DEBUG != 0)
<something>
#endif
#endif
#endif

[GTBecker]

Good, thanks. I haven't been able, so far, to get the ATN-character download method working despite following your demo code from a thread with Ben Sturgess http://www.zbasic.net/forum/about1082.html&highlight=

The IDE locks up and can only be terminated via the task manager. I've verified that I'm trapping the ATN character and executing ZXCmdMode() but haven't seen success yet. I'm suspecting a speed issue; the Bluetooth channel normally runs at 115200 and I don't know if it can shift to 19200 gracefully. I'll pound on it some more until it succumbs.

One thing I've noticed, a benefit, is that DTR/ATN still works even when persistent address 13h is set non-zero (which I expected would desensitize the processor to the hardware toggle). Is that right? For the time being, I have both hardwired and Bluetooth channels to the target machine, automatically switched if Bluetooth DCD is true, so it's not difficult to play with this, fortunately. I want to lose the hardwire but still be able to program the machine.

[dkinzer]

DTR/ATN still works even when persistent address 13h is set non-zero

That is correct. It serves as a fail-safe mechanism so you can download by that method even if the ATN character isn't working.

[GTBecker]

Baffled for the last week trying to get the ATNChar download method to work through a Bluetooth link, I think I see why it is failing.

I pulled the ATN/DTR line when hardwired to produce a DTR-less serial connection and see that the processor utters two Nulls after zxCmdMode is issued. The Bluetooth channel seems to not pass Nulls so the IDE never hears that the processor is ready for download, I think. Is there a remedy to that?

I also remain unclear about just what I'm doing when I set ATNChar at Persistent &h13. It appears that if I set it to zero it is entirely up to my code to capture the ATNChar and issue zxCmdMode. If I set &h13 to ATNChar, though, it seems that the OS captures it (and enters command mode) and my code never sees it. Is that right?

Oddly, it seems that if &h13 is zero and my code captures the ATNChar and issues zxCmdMode, subsequent ATNChars are captured by the OS as if I had set &h13 to ATNChar. That puzzles me.

I don't think I have any control over the Bluetooth Null handling. Can anything be done?

[GTBecker]

Nah, disregard the Bluetooth Null comments. I wrote a little test and see that the link does indeed pass all 256 byte codes, as it must. Still, the link behaves differently than does a hardwired connection. More to learn.

[stevech]

maybe it uses DLE/STX or some such byte-stuffing?

[dkinzer]

It appears that if I set it to zero it is entirely up to my code to capture the ATNChar and issue zxCmdMode. If I set &h13 to ATNChar, though, it seems that the OS captures it (and enters command mode) and my code never sees it. Is that right?

Correct on both parts.

[GTBecker]

It appears that there are two issues with Bluetooth downloads: timing and buffered data.

A Bluetooth serial link can take several seconds to open; the IDE seems to allow only one second for the processor prompt to arrive before it transmits an &h1B; the processor and IDE then exchange 1B and &hE0 until the IDE gives up. This happens even if the Bluetooth link is already open, though, which still puzzles me.

Further, it looks like several E0 bytes can be buffered in the Bluetooth transmitter and are dumped to the IDE en masse upon connection. If the processor sees the ATNChar from the IDE and issues a ">" prompt, it seems to be lost when the IDE sends a 1B to try to clear the E0s from the link, I believe.

Even hardwired, though, timing seems an issue - but the IDE recovers. Here, for example, is a 115200 hardwire exchange through the first code block. Notice that the IDE appears to send a 1B after the ATNChar (here, an &h08) even before it receives the first prompt, which the processor then repeats twice before the process continues:

• > IDE to ZX-24n
  < ZX-24n to IDE
  
  >000071: 26.09.2009 22:01:22.829 08 .
  >000075: 26.09.2009 22:01:22.938 1B .
  <000083: 26.09.2009 22:01:22.985 3E >
  >000087: 26.09.2009 22:01:23.032 3E 0D >.
  <000095: 26.09.2009 22:01:23.032 3E FE >þ
  >000127: 26.09.2009 22:01:23.250 1B .
  <000135: 26.09.2009 22:01:23.266 0D 0A 3E ..>
  >000139: 26.09.2009 22:01:23.344 49 0D I.
  <000145: 26.09.2009 22:01:23.360 49 0D 0A 5A 58 32 34 6E 20 76 31 2E 32 20 31 34 33 64 2C 39 38 30 63 0D 0A 3E I..ZX24n v1.2 14 3d,980c..>
  >000149: 26.09.2009 22:01:23.454 4C 0D L.
  <000155: 26.09.2009 22:01:23.469 4C 0D 0A 41 L..A
  >000159: 26.09.2009 22:01:23.563 53 00 00 00 00 05 5A 58 32 34 6E 63 F9 S.....ZX24ncù
  <000165: 26.09.2009 22:01:23.579 41 A
  >000169: 26.09.2009 22:01:23.579 46 00 00 00 01 00 0C 95 09 02 08 91 41 06 04 9D 4D 0A 00 99 49 0E 1C 85 55 12 18 81 51 16 14 8D 5D 1A 10 89 59 1E 2C B5 65 22 28 B1 61 26 24 BD 6D 2A 20 B9 69 2E 3C A5 75 32 38 A1 71 36 34 AD 7D 3A 30 A9 79 3E 4C D5 31 5A 48 D1 01 46 44 DD 0D 4A 40 D9 09 4E 5C C5 8A 4F 58 C1 CD 4B 54 CD D5 47 50 C9 19 5E 6C F5 25 62 68 F1 21 66 64 FD 2D 6A 60 F9 29 6E 7C E5 35 72 78 E1 31 76 74 ED 3D 7A 74 37 A9 44 BB 4F 83 ED 00 39 39 7A 49 A6 B7 E7 F8 BC 14 32 C6 12 AF 49 A9 95 51 E8 89 27 43 7F 27 D1 A0 0E CB 0B 08 1D A4 A5 A6 27 97 AE 86 D1 09 17 C2 6A 20 6B 89 20 D1 49 3D 0B EB 41 AA 46 80 EB 2C 3C 8D 7C 45 5E FE 73 FB 0C 01 76 91 75 BF 17 C1 06 EF D4 7A 9F 19 67 02 99 61 E1 EC 72 DE D1 8E 66 71 67 6A EB D8 43 4C 4D C2 57 EA EB EC 6D D1 E7 F0 F1 F2 4D 66 D1 BF E5 C6 52 50 51 D6 43 33 33 65 13
  <000175: 26.09.2009 22:01:23.626 41 A

I'll follow with a Bluetooth exchange, but there is little to see there as the IDE and processor just yell "What?" at one another.

[GTBecker]

Here is a Bluetooth 115200 exchange:

• > IDE to ZX-24n
  < ZX-24n to IDE
  
  >000079: 27.09.2009 11:10:45.540 08 .
  >000083: 27.09.2009 11:10:45.634 1B .
  <000091: 27.09.2009 11:10:45.681 E0 à
  >000095: 27.09.2009 11:10:45.728 1B .
  <000103: 27.09.2009 11:10:45.775 E0 à
  >000107: 27.09.2009 11:10:45.837 1B .
  <000115: 27.09.2009 11:10:45.884 E0 à
  []
  <000307: 27.09.2009 11:10:47.603 E0 à
  >000311: 27.09.2009 11:10:47.665 21 0D !.
  <000319: 27.09.2009 11:10:47.712 E0 E0 àà
  >000354: 27.09.2009 11:10:47.759 20
  
  At this point the IDE declares "Device failed to respond to ATN character {8} on COM3."

Here is the same but with the Bluetooth data lines disconnected from the processor:

• >000673: 27.09.2009 11:28:06.618 08 .
  >000677: 27.09.2009 11:28:06.728 1B .
  >000681: 27.09.2009 11:28:06.821 1B .
  >000685: 27.09.2009 11:28:06.915 1B .
  []
  >000945: 27.09.2009 11:28:27.353 1B .
  >000949: 27.09.2009 11:28:27.462 21 0D !.
  >000984: 27.09.2009 11:28:27.556 20
  
  IDE: "Device failed to respond to ATN character {8} on COM3."

I thought I saw a full second pause after the ATNChar from the IDE when I did this last night, but the wait appears to actually be ~100mS. I suspect that this is far too short for a wireless link.

[GTBecker]

Here is a 115200 hardwire ATNChar download exchange through the first code block, initiated while my code was running and detected and started by my code (below). Again, the IDE-ZX-24n exchange seems to get off to a rocky start but succeeds:

• > IDE to ZX-24n
  < ZX-24n to IDE
  
  <002509: 27.09.2009 14:52:23.665 0D 4A 38 39 20 30 0A 0D 49 30 20 30 20 30 20 30 20 0A .J89 0..I0 0 0 0 .
  >002549: 27.09.2009 14:52:23.696 08 .
  <002557: 27.09.2009 14:52:23.712 3E F8 >ø
  >002561: 27.09.2009 14:52:23.806 1B .
  <002569: 27.09.2009 14:52:23.821 0D 0A 3E ..>
  >002573: 27.09.2009 14:52:23.900 3E 0D >.
  <002581: 27.09.2009 14:52:23.915 3E FE >þ
  >002613: 27.09.2009 14:52:24.118 1B .
  <002621: 27.09.2009 14:52:24.134 0D 0A 3E ..>
  >002625: 27.09.2009 14:52:24.212 49 0D I.
  <002631: 27.09.2009 14:52:24.228 49 0D 0A 5A 58 32 34 6E 20 76 31 2E 32 20 31 34 34 34 2C 63 31 37 33 0D 0A 3E I..ZX24n v1.2 1444,c173..>
  >002635: 27.09.2009 14:52:24.337 4C 0D L.
  <002641: 27.09.2009 14:52:24.337 4C 0D 0A 41 L..A
  >002645: 27.09.2009 14:52:24.446 53 00 00 00 00 05 5A 58 32 34 6E 63 F9 S.....ZX24ncù
  <002651: 27.09.2009 14:52:24.462 41 A
  >002655: 27.09.2009 14:52:24.462 46 00 00 00 01 00 0C 95 09 02 08 91 41 06 04 9D 4D 0A 00 99 49 0E 1C 85 55 12 18 81 51 16 14 8D 5D 1A 10 89 59 1E 2C B5 65 22 28 B1 61 26 24 BD 6D 2A 20 B9 69 2E 3C A5 75 32 38 A1 71 36 34 AD 7D 3A 30 A9 79 3E 4C D5 C0 5A 48 D1 01 46 44 DD 0D 4A 40 D9 09 4E 5C C5 B5 4F 58 C1 FC 4B 54 CD C4 47 50 C9 19 5E 6C F5 25 62 68 F1 21 66 64 FD 2D 6A 60 F9 29 6E 7C E5 35 72 78 E1 31 76 74 ED 3D 7A 74 37 A9 44 BB 4F 83 ED 00 39 39 7A 49 A6 B7 E7 F8 BC 14 32 C6 12 AF 49 A9 95 51 E8 89 27 43 7F 27 D1 A0 0E CB 0B 08 1D A4 A5 A6 27 97 AE 86 D1 09 17 C2 6A 20 6B 89 20 D1 49 3D 0B EB 41 AA 46 80 EB 2C 3C 8D 7C 45 5E FE 73 FB 0C 01 76 91 75 BF 17 C1 06 EF D4 7A 9F 19 67 02 99 61 E1 EC 72 DE D1 8E 66 71 67 6A EB D8 43 4C 4D C2 57 EA EB EC 6D D1 E7 F0 F1 F2 4D 66 D1 BF E5 C6 52 50 51 D6 43 33 33 8E 52
  <002661: 27.09.2009 14:52:24.509 41 A

Here is the same via a 115200 Bluetooth link, which fails to send the prompt after my code detects the ATNChar (an illuminated LED shows that) and issues zxCmdMode(False); the prompt appears to not be sent by the processor:

• > IDE to ZX-24n
  < ZX-24n to IDE
  
  <001982: 27.09.2009 14:03:25.681 0D 4A 38 38 20 30 0A 0D 49 2D 31 20 30 20 30 20 30 20 0A .J88 0..I-1 0 0 0 .
  >001997: 27.09.2009 14:03:25.712 08 .
  <002005: 27.09.2009 14:03:25.728 0D 4A 38 38 20 30 0A 0D 49 30 20 30 20 30 20 30 20 0A .J88 0..I0 0 0 0 .
  >002017: 27.09.2009 14:03:25.821 1B .
  <002025: 27.09.2009 14:03:25.868 E0 à
  >002029: 27.09.2009 14:03:25.915 1B .
  <002037: 27.09.2009 14:03:25.978 E0 à
  []
  <002229: 27.09.2009 14:03:27.696 E0 à
  >002233: 27.09.2009 14:03:27.743 21 0D !.
  <002258: 27.09.2009 14:03:27.790 E0 E0 àà
  >002276: 27.09.2009 14:03:27.853 20

Code: Select all

Function NextComByte() As Byte
	dim b as byte
	CALL GetQueue(InQueue_1, b, 1)		' task blocks here until a byte arrives
	if b = cmdChar then					' get ready for code download
		Call PutPin(pinLEDRed, 0)		' show download active
		Call zxCmdMode(False)			' application stops for download
	end if
	NextComByte = b
End Function

[GTBecker]

More:

Not surprisingly, a 115200 hardwired connection, looped back with a ZX-24n, is fast - usually less than a millisecond round-trip:

>028895: 27.09.2009 17:10:00.759 31 1
<028901: 27.09.2009 17:10:00.759 31 1 0.000
>028905: 27.09.2009 17:10:02.978 32 2
<028911: 27.09.2009 17:10:02.978 32 2 0.000
>028915: 27.09.2009 17:10:04.775 33 3
<028921: 27.09.2009 17:10:04.790 33 3 +0.015
>028925: 27.09.2009 17:10:06.915 34 4
<028925: 27.09.2009 17:10:06.915 34 4 0.000


A 115200 Bluetooth loopback - using a ZX-24n to do the loopback - takes about 50mS round-trip at 115200:

>000061: 27.09.2009 17:18:52.915 31 1
<000067: 27.09.2009 17:18:52.978 31 1 +0.063
>000071: 27.09.2009 17:18:53.775 32 2
<000077: 27.09.2009 17:18:53.821 32 2 +0.046
>000081: 27.09.2009 17:18:54.478 33 3
<000087: 27.09.2009 17:18:54.525 33 3 +0.047
>000091: 27.09.2009 17:18:55.259 34 4
<000097: 27.09.2009 17:18:55.306 34 4 +0.047 , Mean +0.05075

It will certainly take only two bytes, and very likely only one byte, queued ahead of the ATNChar-zxCmdMode induced, processor-issued prompt to exceed the ~100mS (probably two-PC-ticks, ~110mS) IDE tolerance with this ~50mS Bluetooth transit time - and that disregards any processing time that might delay detecting the ATNChar. That, I suggest, is too tight.

Can it be relaxed, Don?

[GTBecker]

I finally have reliable downloads via Bluetooth. To make a long crooked path a straight line, the link must be immune to RTS and DTR, and - at least for now - it must operate at 19200. I'll further research high-speed Bluetooth when I have more time; it remains elusive.

Make certain the module pair you choose is not disturbed by any combination of RTS and DTR states at either end and configure the modules for 19200. Both methods of ATN character capture work fine, but I've found the code-capture method (Persistent &H13 = 0) very useful to turn off devices before allowing the download lest, in my case, a motor remains running uncontrolled for the duration. If you allow the processor to capture the ATN character (Persistent &H13 = ATNChar) the I/O pins are often floating for the duration of the transfer and verification.

Obviously choose an ATN character that will not normally be present on the link; it must be uniquely sent only by the IDE or your downloader.

This facility allows me to leave the prototype hardware in a difficult-to-access, in fact rotating, location and still be able to easily work on code. I also have a handheld wireless joystick controller that can now accept code, too, without cabling. Very nice.

Thanks to Don for his assistance.

Tom