Sending USB reports to set keyboard LEDs? #6
Comments
|
I added keyboard LED control to the core: https://github.com/epsilon537/usb_hid_host |
|
That is nice. I'll merge it. |
|
hi [epsilon537] |
|
Is this the version you merged: https://github.com/epsilon537/usb_hid_host/blob/boxlambda/src/usb_hid_host/asukp? |
|
yes this I have merged
It still exports 4-bit hex file because of this
printf "%01x\n", shift(@_);
I changed to
printf "%02x\n", shift(@_);
but still the usb enumeration doesn't work for me (it worked before your
changes
merged)
…On Tue, Apr 2, 2024 at 9:50 PM Epsilon ***@***.***> wrote:
Is this the version you merged:
https://github.com/epsilon537/usb_hid_host/blob/boxlambda/src/usb_hid_host/asukp
?
When I run it against this ukp.s,
https://github.com/epsilon537/usb_hid_host/blob/boxlambda/src/usb_hid_host/ukp.s,
it produces a .hex file where I can see a few opcodes > 10 (hex).
The generated usb_hid_host_rom.v also has 5 bits wide data.
—
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC4K2R5TFIBFWBFIOVKJA23Y3MDZDAVCNFSM6AAAAABBTJTSFWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZSHE4DANBVHE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
I'll take a look, but I'm in transit right now. It might be a day or two before I can report back. |
|
no problem, I'd like to have LEDs support,
with similar code we could control joystick vibration
If if you know write a short description of all assembly
commands what they do, like you documented those
3 that you added
…On Tue, Apr 2, 2024 at 10:18 PM Epsilon ***@***.***> wrote:
I'll take a look, but I'm in transit right now. It might be a day or two
before I can report back.
—
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC4K2R6BNB7YFKCZ6XJJEGDY3MHANAVCNFSM6AAAAABBTJTSFWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZTGAYTSOBZG4>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
OK, I might do that (the ones I understand at least ;-) |
|
yes of course whatever you understand its still
better than nothing :) I tried and found out I understand
too little of them
I'm building for ulx3s boards they have ECP5 12F and 85F
I made it work without your LED patches. I added in Makefile
to quickly replace only firmware without full recompiling FPGA
bitstream so development of ukp code can be real fast
I added pull request for ulx3s but later I merged
your LED changes without checking them
There was my pending pull request and when nand2mario
merged later on his repo are not only my ulx3s changes but
also your LEDs
…On Tue, Apr 2, 2024 at 10:58 PM Epsilon ***@***.***> wrote:
OK, I might do that (the ones I understand at least ;-)
You mentioned enumeration isn't working for you. Which board are you
building?
—
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC4K2R2XVCYY7GDCDWZ6VWLY3MLWFAVCNFSM6AAAAABBTJTSFWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZTGA4DOMRRGM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Thanks. I'm not familiar with the Lattice toolchain, but this looks suspect in the ulx3s Makefile: Shouldn't that width be 5? Also, it looks like top.v in the ulx3s board directory hasn't been updated to match the new usb_hid_host module interface. What I don't get is that without fixing up top.v to match the new usb_hid_host interface, it shouldn't even synthesize. The port names have changed. Anyway, if it helps, I can make a best-effort modification of the ulx3s top.v, but I won't be able to test since I don't have that board. |
|
for ECP5 width should actually be 8 (divisible by 4) although only 5
actually in use. Width divisible by 4 allows
quick recompile of the ukp firmware and patching new rom in
already built bitstream without waiting for full FPGA synthesis
my project is here I got everything to compile but not to enumerate
no LEDs light up, no reports printed on serial. Only reset btn works
https://github.com/emard/usb_hid_host/blob/main/boards/ulx3s/top.v
…On Wed, Apr 3, 2024 at 12:58 AM Epsilon ***@***.***> wrote:
Thanks. I'm not familiar with the Lattice toolchain, but this looks
suspect in the ulx3s Makefile:
ecpbram --width 4 --depth $(ROMDEPTH512) --seed 0 --generate $(SRC)/usb_hid_host_rom_random_new.hex
Shouldn't that width be 5?
Also, it looks like top.v in the ulx3s board directory hasn't been updated
to match the new usb_hid_host module interface.
Aside from the additional inputs and outputs for led control, I also split
the usb inouts into separate inputs, outputs, and an output enable. That
makes it easier to use the core in Verilator.
(In my fork of the repo, I haven't modified any of the board files. I just
pull in the repo as a submodule and synthesize only the usb_hid_host core
into my own design, BoxLambda).
What I don't get is that without fixing up top.v to match the new
usb_hid_host interface, it shouldn't even synthesize. The port names have
changed.
Anyway, if it helps, I can make a best-effort modification of the ulx3s
top.v, but I won't be able to test since I don't have that board.
—
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC4K2RZ4WTEJO2JV3Z7YKA3Y3MZ2FAVCNFSM6AAAAABBTJTSFWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZTGI2TCNBWGY>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
OK, so then width should be set to 8 in your Makefile, not 4. |
|
I haven't yet installed led updater module I thought kbd
would enumerate without it but maybe I should add this
module...
…On Thu, Apr 4, 2024 at 2:21 PM Epsilon ***@***.***> wrote:
OK, so then width should be set to 8 in your Makefile, not 4.
In your top.v, where you instantiated usb_hid_host, can you add
.update_leds_stb(1'b0) to the port list?
—
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC4K2RYYW3DBSHVO2DBEWBDY3VAT7AVCNFSM6AAAAABBTJTSFWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZXGA2DANJXGE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
I don't think we're on the same page. What do you mean with the led updater module? There's no separate module, just a bit of extra logic in the usb_hid_host_core and the ukp module, and a bit of extra code in the ukp firmware. I don't know if verilog, or your toolchain, has a concept of a default value for input ports that are left unspecified. I think it's best to be explicit and specify a value (or wire) for all input ports when you instantiate the usb_hid_host core in top.v. If we were in the same room we probably would have sorted this out in 5 minutes, but as it is (and with me severly jetlagged) it'll take a bit longer for us to understand each other. |
|
ok I will set all floating inputs to 0
yosys does them slightly random if unspecified.
popular non-free compiles usually set to 0 unspec ports
…On Thu, Apr 4, 2024 at 4:36 PM Epsilon ***@***.***> wrote:
I don't think we're on the same page. What do you mean with the led
updater module? There's no separate module, just a bit of extra logic in
the usb_hid_host_core and the ukp module, and a bit of extra code in the
ukp firmware.
I don't know if verilog, or your toolchain, has a concept of a default
value for input ports that are left unspecified. I think it's best to be
explicit and specify a value (or wire) for all input ports when you
instantiate the usb_hid_host core in top.v.
If we were in the same room we probably would have sorted this out in 5
minutes, but as it is (and with me severly jetlagged) it'll take a bit
longer for us to understand each other.
—
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC4K2RZ5KMRZSZICM3WZMZLY3VQNRAVCNFSM6AAAAABBTJTSFWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZXGM4TANZUGE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
https://github.com/emard/usb_hid_host/blob/main/boards/ulx3s/top.v
this is how I connected BTNs to LED control inputs
but still I don't get enumeration no LEDs on FPGA turned
on, no serial messages printed when I plug KBD
…On Thu, Apr 4, 2024 at 5:20 PM D EMARD ***@***.***> wrote:
ok I will set all floating inputs to 0
yosys does them slightly random if unspecified.
popular non-free compiles usually set to 0 unspec ports
On Thu, Apr 4, 2024 at 4:36 PM Epsilon ***@***.***> wrote:
> I don't think we're on the same page. What do you mean with the led
> updater module? There's no separate module, just a bit of extra logic in
> the usb_hid_host_core and the ukp module, and a bit of extra code in the
> ukp firmware.
>
> I don't know if verilog, or your toolchain, has a concept of a default
> value for input ports that are left unspecified. I think it's best to be
> explicit and specify a value (or wire) for all input ports when you
> instantiate the usb_hid_host core in top.v.
>
> If we were in the same room we probably would have sorted this out in 5
> minutes, but as it is (and with me severly jetlagged) it'll take a bit
> longer for us to understand each other.
>
> —
> Reply to this email directly, view it on GitHub
> <#6 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AC4K2RZ5KMRZSZICM3WZMZLY3VQNRAVCNFSM6AAAAABBTJTSFWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZXGM4TANZUGE>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
|
|
git checkout 461d782 -- src/usb_hid_host.v
git checkout 461d782 --
src/usb_hid_host/ukp.s
after this revert enumeration works (with old top.v too)
so I can verify that 8-bit ROM works when its lower 4-bits are used in the
code
and new asukp is good to compile old code ukp.s
…On Thu, Apr 4, 2024 at 7:32 PM D EMARD ***@***.***> wrote:
https://github.com/emard/usb_hid_host/blob/main/boards/ulx3s/top.v
this is how I connected BTNs to LED control inputs
but still I don't get enumeration no LEDs on FPGA turned
on, no serial messages printed when I plug KBD
On Thu, Apr 4, 2024 at 5:20 PM D EMARD ***@***.***> wrote:
> ok I will set all floating inputs to 0
>
> yosys does them slightly random if unspecified.
> popular non-free compiles usually set to 0 unspec ports
>
>
>
> On Thu, Apr 4, 2024 at 4:36 PM Epsilon ***@***.***> wrote:
>
>> I don't think we're on the same page. What do you mean with the led
>> updater module? There's no separate module, just a bit of extra logic in
>> the usb_hid_host_core and the ukp module, and a bit of extra code in the
>> ukp firmware.
>>
>> I don't know if verilog, or your toolchain, has a concept of a default
>> value for input ports that are left unspecified. I think it's best to be
>> explicit and specify a value (or wire) for all input ports when you
>> instantiate the usb_hid_host core in top.v.
>>
>> If we were in the same room we probably would have sorted this out in 5
>> minutes, but as it is (and with me severly jetlagged) it'll take a bit
>> longer for us to understand each other.
>>
>> —
>> Reply to this email directly, view it on GitHub
>> <#6 (comment)>,
>> or unsubscribe
>> <https://github.com/notifications/unsubscribe-auth/AC4K2RZ5KMRZSZICM3WZMZLY3VQNRAVCNFSM6AAAAABBTJTSFWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZXGM4TANZUGE>
>> .
>> You are receiving this because you commented.Message ID:
>> ***@***.***>
>>
>
|
|
In the version before you reverted you had ".update_leds_stb(btn[2])" in your top.v. Another good test would be to see if enumeration works with the new usb_hid_host core running the old ukp.s firmware compiled with the new asukp. |
|
btn [1..6] logic is normal, 0 idle, 1 pressed.
with new code enumeration doesn't work therefore
there is no chance for LEDs yet
In the previous message I reverted commits before LED
support and I verified that old ukp.s firmware compiles
and works with new asukp and it still works when bram
width is extened from 4 to 8 bits and used with old
usb_hid_host.v which needs only 4 bits
…On Fri, Apr 5, 2024 at 1:39 AM Epsilon ***@***.***> wrote:
In the version before you reverted you had ".update_leds_stb(btn[2])" in
your top.v.
I don't know if btn[2] is active high or active low on your board. It
would be good to test with ".update_leds_stb(1'b0)".
A button there is no good anyway because the strobe should only be
asserted for one clock cycle when you want to update the leds.
Another good test would be to see if enumeration works with the new
usb_hid_host core running the old ukp.s firmware compiled with the new
asukp.
—
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC4K2R6KZUZ57KIOEWOKBWLY3XQBNAVCNFSM6AAAAABBTJTSFWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZYGQ2TCMZRGM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
I also tried old ukp.s with new usb_hid_host.v
but this combination doesn't work
should it work?
I know correct place for 3-state logic is in toplevel
and outside of usb_hid_host.v but this design works
and yosys has limited (buggy?) support for 3-state
anyway so it's not good idea to touch something that
works...
…On Fri, Apr 5, 2024 at 8:14 AM D EMARD ***@***.***> wrote:
btn [1..6] logic is normal, 0 idle, 1 pressed.
with new code enumeration doesn't work therefore
there is no chance for LEDs yet
In the previous message I reverted commits before LED
support and I verified that old ukp.s firmware compiles
and works with new asukp and it still works when bram
width is extened from 4 to 8 bits and used with old
usb_hid_host.v which needs only 4 bits
On Fri, Apr 5, 2024 at 1:39 AM Epsilon ***@***.***> wrote:
> In the version before you reverted you had ".update_leds_stb(btn[2])" in
> your top.v.
> I don't know if btn[2] is active high or active low on your board. It
> would be good to test with ".update_leds_stb(1'b0)".
> A button there is no good anyway because the strobe should only be
> asserted for one clock cycle when you want to update the leds.
>
> Another good test would be to see if enumeration works with the new
> usb_hid_host core running the old ukp.s firmware compiled with the new
> asukp.
>
> —
> Reply to this email directly, view it on GitHub
> <#6 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AC4K2R6KZUZ57KIOEWOKBWLY3XQBNAVCNFSM6AAAAABBTJTSFWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZYGQ2TCMZRGM>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
|
|
I found an error in your top.v (before you reverted) that would explain why enumeration isn't working: That last one should be .usb_dp_o(usb_dp_o). |
|
aieeeeeeeeeeeeeeeeeeee grrr my typo
will check
…On Fri, Apr 5, 2024 at 1:37 PM Epsilon ***@***.***> wrote:
I found an error in your top.v (before you reverted) that would explain
why enumeration isn't working:
.usb_dm_i(usb_dm_i), .usb_dp_i(usb_dp_i),
.usb_dm_o(usb_dm_o), .usb_dp_i(usb_dp_o),
That last one should be .usb_dp_o(usb_dp_o).
—
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC4K2R6ISCFALBESFSGZPTLY32EGDAVCNFSM6AAAAABBTJTSFWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZZGU4DAMRTGU>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
I tried to fix this ugly typo but still it doesn't help
.usb_oe(usb_oe),
.usb_dm_i(usb_dm_i), .usb_dp_i(usb_dp_i),
.usb_dm_o(usb_dm_o), .usb_dp_o(usb_dp_o),
assign usb_dm_i = usb_fpga_bd_dn;
assign usb_dp_i = usb_fpga_bd_dp;
assign usb_fpga_bd_dn = usb_oe ? usb_dm_o : 1'bZ;
assign usb_fpga_bd_dp = usb_oe ? usb_dp_o : 1'bZ;
no enumeration
I reverted only firmware ukp.s still no enumeration
only when I revert both ukp.s and usb_hid_host.v
and top then I get enumeration
…On Fri, Apr 5, 2024 at 3:53 PM D EMARD ***@***.***> wrote:
aieeeeeeeeeeeeeeeeeeee grrr my typo
will check
On Fri, Apr 5, 2024 at 1:37 PM Epsilon ***@***.***> wrote:
> I found an error in your top.v (before you reverted) that would explain
> why enumeration isn't working:
>
> .usb_dm_i(usb_dm_i), .usb_dp_i(usb_dp_i),
> .usb_dm_o(usb_dm_o), .usb_dp_i(usb_dp_o),
>
> That last one should be .usb_dp_o(usb_dp_o).
>
> —
> Reply to this email directly, view it on GitHub
> <#6 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AC4K2R6ISCFALBESFSGZPTLY32EGDAVCNFSM6AAAAABBTJTSFWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZZGU4DAMRTGU>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
|
|
HI additionally I found that I have to revert asukp too,
now asukp doesn't produce correct code for old ukp.s
…On Fri, Apr 5, 2024 at 6:31 PM D EMARD ***@***.***> wrote:
I tried to fix this ugly typo but still it doesn't help
.usb_oe(usb_oe),
.usb_dm_i(usb_dm_i), .usb_dp_i(usb_dp_i),
.usb_dm_o(usb_dm_o), .usb_dp_o(usb_dp_o),
assign usb_dm_i = usb_fpga_bd_dn;
assign usb_dp_i = usb_fpga_bd_dp;
assign usb_fpga_bd_dn = usb_oe ? usb_dm_o : 1'bZ;
assign usb_fpga_bd_dp = usb_oe ? usb_dp_o : 1'bZ;
no enumeration
I reverted only firmware ukp.s still no enumeration
only when I revert both ukp.s and usb_hid_host.v
and top then I get enumeration
On Fri, Apr 5, 2024 at 3:53 PM D EMARD ***@***.***> wrote:
> aieeeeeeeeeeeeeeeeeeee grrr my typo
> will check
>
> On Fri, Apr 5, 2024 at 1:37 PM Epsilon ***@***.***> wrote:
>
>> I found an error in your top.v (before you reverted) that would explain
>> why enumeration isn't working:
>>
>> .usb_dm_i(usb_dm_i), .usb_dp_i(usb_dp_i),
>> .usb_dm_o(usb_dm_o), .usb_dp_i(usb_dp_o),
>>
>> That last one should be .usb_dp_o(usb_dp_o).
>>
>> —
>> Reply to this email directly, view it on GitHub
>> <#6 (comment)>,
>> or unsubscribe
>> <https://github.com/notifications/unsubscribe-auth/AC4K2R6ISCFALBESFSGZPTLY32EGDAVCNFSM6AAAAABBTJTSFWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZZGU4DAMRTGU>
>> .
>> You are receiving this because you commented.Message ID:
>> ***@***.***>
>>
>
|
|
In your 'typo but it doesn't help' commit you only changed one statement between comments. I assume this is not what you actually tested. |
|
no problem, I will push what I have tried
later can I clean my fork, now lets experiment
…On Sat, Apr 6, 2024 at 12:55 PM Epsilon ***@***.***> wrote:
In your 'typo but it doesn't help' commit you only changed one statement
between comments. I assume this is not what you actually tested.
Can you check in the code that you tested (i.e. with the fix but still not
working) and push to Github? If you don't want to commit to main branch,
maybe create a separate branch?
—
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC4K2R76D5C5PCEN4NR4C7TY37ICXAVCNFSM6AAAAABBTJTSFWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBRGA2DONJVHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
I pushed on my git code that I'm trying to get work
board is ulx3s 12f, toplevel is there
if I press btn[1] as reset, onboard led[3] turns on
wheile I hold reset
tried resetting and replugging kbd mouse gamepad, nothing
no other onboard leds light, they should turn on
and one should blink after successful enumeration
…On Sat, Apr 6, 2024 at 2:36 PM D EMARD ***@***.***> wrote:
no problem, I will push what I have tried
later can I clean my fork, now lets experiment
On Sat, Apr 6, 2024 at 12:55 PM Epsilon ***@***.***> wrote:
> In your 'typo but it doesn't help' commit you only changed one statement
> between comments. I assume this is not what you actually tested.
> Can you check in the code that you tested (i.e. with the fix but still
> not working) and push to Github? If you don't want to commit to main
> branch, maybe create a separate branch?
>
> —
> Reply to this email directly, view it on GitHub
> <#6 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AC4K2R76D5C5PCEN4NR4C7TY37ICXAVCNFSM6AAAAABBTJTSFWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBRGA2DONJVHA>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
|
|
I would be a bit more comfortable if in askup, you change this line: \talways @(posedge clk) data <= mem[adr]; to: \talways @(posedge clk) data <= mem[adr][4:0]; Nothing else is catching my eye at the moment. |
|
In my project, there's an explicit power-on-reset phase. In your project there isn't which means that the initial values in usb_hid_host.v are more important. |
|
I did this in the source and commited
still no enumeration
…On Sat, Apr 6, 2024 at 4:29 PM Epsilon ***@***.***> wrote:
I would be a bit more comfortable if in askup, you change this line:
\talways @(posedge clk) data <= mem[adr];
to:
\talways @(posedge clk) data <= mem[adr][4:0];
Nothing else is catching my eye at the moment.
—
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC4K2RYV6RHLZSBQHWTHTLLY4ABDVAVCNFSM6AAAAABBTJTSFWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBRGEYDIOBQGI>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
yes I always try pressing btn[1] (reset) many times,
replug usb few times, unplug fpga board and replug
still no enumeration
…On Sat, Apr 6, 2024 at 5:00 PM D EMARD ***@***.***> wrote:
I did this in the source and commited
still no enumeration
On Sat, Apr 6, 2024 at 4:29 PM Epsilon ***@***.***> wrote:
> I would be a bit more comfortable if in askup, you change this line:
>
> \talways @(posedge clk) data <= mem[adr];
>
> to:
>
> \talways @(posedge clk) data <= mem[adr][4:0];
>
> Nothing else is catching my eye at the moment.
>
> —
> Reply to this email directly, view it on GitHub
> <#6 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AC4K2RYV6RHLZSBQHWTHTLLY4ABDVAVCNFSM6AAAAABBTJTSFWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBRGEYDIOBQGI>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
|
|
I reviewed my usb_hid_host.v changes and noticed a coupled of things I don't like. I'll correct them and get back to you. |
|
I checked in my changes. I made sure ukp initial state is same as after reset. Please give it a try. |
|
HI
I copied usb_hid_host.v from your repository
but it still doesn't enumerate
tried resetting and replugging kbd muse joystick
…On Mon, Apr 8, 2024 at 10:51 AM Epsilon ***@***.***> wrote:
I checked in my changes. I made sure ukp initial state is same as after
reset. Please give it a try.
—
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC4K2RZHRQFY2AUOJ33JLHDY4JLCZAVCNFSM6AAAAABBTJTSFWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBSGIYDQNBTGQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Bummer. I have spent a fair amount of time looking at my code, your code, synthesis results, and will continue to do so, but at the moment, I'm not seeing it. My go-to to dig deeper is simulation, but my simulation test bench is just working fine. |
|
i guess the easiest would be if you can obtain
some ulx3s or similar ecp5 board and check it
for yourself
one day I'm planning to get again to compile
hdl4fpga project (may need a longer time)
This project has a simple scope "scopeio"
It has fast hdmi graphics and mouse support
and has no CPU not even a simple ukp-alike.
scopeio can show USB traces
…On Mon, Apr 8, 2024 at 10:13 PM Epsilon ***@***.***> wrote:
Bummer. I have spent a fair amount of time looking at my code, your code,
synthesis results, and will continue to do so, but at the moment, I'm not
seeing it. My go-to to dig deeper is simulation, but my simulation test
bench is just working fine.
We may have to move on to an on-FPGA debug session. Is an embedded logic
analyzer an option for you? I would love to see a trace of the ukp_prom
input (adr/pc) and output (data/inst).
—
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC4K2RY7TSM274X72UDL4TDY4L253AVCNFSM6AAAAABBTJTSFWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBTGU3DAOJSGM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
I wonder if the issue is with the inference of the tristate logic. //-- Generic InOut //-- Configuration as input: //-- Configuration as output i.e. the if oe then-else should be applied to both the input and the output direction. |
|
https://github.com/emard/usb_hid_host/blob/7244301a92171f848d78723497f99af542f179d4/boards/ulx3s/top.v#L90
I applied something like this recommendation,
although no enumeration yet
yosys 3-state is somehow buggy although the old
style where usb_oe is applied only to output works
for other similar usb cores like this
https://github.com/emard/ulx3s-misc/blob/7acedaae0f52e17def1d76f561eecf98f108b012/examples/usb/usbhost/usbh_host_hid.v#L154
Core is somehow larger and no small CPU (it would be smaller then)
but It is 100% reliable with replugging. Other cores are smaller but
replugging
is successful in 90-95% cases
https://github.com/emard/usb_host riscv mcu C-compiled, supports usb hub
but too much BRAM
https://github.com/emard/usb_hid_host ukp spec assembly, very small
…On Tue, Apr 9, 2024 at 1:46 PM Epsilon ***@***.***> wrote:
I wonder if the issue is with the inference of the tristate logic.
According to this doc: https://github.com/FPGAwars/iceIO/wiki
this how the verilog should be written:
//-- Generic InOut
//-- Number of data bits
localparam N = 1;
//-- Configuration as input:
//---- Read from pin --> din
assign din = oe ? {N{1'b0}} : pin;
//-- Configuration as output
//-- din is always 0!
//-- dout --> pin
assign pin = oe ? dout : {N{1'bZ}};
i.e. the if oe then-else should be applied to both the input and the
output direction.
—
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC4K2R7YMRUNTGP5XCSGIQ3Y4PIH3AVCNFSM6AAAAABBTJTSFWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBUHEYDEOBYGM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm testing this core with a USB keyboard. It's working great! I was wondering if you're considering adding support for sending reports to the keyboard to set the num_lock/caps_lock/... LEDs.
The text was updated successfully, but these errors were encountered: