Add general status query function

[oskay]

Suggestion: Add a single query function that handles the most common status request items -- to help with handling high-performance use of the EBB.

• Format: QG<CR>
• Response: button,pen,motor1,motor2,fifo<NL><CR>

Where:

• button gives the button status (equivalent to calling QB)
• pen gives the pen status (equivalent to calling QP)
• motor1, motor2, and fifo give the motor status (moving or not) and FIFO status (equivalent to calling QM).

or possibly (and probably better)

• Response: status_byte<NL><CR> Giving a single byte: xxxABCDE:

• x: Reserved

• A: button

• B: pen

• C: motor1

• D: motor2

• E: fifo

[EmbeddedMan]

Heck yeah. This makes a ton of sense and should be very simple to implement.

On Mon, Jan 7, 2019 at 1:19 PM Windell Oskay notifications@github.com wrote:

Suggestion: Add a single query function that handles the most common status request items -- to help with handling high-performance use of the EBB.

• Format: QG
• Response: button,pen,motor1,motor2,fifo

Where:

• button gives the button status (equivalent to calling QB)
• pen gives the pen status (equivalent to calling QP)
• motor1, motor2, and fifo give the motor status (moving or not) and FIFO status (equivalent to calling QM).

or possibly (and probably better)

• Response: status_byte Giving a single byte: xxxABCDE:

• x: Reserved

• A: button

• B: pen

• C: motor1

• D: motor2

• E: fifo

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/evil-mad/EggBot/issues/111, or mute the thread https://github.com/notifications/unsubscribe-auth/AAbeCHCLlUEpAPk1eqvVLvxyB1tyIvaqks5vA53KgaJpZM4Z0F9S .

[EmbeddedMan]

What would make for the easiest output (for both humans and machines) - a single hexadecimal byte, a single byte as an integer (zero padded?) or eight "0"s / "1"s representing the eight bits of the byte?

[oskay]

Probably a single hex byte, so as to minimize the total number of characters being sent.

[EmbeddedMan]

New version 2.6.1 is now waiting for your testing and review in Branch_Issue111. Docs updated as well.

[oskay]

Is there a reason to have the OK on the end there?

[EmbeddedMan]

No, other than it's there on all of the other commands. You can turn off all "OK" responses to speed things up if you want.

On Wed, Jan 9, 2019 at 3:20 PM Windell Oskay notifications@github.com wrote:

Is there a reason to have the OK on the end there?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/evil-mad/EggBot/issues/111#issuecomment-452845666, or mute the thread https://github.com/notifications/unsubscribe-auth/AAbeCK66xF0JxEXnCqbUiYVzHGxtp_kkks5vBl05gaJpZM4Z0F9S .

[oskay]

It's there on many of the other commands. This was modeled on QM, which doesn't. I could go either way on it.

One additional thing: I think that we should add the CommandStatus bit to this as well. Then it's a weighty and efficient status byte. (Are there others that should be added?)

If there should ever be an opportunity to rewrite the interface, it might be good to replace the QB, QP, and QM queries with just this one.

[EmbeddedMan]

Sure. All good points. There isn't a practical use for the "OK" at the end since this command has a nice fixed output format that you can parse on the PC side. I'll remove it.

I like adding the CommandStatus in as well. I can't think of any other status bits that would be useful right now, but what about throwing the digital logic state of 2 of the PortB 3-pin connectors in there? (So they could be used for easy limit switches.)

On Wed, Jan 9, 2019 at 3:53 PM Windell Oskay notifications@github.com wrote:

It's there on many of the other commands. This was modeled on QM, which doesn't. I could go either way on it.

One additional thing: I think that we should add the CommandStatus bit to this as well. Then it's a full and efficient status byte. (Are there others that should be added?)

If there should ever be an opportunity to rewrite the interface, it might be good to replace the QB, QP, and QM queries with just this one.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/evil-mad/EggBot/issues/111#issuecomment-452882480, or mute the thread https://github.com/notifications/unsubscribe-auth/AAbeCGIR3R10YQu6zPKM9K7yRbzVVbzJks5vBmTSgaJpZM4Z0F9S .

[oskay]

Sure. That sounds good.

[EmbeddedMan]

OK, branch has been updated with the proposed changed.

[EmbeddedMan]

Oskay, have you had a chance to test out these changes? It would be great to get PR #112 merged in if the new command works for you.

[oskay]

I think that this command is not quite working correctly, as of 2.6.1 -- or at least, does not match the documentation.

With no commands but pen down, QG gives 00 -- OK.

Pressing the button, QG now gives 10 (decimal 16, 0001 0000 binary), suggesting that bit 4 (not 5) is giving the button status.

Moving with the pen down and one item in the FIFO gives 07, or 0000 0111 binary, suggesting that bit 3 ("CommandStaus" <- noting typo) is not working as expected.

Toggling the pen up and again moving with an item in the FIFO gives 0F, decimal 15, or 0000 1111 binary, suggesting that bit 3 (not 4) is the pen position.

I have not tested the GPIO indicator bits.

We should also add an HTML table showing the bit positions (like a register description from MCU docs), to make it clear which is the low and high bit, and also give the "decimal value per bit" which can make it a little easier to follow.

[EmbeddedMan]

Thanks for testing this. I'll figure out what's going on and update the code/docs.

[EmbeddedMan]

I think part of the problem here is the documentation - mainly the numbering of the bits. I think we should number them bits 1 through 8.

So testing the existing code, I get the following results. (Note: all of these tests had jumpers from RB2 and RB5 to GND):

• With the pen up, nothing moving and no PRG button press, I get 0x00
• With the pen down, nothing moving and no PRG button press, I get 0x10 (bit 5)
• With the pen up, nothing moving, and a PRG press, I get 0x20 (bit 6)
• With the pen up, no PRG button press, one SM,10000,100,0 command, I get 0x0C (CommandStatus (bit 4) = 1, Motor 1 moving = 1 (bit 3))
• With the pen up, no PRG button press, one SM,10000,0,100 command, i get 0x0A (CommandStatus (bit 4) = 1, Motor 2 moving = 1 (bit 2))
• With the pen up, no PRG button press, and two back to back SM,10000,100,100 commands, I get 0x0F (CommandStatus = 1 (bit 4), Motor 1 moving = 1 (bit 3), Motor 1 moving = 1 (bit2), FIFO = 1 (bit 1))

So I think it is all working as expected, as far as I can tell. I have updated the documentation with this bit numbering change, as well as the table you suggested, and added more bit description text, but no code changes are necessary.

[oskay]

Ha! You changed the behavior of QG between the two versions!

From the Issue 111 (this issue) branch, using v 2.6.1 (as I reported), after reset, we get: QG: 08 (0000 1000)

After toggling the pen, we get QG: 00 (0000 0000)

So bit 3, starting the numbering at bit 0 following datasheet conventions (such that we're talking about the bit that represents 2^3 = 8) gives the pen status -- just as I had reported.

From the Issue 113 branch, using v 2.6.2, after reset, we get: QG: D0 (1101 0000)

After toggling the pen, we get QG: C0 (1100 0000)

So, in 2.6.2, bit 4 (2^4 = 16) gives the pen status. That's quite different.

I'll try and test the rest of the functions, if we're targeting 2.6.2

[EmbeddedMan]

I think I forgot to check in the hex file somewhere. Hold on a bit and I'll get it sorted out.

On Fri, Mar 15, 2019, 11:27 AM Windell Oskay notifications@github.com wrote:

Ha! You changed the behavior of QG between the two versions!

From the Issue 111 (this issue) branch, using v 2.6.1 (as I reported), after reset, we get: QG: 08 (0000 1000)

After toggling the pen, we get QG: 00 (0000 0000)

So bit 3, starting the numbering at bit 0 following datasheet conventions (such that we're talking about the bit that represents 2^3 = 8) gives the pen status -- just as I had reported.

From the Issue 113 branch, using v 2.6.2, after reset, we get: QG: D0 (1101 0000)

After toggling the pen, we get QG: C0 (1100 0000)

So, in 2.6.2, bit 4 (2^4 = 16) gives the pen status. That's quite different.

I'll try and test the rest of the functions, if we're targeting 2.6.2

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/evil-mad/EggBot/issues/111#issuecomment-473353370, or mute the thread https://github.com/notifications/unsubscribe-auth/AAbeCGLdCazq7yhYBTGZn_-1fw1mU5dFks5vW8n6gaJpZM4Z0F9S .

[oskay]

On 2.6.2:

Bit 0: 0x01 (0000 0001): FIFO full

Bit 1: 0x02 (0000 0010): Motor 2

Bit 2: 0x04 (0000 0100): Motor 1

Bit 3: 0x08 (0000 1000): Motion Command

Bit 4: 0x10 (0001 0000): Pen Up

Bit 5: 0x20 (0010 0000): PRG Button

Bit 6: 0x40 (0100 0000): B2 status: High for on

Bit 7: 0x80 (1000 0000): B5 status: High for on

[EmbeddedMan]

Yes, you are quite right. The v2.6.1 does not have the latest version of the QG command - the v2.6.2 code does. My mistake - I got confused with the branches. If we merge this branch (Branch_Issue111) in first (to get the doc changes), then merge in Branch_Issue113 we'll get the right documentation changes and the right code changes for both HM and QG.

So, considering the QG doc changes in this branch, coupled with the v2.6.2 hex file, are there still issues to resolve, or do you think we're good to merge?

[oskay]

OK; I'll go ahead and merge 111, then 113, with your approval.

I do want to make some changes to the QG docs, but I can do that after the merges.

[EmbeddedMan]

Perfect? Thanks

On Fri, Mar 15, 2019, 6:40 PM Windell Oskay notifications@github.com wrote:

OK; I'll go ahead and merge 111, then 113, with your approval.

I do want to make some changes to the QG docs, but I can do that after the merges.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/evil-mad/EggBot/issues/111#issuecomment-473473717, or mute the thread https://github.com/notifications/unsubscribe-auth/AAbeCKOlAwKFwdMDUceKnQx6MdrkLeZNks5vXC-AgaJpZM4Z0F9S .

[oskay]

OK, merged!

[oskay]

I've made some significant changes to the docs of this and a few other commands -- please check the diffs.

[EmbeddedMan]

I have to say - nothing but improvements. :-)

[oskay]

It looks like the 2.6.2 firmware updater is not published yet -- is that correct?

[EmbeddedMan]

Well, would you look at that. It certainly is not there yet. I'll get right on it.

*Brian

On Thu, Apr 18, 2019 at 1:03 PM Windell Oskay notifications@github.com wrote:

It looks like the 2.6.2 firmware updater is not published yet -- is that correct?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/evil-mad/EggBot/issues/111#issuecomment-484618823, or mute the thread https://github.com/notifications/unsubscribe-auth/AADN4CFQOC2BKQGAEFV3RCTPRCZWRANCNFSM4GOQL5JA .

[EmbeddedMan]

OK, the 2.6.2 updater is now in the repo.

[oskay]

Great-- thanks!

[oskay]

I'm updating the Mac installer as well, posting direct links in the AxiDraw releases page, and will update the EBB docs page to directly link to our wiki page about updating firmware.