rasteri wrote on 2023-01-23, 12:50:

tabm0de wrote on 2023-01-23, 11:59:

You should make a mini serial version 😉

Powering a keyboard from the serial port would be non-trivial.

Aha no I just meant mouse only 😉

tabm0de wrote on 2023-01-23, 13:02:

Aha no I just meant mouse only 😉

oops brainfart...

Even though USB mice don't need much power it would still be non-trivial. RS232 doesn't have VCC, so you'd have to scavenge some power from the unused control lines (+12/-12V) and convert it down to 5V.

I'm not even sure what kind of current you can draw from a serial port safely - you wouldn't be able to get away with a linear regulator as that would be too inefficient. Maybe some kind of split-phase DC-DC converter to use both +12v and -12v lines...

Even then, I imagine many fancy-pants RGB mice would draw too much current

rasteri wrote on 2023-01-23, 14:26:

oops brainfart... […]
Show full quote

tabm0de wrote on 2023-01-23, 13:02:

Aha no I just meant mouse only 😉

oops brainfart...

Even though USB mice don't need much power it would still be non-trivial. RS232 doesn't have VCC, so you'd have to scavenge some power from the unused control lines (+12/-12V) and convert it down to 5V.

I'm not even sure what kind of current you can draw from a serial port safely - you wouldn't be able to get away with a linear regulator as that would be too inefficient. Maybe some kind of split-phase DC-DC converter to use both +12v and -12v lines...

Even then, I imagine many fancy-pants RGB mice would draw too much current

Even worse, if I remember correctly the RS-232 standard only requires a minimum of +/- 3V, so there's no guarantee you'll have the full +/- 12V to play with. Would require some nifty circuitry to utilize both positive and negative voltages or use a boost converter. Plus, you wouldn't necessarily know which control lines are positive and negative? Interesting challenge... 😀

Eivind wrote on 2023-01-18, 00:20:

@rasteri: Attached a log dump of unplugging and reattaching the Kova+ using firmware compiled from commit f25808e.

OK I think I've figured it out.

Despite the Kova supporting boot mode, it also contains a "virtual" keyboard (presumably for keyboard shortcuts) that DOES NOT support boot mode. Trying to switch the virtual keyboard into boot mode seems to be glitching the mouse back to report mode.

The latest HIDman commit checks for boot mode support before enabling it. I should have really done that in the first place...

EDIT : btw, I will be implementing 16bit report parsing eventually, but I wanted to get boot mode fully debugged as it's important as a failover.

I tried to debug my non-working HIDman AXP serial mouse and made some progress.
It looks like the data I'm getting receiving on my PC is good (output of cutemouse PROTOCOL.COM).
However after some printf debugging I noticed that the MCU is not getting the RTS signal. So I'm also never receiving the 'M' and mouse detection fails.
I looked at pins 8 and 9 of the MAX232. The voltage levels I'm getting at pin 8 look ok (between -12V and +12V) but the output at pin 9 is only between 0V and 0.4V. So far I have not figured out why that happens. Any hints would be welcome.

@rasteri While looking at the code I noticed that this shift here seems wrong and should probably 6 instead of 11?

florian3 wrote on 2023-01-24, 02:10:

I looked at pins 8 and 9 of the MAX232. The voltage levels I'm getting at pin 8 look ok (between -12V and +12V) but the output at pin 9 is only between 0V and 0.4V. So far I have not figured out why that happens. Any hints would be welcome.

2 possibilities - either your MAX232 is fried or the CH559 is holding that pin low.

P0_DIR is supposed to be set to zero on startup, but maybe you have a different chip revision. Latest commit expressly sets P0_DIR rather than ORing it.

@rasteri While looking at the code I noticed that this shift here seems wrong and should probably 6 instead of 11?

Woops! That might be the cause of the jerkiness we're seeing on serial mice. Also fixed in latest commit, mouse seems smoother now too...

I got it working!
First I updated the software, still didn't work.
Then I lifted pin 9 of the MAX232 and measured again. Voltage level at pin 9 looked good without being connected to the CH559 P0.4.
After some trial and error I figured out that it works when I set P0.4 to 1 here. However I don't understand why this works. Any idea?

florian3 wrote on 2023-01-25, 01:21:

After some trial and error I figured out that it works when I set P0.4 to 1 here. However I don't understand why this works. Any idea?

Aha... it seems because P0.4 is open-drain, setting it to zero will pull it low. I wonder why it works on my system...

Setting it high should make everything work

EDIT : It seems that having a pin set to INPUT but also OPEN-DRAIN puts it in a kind of pseudo-bidirectional mode. Like even though it's an input, setting it low will actually pull the line low. Kinda unusual.

This device seems awesome. Is there a source to buy one ready made?

Xanxi wrote on 2023-01-25, 12:58:

This device seems awesome. Is there a source to buy one ready made?

I'll look into making it more widely available when most of the bugs are ironed out.

rasteri wrote on 2023-01-25, 11:00:

Aha... it seems because P0.4 is open-drain, setting it to zero will pull it low. I wonder why it works on my system...

Setting it high should make everything work

EDIT : It seems that having a pin set to INPUT but also OPEN-DRAIN puts it in a kind of pseudo-bidirectional mode. Like even though it's an input, setting it low will actually pull the line low. Kinda unusual.

Maybe it would be better to just a different GPIO for this that is configured as "normal" input?

Btw I also noticed that the code here configures the UART for the mouse to use 8 data bits, however I found other documentation online that says that MS serial mouse is supposed to use 7 data bits. I tried to change it but it made no difference.

I also tried increasing the data rate to 19200 combined with the patched mouse drivers of this serial mouse adapter project. Worked fine and I think the difference was noticeable. But not 100% sure because I had to flash the HIDman in between, so no side by side comparison.

florian3 wrote on 2023-01-25, 17:43:

Maybe it would be better to just a different GPIO for this that is configured as "normal" input?

I don't see the harm in leaving it there now we've figured out how to make it work. Anyway I picked 0.4 because it's the CTS pin of the UART, maybe I'll need flow control one day haha.

Btw I also noticed that the code here configures the UART for the mouse to use 8 data bits, however I found other documentation online that says that MS serial mouse is supposed to use 7 data bits. I tried to change it but it made no difference.

The 8th bit is to ensure a 1-bit gap between bytes. All the serial mice I own do this, so maybe this is expected by some mouse drivers.

I also tried increasing the data rate to 19200 combined with the patched mouse drivers of this serial mouse adapter project.

Awesome, any chance you could send me a patch/PR with the alternate UART init values? I'll make a menu item for it.

rasteri wrote on 2023-01-25, 19:08:

Awesome, any chance you could send me a patch/PR with the alternate UART init values? I'll make a menu item for it.

Made a PR with all my changes. Commits should be independent.

florian3 wrote on 2023-01-25, 21:10:

Made a PR with all my changes. Commits should be independent.

Oh awesome you even merged the case-sensitive fixes branch!

Nice to have an open source project where people actually help 😀

rasteri wrote on 2023-01-08, 13:36:

There is one other change I need to make to the AXP version, DTR needs to be routed to the MAX232 instead of TXD. This is required for reset detection.

I can fake it for existing boards (by spamming "M" for a few seconds after RTS goes high) but I'd prefer to do it the "proper" way.

@rasteri - Can you clarify why you think we need DTR (in addition to RTS) for reset detection? All the documentation I found so far seems to indicate that RTS (also) goes low along with DTR for at least 100 ms to signal a reset. When I attach an oscilloscope to both DTR and RTS they behave exactly the same. I see a 165 mS toggle on both of them at the exact same time. This is with the ctmouse.exe driver. Seems like DTR is redundant, unless you have seen different behavior with other drivers?

"A Mouse reset is generated by a falling edge of the host RTS line while the DTR line is low. This mode is used by most standard serial port mouse drivers to determine the
presence and type of pointing device connected to the host’s serial port."
- from 2.2.1.3 Serial Mouse Reset: https://web.stanford.edu/class/ee281/projects … 20Detection.pdf

If we want to stop spamming the "M", we could probably change the code to wait until RTS is brought back high (and wait an additional 10ms or so) before sending it out. I think that is closer to what the host is expecting to begin with.

TXD might still come in handy in the future. Some mice expect the host to send it commands to switch modes (i.e. to increase the baud rate) or return other information (like PnP strings). So, it feels wrong to loose it for a possibly redundant signal.

serisman wrote on 2023-01-27, 22:38:

"A Mouse reset is generated by a falling edge of the host RTS line while the DTR line is low. This mode is used by most standar […]
Show full quote

rasteri wrote on 2023-01-08, 13:36:

There is one other change I need to make to the AXP version, DTR needs to be routed to the MAX232 instead of TXD. This is required for reset detection.

I can fake it for existing boards (by spamming "M" for a few seconds after RTS goes high) but I'd prefer to do it the "proper" way.

"A Mouse reset is generated by a falling edge of the host RTS line while the DTR line is low. This mode is used by most standard serial port mouse drivers to determine the
presence and type of pointing device connected to the host’s serial port."
- from 2.2.1.3 Serial Mouse Reset: https://web.stanford.edu/class/ee281/projects … 20Detection.pdf

If we want to stop spamming the "M", we could probably change the code to wait until RTS is brought back high (and wait an additional 10ms or so) before sending it out. I think that is closer to what the host is expecting to begin with.

Here's a PR with what I believe to be better serial mouse detection (doesn't need to spam the 'M') using just RTS: https://github.com/rasteri/HIDman/pull/9
It has been tested with the CuteMouse driver, and seems to work pretty good. I can do some testing with other drivers in a bit.

I was reverse in my thinking about waiting until RTS goes high again (TTL is inverse RS232), but it seems to work fine the other way around.

serisman wrote on 2023-01-27, 22:38:

@rasteri - Can you clarify why you think we need DTR (in addition to RTS) for reset detection? All the documentation I found so far seems to indicate that RTS (also) goes low along with DTR for at least 100 ms to signal a reset.

Just looking at the mice I have, some have DTR hooked up, some have RTS, and some have both. So I was afraid certain drivers would toggle one but not the other. My thinking was to look at both lines and cover all bases.

But you're right it would be a shame to lose TXD, we could even use it to do firmware updates from DOS. Or per-game settings from a batch file.

I'll try a range of serial mouse drivers on the scope and see what they do. Maybe we don't need DTR.

rasteri wrote on 2023-01-28, 02:42:

Just looking at the mice I have, some have DTR hooked up, some have RTS, and some have both. So I was afraid certain drivers wou […]
Show full quote

serisman wrote on 2023-01-27, 22:38:

@rasteri - Can you clarify why you think we need DTR (in addition to RTS) for reset detection? All the documentation I found so far seems to indicate that RTS (also) goes low along with DTR for at least 100 ms to signal a reset.

Just looking at the mice I have, some have DTR hooked up, some have RTS, and some have both. So I was afraid certain drivers would toggle one but not the other. My thinking was to look at both lines and cover all bases.

But you're right it would be a shame to lose TXD, we could even use it to do firmware updates from DOS. Or per-game settings from a batch file.

I'll try a range of serial mouse drivers on the scope and see what they do. Maybe we don't need DTR.

Ok, sounds good. Thanks!

I did just try my code changes with some other drivers, and so far they all seem to work fine as well.
- Win 3.11 built-in driver
- Microsoft Mouse Driver Version 11.00 (mouse.exe)
- CuteMouse v2.1 beta4 (ctmouse.exe)
- CuteMouse v1.9.1 alpha1 (ctmouse.exe)

By the way, I've added experimental XT support in another branch. It works reasonably well on my FE2010/PT8010AF based Micro 8088, but they read the keyboard in a slightly odd fashion.

If anyone has a real 5160 and wants a free HIDman in exchange for some testing please hit me up.

Question, are you guys and girls using usb-a to usb-a for programming or usb-a to usb-c?