-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No mouse movement. #1
Comments
Feel free to create an issue after days instead of a week. Let's look. I first try to answer the first question which I think you have deleted. I don't use an UART for printf debugging. Please never use an UART again for printf debugging. The RP2040 is capable of doing RTT. The vscode Projekt does it automatically. By enabling CONFIG_DEBUG_PRINT you enable the printf output over RTT. Please look into it, it is very useful as it doesn't take up any pins. But you need to have a debugger attached for it, which can just be another Rp Pico. Next the problem itself. I think you have the Yaumataca in C1351 mode. You may need to press the button to cycle through the modes. What computer do you have? Amiga? Quadrature on mouse click sounds extremly like C1351. |
You are the unlucky first person which has ever created an issue here. But with every issue I can sense the problems this project has and improve it. |
Yes, I deleted the issue as I figured that one out, but I didn't had a second pico or a debugger, according to the printouts, it's running in Amiga mode, I should have 2 pairs of quandrature output, but on the scope I can only see one output per axis |
Alright. You've found an issue. I've looked again at the svg files and it seems that after I've done the PCB, I forgot to update the first svg. The commits are squashed. I had an old version, where the old pinout is still used. At first there was no intent of making a PCB. This is where the first SVG was right. It was intended for manual wiring. |
If you see the prints, when moving the mouse there should be a display of the quadrature signals. I would expect that these are also present on the pins. There is not much between the outer pads and those prints. |
Here is a log of what's happening, when I move the mouse in both axis, only the first 2 bytes moves: |
Oh no. I have a theory. This here catches my mind.
It says 4 reports... I've added a branch for you: This does two things. It ditches the "report mode" in favor of the default boot compatibility mode. Wheels no longer work with this. But it behaves like a standard PS/2 mouse. Please try if this fixes the problem. |
it's a logitech mouse modle M310 with a unify receiver, I will try it |
I'm building the branch and I get : |
Ah this is because you are building without CONFIG_DEBUG_PRINT. PRINTF is masked out. This print is rather helpful. It prints the full report for protocol analysis :-) |
I've just experimented with a rapoo receiver. I'm having the same issues as you. But the workaround should fix your issues. |
Yes, this is better: Yaumataca says hello! |
Thank you for finding this. I'll recommend to remove the prints now as it will disrupt the usability because lag is generated. Afterwards please use the device with this change for now so you can actually use it with your beloved machine. We will leave this Issue open until a fix exists. |
ok, I tested it on my amiga but the mouse it's not moving, the mouse goes up and down but not left and right, it's this related to the debug? |
Maybe this is still related to the pinout misunderstanding from the SVG.
The SVG was wrong at some point. Those are the right numbers. According to the prints I see from you, those are exactly the values at the output of the Pico. Quadrature Encoding is indeed performed so it has to work. When up and down is fluent, this means that this is no longer related to Atari ST or C64 mode.... |
Ah you have a scope. That is very good. I mean, yes I see the signals. And if there is quadrature on the pins, there should be something occurring on the Amiga as long as you've soldered the right pins to the controller port. You can even now check the signals in the Amiga. It is no longer a software issue we are facing here. The quadrature on up down is the same as the one left right. Just different pins. |
Ok, after some rewiring seems to be alright. I do now have some problems with the left buttons. The amiga seems to see the left button always pressed, like it's stuck, if I press it, it unstuck and it depressed until I pressed again, basically, it's sticky. the middle button it's always high. the right button doesn't work |
Always pressed? This seems wrong.... Just in case. Do you have directly wired the Pico Pins to the Amiga? If yes, this is not the intended way as the Amiga is 5V while the Pico is officially not 5V tolerant. There are NPN transistors used as level shifters. This also means of course that the output of the Pico is inverted. A high signal on the Pico causes the transistor to pull down the signal on the Amiga which has an internal pull up. |
No, of course not, I'm using two 8bit level translators (the one readily available on AliExpress and company) the rest of the mouse works well, but maybe it's inverted from the way it works with the transistors ? |
Yes, in this case you've build it differently than originally intended. I think you may just need to change the code in |
I haven't tested this setup yet. Usually it is not expected to actually drive an Amiga controller port up. It has internal pull ups and pushing it down is sufficient for everything.... except the C64... or the Paddle inputs.... |
Cool, thank you very much for the project and the support :) |
I know it has been a while. I've made some changes to the software. It is now capable of parsing the HID descriptor of a mouse. This should allow using your mouse together with a wheel. |
I have completely forgotten about this, but tahst awesome ! I will give it a try ! |
Don't forget that you have build the device differently.^^ |
I spent a week trying to figure out what's going on with this project.
I've got the UART working to get some info, I had to move some of he pins of port 2 to do that.
the only thing I can get it's some quadrature out on GP14 and GP15 when..I press the mouse button?
...what?
What's up with the sense pin?
also, the schematics here:
https://github.com/Slamy/Yaumataca/blob/main/schematic/yaumataca/yaumataca.svg
says gpio14 and 15 are up and down but here:
https://raw.githubusercontent.com/Slamy/Yaumataca/8ccdbdfc71e2675bf3530aba36dd38ebfc55d48c/doc/pinout.svg
are left and right?
what's going on.
The text was updated successfully, but these errors were encountered: