TF Riser Revision 0 Arrives
Moderators: terriblefire, Terriblefire Moderator
-
terriblefire
- Admin sponsor

- Posts: 5686
- Joined: 28 Aug 2017 22:56
- Location: Glasgow, UK
Re: TF Riser Revision 0 Arrives
Just FYI.. RS despatch most stock from Glasgow.. so you get it v quickly.
I dont have to pay postage as I have a commercial account.
I dont have to pay postage as I have a commercial account.
———
"It is not necessarily a supply voltage at no load, but the amount of current it can provide when touched that
indicates how much hurting you shall receive."
"It is not necessarily a supply voltage at no load, but the amount of current it can provide when touched that
indicates how much hurting you shall receive."
-
arkadiusz.makarenko
- Moderator Team

- Posts: 1371
- Joined: 19 Jun 2019 07:36
- Location: Edinburgh
Re: TF Riser Revision 0 Arrives
Ok Small update on progress of supporting gamepads/usb joysticks.
After full week of banging my head in USB protocol and stm32 USB host library at last I managed to read values from gamepad!
At this point it is dev f407 board, but library is shared so porting this to either f105 or f730 is 10 minutes.
Mappings and support of different pads. This most likekly will be unfortunately manual process.
A lot of them are XBOX360 compatible, so I think I will only focus on few the most common with ability of updating in the future (this will need firmware update, and we don't have easy way of doing it just now (yet).
Composite devices. At this point what I understand any of them will not work out of the box. For each one there will be need of writing driver.
Issue is that at this point firmware read only report for when report id is not specified. each report with different id need to be separately mapped and provide means to be read.
Unless there is a standard (which I really don't think it is) then it may happen only for literally few devices which I must have access to (without guarantee that it actually will work)
Issues with Rev0 hardware. I think my stm32 chip is a little bit fragile as it started to misbehave today a lot. Mainly on usb connect/disconnect and few other situations. I think I need to work on my soldering skills as at this point I managed to kill 2 MPUs one is on its way. Definitely they are not that robust as clpds.
EDIT.
Few additional caps, new cables and move to linux for developement did solve all my hardware and unspecific issues. Reading data from gamepad now work on Riser with f730 chip.
After full week of banging my head in USB protocol and stm32 USB host library at last I managed to read values from gamepad!
At this point it is dev f407 board, but library is shared so porting this to either f105 or f730 is 10 minutes.
Mappings and support of different pads. This most likekly will be unfortunately manual process.
A lot of them are XBOX360 compatible, so I think I will only focus on few the most common with ability of updating in the future (this will need firmware update, and we don't have easy way of doing it just now (yet).
Composite devices. At this point what I understand any of them will not work out of the box. For each one there will be need of writing driver.
Issue is that at this point firmware read only report for when report id is not specified. each report with different id need to be separately mapped and provide means to be read.
Unless there is a standard (which I really don't think it is) then it may happen only for literally few devices which I must have access to (without guarantee that it actually will work)
Issues with Rev0 hardware. I think my stm32 chip is a little bit fragile as it started to misbehave today a lot. Mainly on usb connect/disconnect and few other situations. I think I need to work on my soldering skills as at this point I managed to kill 2 MPUs one is on its way. Definitely they are not that robust as clpds.
EDIT.
Few additional caps, new cables and move to linux for developement did solve all my hardware and unspecific issues. Reading data from gamepad now work on Riser with f730 chip.
Do not trust people. They are capable of greatness.
~ Stanislaw Lem
~ Stanislaw Lem
-
sampedenawa
- Posts: 29
- Joined: 14 Mar 2019 16:22
Re: TF Riser Revision 0 Arrives
Handling composite devices is not so difficult as it seems at first glance ... the trick is (at least, "my trick is") to get the "report id" you are interested in by looking at InterfaceSubClass and InterfaceProtocol parameters, to match the device you are interested in (keyb, mouse or joypad/controller, etc).
Then, save the reportID value you looked at, and filter all incoming reports from the peripheral against that value, discarding the rest.
This way you can write a general driver, which works with all standard HID compliant composite devices (there are a lot of them ... I even found a Logitech Gaming Mouse which declares itself as a composite mouse+pad+keyboard ....)
With regard to XBOX 360 compatible devices: be warned that they don't supply/send a report descriptor (so you have to code it manually), but fortunately their data report is always a fixed length (20 bytes), so decoding is quite simple, though it can't be of general use for other standard HID devices
Then, save the reportID value you looked at, and filter all incoming reports from the peripheral against that value, discarding the rest.
This way you can write a general driver, which works with all standard HID compliant composite devices (there are a lot of them ... I even found a Logitech Gaming Mouse which declares itself as a composite mouse+pad+keyboard ....)
With regard to XBOX 360 compatible devices: be warned that they don't supply/send a report descriptor (so you have to code it manually), but fortunately their data report is always a fixed length (20 bytes), so decoding is quite simple, though it can't be of general use for other standard HID devices
-
arkadiusz.makarenko
- Moderator Team

- Posts: 1371
- Joined: 19 Jun 2019 07:36
- Location: Edinburgh
Re: TF Riser Revision 0 Arrives
Thank you for suggestions.sampedenawa wrote: 21 Feb 2020 07:47 Handling composite devices is not so difficult as it seems at first glance ... the trick is (at least, "my trick is") to get the "report id" you are interested in by looking at InterfaceSubClass and InterfaceProtocol parameters, to match the device you are interested in (keyb, mouse or joypad/controller, etc).
Then, save the reportID value you looked at, and filter all incoming reports from the peripheral against that value, discarding the rest.
This way you can write a general driver, which works with all standard HID compliant composite devices (there are a lot of them ... I even found a Logitech Gaming Mouse which declares itself as a composite mouse+pad+keyboard ....)
With regard to XBOX 360 compatible devices: be warned that they don't supply/send a report descriptor (so you have to code it manually), but fortunately their data report is always a fixed length (20 bytes), so decoding is quite simple, though it can't be of general use for other standard HID devices
With composite devices in out use case I would need to parse report descriptor, then based on USAGE map report id to particular use and map it to output.
We would need to be able to decode all report ids,as we need to support both keyboard and mouse from composite device. After sleeping with it I can say it is doable, but I need to write at least partial report descriptor parser.
I think I need to write priority list as there is so many things to do for this firmware!
Do not trust people. They are capable of greatness.
~ Stanislaw Lem
~ Stanislaw Lem
-
terriblefire
- Admin sponsor

- Posts: 5686
- Joined: 28 Aug 2017 22:56
- Location: Glasgow, UK
Re: TF Riser Revision 0 Arrives
Its possible that i've undercooked the caps on the riser board. I'll add more next time. Also the cheap cheap regulators are utter crap. I always get a slightly more expensive one to put on there (RS/Mouser/Digikey). I never use an Ebay/UTSource regulator (again)
So can you explain what you have working so far? Serial output to the amiga?
So can you explain what you have working so far? Serial output to the amiga?
———
"It is not necessarily a supply voltage at no load, but the amount of current it can provide when touched that
indicates how much hurting you shall receive."
"It is not necessarily a supply voltage at no load, but the amount of current it can provide when touched that
indicates how much hurting you shall receive."
-
arkadiusz.makarenko
- Moderator Team

- Posts: 1371
- Joined: 19 Jun 2019 07:36
- Location: Edinburgh
Re: TF Riser Revision 0 Arrives
I didn't get that far yet, but I am not that far either.terriblefire wrote: 21 Feb 2020 15:25 Its possible that i've undercooked the caps on the riser board. I'll add more next time. Also the cheap cheap regulators are utter crap. I always get a slightly more expensive one to put on there (RS/Mouser/Digikey). I never use an Ebay/UTSource regulator (again)
So can you explain what you have working so far? Serial output to the amiga?
I have expanded USB library to support other kind of devices not only mouse and keyboard in boot mode. I can read game pads and usb joysticks.
Now I am looking at supporting (at least partially) composite devices and merging with your firmware.
Do not trust people. They are capable of greatness.
~ Stanislaw Lem
~ Stanislaw Lem
-
terriblefire
- Admin sponsor

- Posts: 5686
- Joined: 28 Aug 2017 22:56
- Location: Glasgow, UK
Re: TF Riser Revision 0 Arrives
arkadiusz.makarenko wrote: 21 Feb 2020 16:12 I didn't get that far yet, but I am not that far either.
I have expanded USB library to support other kind of devices not only mouse and keyboard in boot mode. I can read game pads and usb joysticks.
Now I am looking at supporting (at least partially) composite devices and merging with your firmware.
I guess i'm asking how you're seeing that your code is working? Serial output?
———
"It is not necessarily a supply voltage at no load, but the amount of current it can provide when touched that
indicates how much hurting you shall receive."
"It is not necessarily a supply voltage at no load, but the amount of current it can provide when touched that
indicates how much hurting you shall receive."
-
arkadiusz.makarenko
- Moderator Team

- Posts: 1371
- Joined: 19 Jun 2019 07:36
- Location: Edinburgh
Re: TF Riser Revision 0 Arrives
Debugger.terriblefire wrote: 21 Feb 2020 17:11arkadiusz.makarenko wrote: 21 Feb 2020 16:12 I didn't get that far yet, but I am not that far either.
I have expanded USB library to support other kind of devices not only mouse and keyboard in boot mode. I can read game pads and usb joysticks.
Now I am looking at supporting (at least partially) composite devices and merging with your firmware.
I guess i'm asking how you're seeing that your code is working? Serial output?
Do not trust people. They are capable of greatness.
~ Stanislaw Lem
~ Stanislaw Lem
-
arkadiusz.makarenko
- Moderator Team

- Posts: 1371
- Joined: 19 Jun 2019 07:36
- Location: Edinburgh
Re: TF Riser Revision 0 Arrives
I merged projects. And ported it to f730. It does compile and runs in debugger.
I can see that main() works as expected. I updated led pin to output to led on the board ( different pin on port. Difference on f105 and f730)
I had some issue with programming xillinx chip. It was saying that on verification once cell was being still deleted. After another attempt It did go through ok.
Now I am not sure if I did something really bad at the first power on (like reversing power polarity), that it killed first f105 and cpld chip.
I can see that main() works as expected. I updated led pin to output to led on the board ( different pin on port. Difference on f105 and f730)
I had some issue with programming xillinx chip. It was saying that on verification once cell was being still deleted. After another attempt It did go through ok.
Now I am not sure if I did something really bad at the first power on (like reversing power polarity), that it killed first f105 and cpld chip.
Do not trust people. They are capable of greatness.
~ Stanislaw Lem
~ Stanislaw Lem
-
terriblefire
- Admin sponsor

- Posts: 5686
- Joined: 28 Aug 2017 22:56
- Location: Glasgow, UK
Re: TF Riser Revision 0 Arrives
The Xilinx chips are hard to kill. Can you ID it?
———
"It is not necessarily a supply voltage at no load, but the amount of current it can provide when touched that
indicates how much hurting you shall receive."
"It is not necessarily a supply voltage at no load, but the amount of current it can provide when touched that
indicates how much hurting you shall receive."
Who is online
Users browsing this forum: ClaudeBot and 2 guests