That's interesting/good to know. In that case, perhaps that keyboard might work with the P2 if garryj is able to (make time to) get the hub-compatible version fully working. I presume that one would hook up a hub (such as a four-port hub) to one instance of such a driver through one port. That presumably would take one cog and just two or three pins (I would assume three pins, including an Event Repository pin, unless garryj says otherwise). But that's down the road, if it happens at all (it's apparently quite tricky to integrate the low-speed stuff with the more straightforward high-speed stuff, I believe garryj said).
Personally, I'd be thrilled with a non-hub version that could talk to multiple physical ports using just a single cog, with each physical port taking two or three pins, of course. But I have no real idea if that is possible. I believe that garryj has said that the current driver needs a minimum clock of somewhere between 80-95 MHz to work with full-speed stuff. Meeting the timing requirements seems to be the limiting factor. But if such a version were possible, it would be quite useful and avoid needing to dangle a hub off of a port. If cog or lut memory were tight, I'd be happy with just a keyboard- or mouse-only version of such a driver. But again, I have no idea if it is possible. Hmm, on second thought, I'm pretty sure that it must be "impossible."
@Cluso99, thanks! I do recall that somewhere you mentioned placing vsync on the pin just below hsync. I'm glad that we can do this, but if I do another version of my current board, I think I'll place vsync after the red signal and also start my hsync on pin 0 of an eight-pin group instead of pin 4, as that appears to be more "standard" with what others are doing here and will save me from having to edit other people's code (even though such edits are straightforward). Plus, I always worry that someone will write a driver that requires the pins to be in a specific order in terms of vsync (of course, hsync and blue, green and red are already in a "standardized" order). That's less likely to happen for VGA, though, as there are "only" four DAC's for a cog, so the slower vsync signal has to be handled by an ordinary pin on either side elsewhere, I meant, of a four-pin group, which would "naturally" place it just above (or just below) the four DAC-driven signals. Also, if anyone else used my board, they also wouldn't have to modify any code. I guess you could call it "going with the flow." Anyway, as I mentioned, I'm happy that garryj's USB pin usage can tuck right in beside the VGA signals. That worked out just fine. Edit: Initially, I psychologically liked keeping hsync and vsync together, but that doesn't really matter. Well, it could from a routing standpoint, I suppose, but it didn't matter in my case.
@JRetSapDoog You can always try to use 4 pin VGA to help save a pin. eg. Composite H+V syncs on the one pin (75ohm), my video driver supports this as well as a Sync-on-Green mode with 3 VGA pins. Many monitors support these too although 5 pin VGA is of course more universal (RGBHV). Plus with the P2 the VSync output can be located on any pin, nothing special about it. In general it's best to have HSync on the base pin of each nibble so the P2's internal colourspace HW can utilize it, though if you write your own custom driver it's likely possible to bit bang it elsewhere as well (with extra care to keep synced to the streamer if that is used).
@Clusso99, by the way, I'm sure that you know that in garryj's latest version of his driver, he has the LED status pin using the same pin that serves as an Event Repository. So one kind of gets the LED status functionality at no additional cost, as it used to be on a separate pin, at least if I've followed his comments and this thread correctly. But I haven't yet hooked up an LED and resistor yet to watch it show the status. Maybe I should just to confirm that it works. Anyway, are you saying that, just as garryj sort of double uses the pin (the smart pin half and the physical pin half) to do both event storage and driving the LED, that the LED functionality could be sacrificed and the physical pin used for other things if the associated code driving the LED was ripped out (while still retaining the Event Repository functionality)? Is that what you did/mean? If so, that could come in handy.
@rogloh, thanks for that info. Those are a couple of possibilities. Quite a while back, I did locate a very long datasheet for the chip that the driver board in my setup uses. And I seem to recall it mentioning something about sync-on-green (SoG), but I don't think I ever fully understood it and the size of that data sheet unnerved me (I think that it was at least a hundred pages with a ton of setup registers, etc.). Edit: The firmware of the chip is actually alterable if one has the right software tool. Another thing that dissuaded me was that using such functionality might make it more troublesome for me (or possibly someone else) to use other people's drivers.
About the h, b, g, r pin order, I believe that it was you that originally explained the colourspace advantages of this "standardized" order to me (and pointed out that this order was the one that Chip was using). Thanks so much. And while it may be possible to alter that order (if not using the colourspace HW, I suppose), I don't think a person at my low "pay grade" should do so. I already tend to make things "funky" enough as it is. Nevertheless, I'll keep it (and especially composite sync and SoG) in the back of my mind (coz never say never), and it's really great that you were able to integrate that extra sync functionality into your amazingly versatile driver (which I routinely followed, even if much of it was over my head). You've got everything in there but the kitchen sink. Well, maybe that, too. I forget if you have mouse cursor capability in there, but I wouldn't be surprised. If so, maybe garryj's driver can be used to provide it with the x-y data through an intermediary. (And notice how I brought my comment back to USB stuff to keep it on topic? Well, I tried, anyway.)
@JRetSapDoog said:
I forget if you have mouse cursor capability in there, but I wouldn't be surprised. If so, maybe garryj's driver can be used to provide it with the x-y data through an intermediary. (And notice how I brought my comment back to USB stuff to keep it on topic? Well, I tried, anyway.)
Yes a USB mouse works nicely with the sprite cursor position in the driver. It's designed for that. A simple long update with X,Y values and it will follow the mouse co-ordinates, though it does need scaling to the graphics resolution. Just a few lines of SPIN2 or PASM, it's very simple and very responsive, as it is drawn directly into the line buffer for you.
@JRetSapDoog I also had trouble with that event pin stomping on something when not using the Parallax USB adapter...
I tweaked the Start() function a bit to stop that and also have it automatically update cursor position and key report like this:
PUB start(base_pin, enable_pin, dm_pin, err_led_pin) : cog
'RJA: Adding handling of mouse data to this driver
'RJA: Adding explicit enable pin that can be set to -1 to not use
'Setting pointers in assembly code before starting cog
pMouseX:=@mouseGunk
pMouseY:=@mouseGunk+4
pMouseMaxX:=@mouseGunk+8
pMouseMaxY:=@mouseGunk+12
pMouseButtons:=@mouseGunk+16
pKeyReport:= @pressedKeys
'Enable USB power, if enable_pin>0
if (enable_pin>0)
pinh(enable_pin)
So, you just set the enable_pin negative to not use it...
Hi, Rayman. Thanks for that comment. I like your tweaked start() method. Yeah, that's a better (long-term) solution than just commenting that functionality out. By "...trouble with that event pin stomping on something...," I assume that you mean the "enable pin" instead of the "event pin" (both words start with an 'e'). Unless I missed something, that matches what you wrote subsequently. Anyway, I think that your tweaked method would make using the driver somewhat easier for a more casual user to use (and everyone, really). And maybe garryj will incorporate something like that in a subsequent release.
As for how your accessing the mouse cursor coordinates and key states, I need to look at that further. But I think that I like the idea of putting such updating into the driver itself (with everything in one place). Currently, I'm using a modified version of one of garryj's demo programs as an intermediary between my top-level object and his USB driver. But why pay a middleman when you can buy direct from the factory? So I may change things later once I understand my options better. Thanks again for your comment.
Thanks for the comments and ideas, guys! I've been trying to focus on the hub-aware version, as I think it may offer the most bang for the buck, and should be much more friendly to two and three pin setups. The only hard rule is that the D- pin# must be an even numbered pin and the D+ pin# must be D- + 1.
When used as a host only, it should behave the same as the current single port version does, for low and full speed devices. If a hub is connected, it will initially support up to four ports. The first iteration will be limited to full-speed capable devices via hub, with (hopefully) low-speed devices via hub coming later.
As far as hubs go, USB 1.1 and 2.x versions work the best, but the two 3.x hubs I have are pretty finicky.
Wow, you actually have USB hub working? That's impressive. Still in just one cog?
Aren't most things full-speed at least now? I'm trying to remember what might be low speed only...
Yes, it would be really swell to have hub compatibility. About the number of cogs for a hub-capable USB host driver, the goal appears to be one cog. Gary has stated:
"A USB hub driver has been on my todo list for quite a while..... Since there shouldn't be any additional low-level buss signalling changes, I think the core code should still fit in one cog + lut exec, with the hub buss scheduler driver developed using C and/or spin." [thread pg. 1]
"I'm still (very slowly) working on a hub-capable version which works with one USB cog. The host is freed from some of the the device connect/disconnect load that is handled by the hub. I have full-speed boot protocol keyboard/mouse working fairly well with up to four ports. Low-speed devices via hub has been a tougher nut to crack...." [thread pg. 5]
I wonder how many keyboards and mice are full speed as opposed to low speed. On Wikipedia's entry on the old PS/2 port, I found this about mice sampling/polling: "Both PS/2 and USB allow the sample rate to be overridden, with PS/2 supporting a sampling rate of up to 200 Hz[2] and USB supporting a polling rate up to 1 kHz as long as the mouse runs at full-speed USB speeds or higher." (emphasis added) So, I'd imagine that gaming mice are full-speed devices, but don't know about regular mice (or keyboards).
Offhand, I forget if the current USB host driver provides a way to report whether a device is connected at LS or FS. I seem to recall something about the DM and DP lines being used differently depending on the device speed.
Thanks, evanh. So, including the combo device, that's one full-speed mouse and four low-speed mice, plus two low-speed keyboards. That's six out of seven devices that are low-speed ones. Following your lead, I tried checking the connection speeds of a keyboard and a couple of mice under the Device Manager of Windows 10, but I didn't see anything that told me the connection speed (1.5 or 12 Mb/s). Under Properties and Details and Properties again, there were several dozen little reports with various bits of info, but I didn't see anything that gave the connection speed. Maybe I missed it. Anyway, with so many keyboards and mice apparently being low speed (1.5 Mb/s) devices, it sounds like they wouldn't work with a hub-compatible P2 host driver that only worked with full-speed devices. Or am I missing something? But even if that's right, if such a driver does get released, perhaps a subsequent version could add support for low-speed devices. But we'll gladly and appreciatively take whatever we can get, of course.
@JRetSapDoog said:
Thanks, evanh. So, including the combo device, that's one full-speed mouse and four low-speed mice, plus two low-speed keyboards. That's six out of seven devices that are low-speed ones.
Err, I misled you a little it seems, my main keyboard is an old PS/2. The listed keyboard is the sole USB keyboard I have.
Following your lead, I tried checking the connection speeds of a keyboard and a couple of mice under the Device Manager of Windows 10, but I didn't see anything that told me the connection speed (1.5 or 12 Mb/s). Under Properties and Details and Properties again, there were several dozen little reports with various bits of info, but I didn't see anything that gave the connection speed. Maybe I missed it.
I'm using the KDE Info Centre that comes with the Kubuntu distro. It in turn will be probing the Linux /proc (or /sys I keep forgetting which) structures I presume.
Anyway, with so many keyboards and mice apparently being low speed (1.5 Mb/s) devices, it sounds like they wouldn't work with a hub-compatible P2 host driver that only worked with full-speed devices. Or am I missing something? But even if that's right, if such a driver does get released, perhaps a subsequent version could add support for low-speed devices. But we'll gladly and appreciatively take whatever we can get, of course.
I haven't been reading all that closely. But I have faith in Garry anyway.
Ah, sorry about that. Anyway, Garry has surprised himself, I think, by what's possible in/with one cog (with a competent and dedicated code warrior, I mean). One limiting factor, though, is finding the time. So we'll (and by "we'll" I mean "I'll) have to be patient.
For reference, here's a link to a Hackaday announcement about a project in which Dmitry Samsonov is doing a USB host that allows "for four USB 1.1 devices to be connected directly to the ESP32 without a separate dedicated chip." Don't know if he has implemented a hub or whether he can handle four separate ports with one instance (perhaps the latter from the picture?). Dmitry has responded to the announcement in the comments. Anyway, posting here for what it's worth.
Gary mentioned in the first post of this thread that " SmartSerial.spin and std_text_routines.spinh files that are packaged with Spin2gui." Where do I find the "Spin2gui"
Edit: what I really want to find is source for "printf"
Thanks,
Jim
I will have to set up a test to see if I bricked the pins. When I use the demo program, I have tried 3 different mice and the screen displays only the initialization data with no indicated failures. However, I do not see any output that would say that the mouse is being read. I am wondering if it has anything to do with the xtal and clock frequencies? I am using a Kiss eval board from ManatWork with a 25MHz xtal and a 200_000_000 MHz clock. I have made the changes in cons at the top of the file and with a 2_000_000 Baud clock I do see the serial printouts correctly. I use flexprop as my compiler and I am using base pin 16 with DM and DP on 22 and 23. Any suggestions? The Mice are 6~year old Radio Shack wireless and a new wired Ohn from Walmart. Also tried my 2 year old Logitec wireless all to no avail. Not super critical but I was experimenting with using an optical mouse as a way to get high rez position data off of a ball to use as a joystick.
Jim
EDIT correct pin numbers to 22 and 23 I guess I could not add when I posted this.
I believe I have seen cases where the 25 MHz xtal made some things not work.
But, if you got serial text to work, maybe you're OK.
Also, DM and DP have to be in a particular order, the driver file has a description of that.
But, just be sure to use the same order as in the examples.
Also, the pins have to be in pairs, that are next to each other. Don't think 23 & 24 will work.
What I have is basepin==16 and:
DM = USB_BASEPIN + 6 ' DM is "The Brain"
DP = USB_BASEPIN + 7 ' DP is passive
Has anyone had success with running this with a 200MHz clock? I was afraid that I had bricked io pins on one board so I set it up to run on my other board with exact same results. Using the test demo program it prints out the startup info and stops. I have tried three different mice. 2 wireless and 1 wired. I am not interested in the Keyboard, only the mouse data. Not sure where to go next unless I put debugging print statements throughout the code.
Jim
Comments
That's interesting/good to know. In that case, perhaps that keyboard might work with the P2 if garryj is able to (make time to) get the hub-compatible version fully working. I presume that one would hook up a hub (such as a four-port hub) to one instance of such a driver through one port. That presumably would take one cog and just two or three pins (I would assume three pins, including an Event Repository pin, unless garryj says otherwise). But that's down the road, if it happens at all (it's apparently quite tricky to integrate the low-speed stuff with the more straightforward high-speed stuff, I believe garryj said).
Personally, I'd be thrilled with a non-hub version that could talk to multiple physical ports using just a single cog, with each physical port taking two or three pins, of course. But I have no real idea if that is possible. I believe that garryj has said that the current driver needs a minimum clock of somewhere between 80-95 MHz to work with full-speed stuff. Meeting the timing requirements seems to be the limiting factor. But if such a version were possible, it would be quite useful and avoid needing to dangle a hub off of a port. If cog or lut memory were tight, I'd be happy with just a keyboard- or mouse-only version of such a driver. But again, I have no idea if it is possible. Hmm, on second thought, I'm pretty sure that it must be "impossible."
@Cluso99, thanks! I do recall that somewhere you mentioned placing vsync on the pin just below hsync. I'm glad that we can do this, but if I do another version of my current board, I think I'll place vsync after the red signal and also start my hsync on pin 0 of an eight-pin group instead of pin 4, as that appears to be more "standard" with what others are doing here and will save me from having to edit other people's code (even though such edits are straightforward). Plus, I always worry that someone will write a driver that requires the pins to be in a specific order in terms of vsync (of course, hsync and blue, green and red are already in a "standardized" order). That's less likely to happen for VGA, though, as there are "only" four DAC's for a cog, so the slower vsync signal has to be handled by an ordinary pin on either side elsewhere, I meant, of a four-pin group, which would "naturally" place it just above (or just below) the four DAC-driven signals. Also, if anyone else used my board, they also wouldn't have to modify any code. I guess you could call it "going with the flow." Anyway, as I mentioned, I'm happy that garryj's USB pin usage can tuck right in beside the VGA signals. That worked out just fine. Edit: Initially, I psychologically liked keeping hsync and vsync together, but that doesn't really matter. Well, it could from a routing standpoint, I suppose, but it didn't matter in my case.
@JRetSapDoog You can always try to use 4 pin VGA to help save a pin. eg. Composite H+V syncs on the one pin (75ohm), my video driver supports this as well as a Sync-on-Green mode with 3 VGA pins. Many monitors support these too although 5 pin VGA is of course more universal (RGBHV). Plus with the P2 the VSync output can be located on any pin, nothing special about it. In general it's best to have HSync on the base pin of each nibble so the P2's internal colourspace HW can utilize it, though if you write your own custom driver it's likely possible to bit bang it elsewhere as well (with extra care to keep synced to the streamer if that is used).
@Clusso99, by the way, I'm sure that you know that in garryj's latest version of his driver, he has the LED status pin using the same pin that serves as an Event Repository. So one kind of gets the LED status functionality at no additional cost, as it used to be on a separate pin, at least if I've followed his comments and this thread correctly. But I haven't yet hooked up an LED and resistor yet to watch it show the status. Maybe I should just to confirm that it works. Anyway, are you saying that, just as garryj sort of double uses the pin (the smart pin half and the physical pin half) to do both event storage and driving the LED, that the LED functionality could be sacrificed and the physical pin used for other things if the associated code driving the LED was ripped out (while still retaining the Event Repository functionality)? Is that what you did/mean? If so, that could come in handy.
@rogloh, thanks for that info. Those are a couple of possibilities. Quite a while back, I did locate a very long datasheet for the chip that the driver board in my setup uses. And I seem to recall it mentioning something about sync-on-green (SoG), but I don't think I ever fully understood it and the size of that data sheet unnerved me (I think that it was at least a hundred pages with a ton of setup registers, etc.). Edit: The firmware of the chip is actually alterable if one has the right software tool. Another thing that dissuaded me was that using such functionality might make it more troublesome for me (or possibly someone else) to use other people's drivers.
About the h, b, g, r pin order, I believe that it was you that originally explained the colourspace advantages of this "standardized" order to me (and pointed out that this order was the one that Chip was using). Thanks so much. And while it may be possible to alter that order (if not using the colourspace HW, I suppose), I don't think a person at my low "pay grade" should do so. I already tend to make things "funky" enough as it is. Nevertheless, I'll keep it (and especially composite sync and SoG) in the back of my mind (coz never say never), and it's really great that you were able to integrate that extra sync functionality into your amazingly versatile driver (which I routinely followed, even if much of it was over my head). You've got everything in there but the kitchen sink. Well, maybe that, too. I forget if you have mouse cursor capability in there, but I wouldn't be surprised. If so, maybe garryj's driver can be used to provide it with the x-y data through an intermediary. (And notice how I brought my comment back to USB stuff to keep it on topic? Well, I tried, anyway.)
Yes a USB mouse works nicely with the sprite cursor position in the driver. It's designed for that. A simple long update with X,Y values and it will follow the mouse co-ordinates, though it does need scaling to the graphics resolution. Just a few lines of SPIN2 or PASM, it's very simple and very responsive, as it is drawn directly into the line buffer for you.
Very nice, indeed. I figured that you'd do it on the fly (or effectively so), like a sprite.
@JRetSapDoog I also had trouble with that event pin stomping on something when not using the Parallax USB adapter...
I tweaked the Start() function a bit to stop that and also have it automatically update cursor position and key report like this:
PUB start(base_pin, enable_pin, dm_pin, err_led_pin) : cog 'RJA: Adding handling of mouse data to this driver 'RJA: Adding explicit enable pin that can be set to -1 to not use 'Setting pointers in assembly code before starting cog pMouseX:=@mouseGunk pMouseY:=@mouseGunk+4 pMouseMaxX:=@mouseGunk+8 pMouseMaxY:=@mouseGunk+12 pMouseButtons:=@mouseGunk+16 pKeyReport:= @pressedKeys 'Enable USB power, if enable_pin>0 if (enable_pin>0) pinh(enable_pin)So, you just set the enable_pin negative to not use it...
Hi, Rayman. Thanks for that comment. I like your tweaked start() method. Yeah, that's a better (long-term) solution than just commenting that functionality out. By "...trouble with that event pin stomping on something...," I assume that you mean the "enable pin" instead of the "event pin" (both words start with an 'e'). Unless I missed something, that matches what you wrote subsequently. Anyway, I think that your tweaked method would make using the driver somewhat easier for a more casual user to use (and everyone, really). And maybe garryj will incorporate something like that in a subsequent release.
As for how your accessing the mouse cursor coordinates and key states, I need to look at that further. But I think that I like the idea of putting such updating into the driver itself (with everything in one place). Currently, I'm using a modified version of one of garryj's demo programs as an intermediary between my top-level object and his USB driver. But why pay a middleman when you can buy direct from the factory? So I may change things later once I understand my options better. Thanks again for your comment.
Thanks for the comments and ideas, guys! I've been trying to focus on the hub-aware version, as I think it may offer the most bang for the buck, and should be much more friendly to two and three pin setups. The only hard rule is that the D- pin# must be an even numbered pin and the D+ pin# must be D- + 1.
When used as a host only, it should behave the same as the current single port version does, for low and full speed devices. If a hub is connected, it will initially support up to four ports. The first iteration will be limited to full-speed capable devices via hub, with (hopefully) low-speed devices via hub coming later.
As far as hubs go, USB 1.1 and 2.x versions work the best, but the two 3.x hubs I have are pretty finicky.
Wow, you actually have USB hub working? That's impressive. Still in just one cog?
Aren't most things full-speed at least now? I'm trying to remember what might be low speed only...
Yes, it would be really swell to have hub compatibility. About the number of cogs for a hub-capable USB host driver, the goal appears to be one cog. Gary has stated:
"A USB hub driver has been on my todo list for quite a while..... Since there shouldn't be any additional low-level buss signalling changes, I think the core code should still fit in one cog + lut exec, with the hub buss scheduler driver developed using C and/or spin." [thread pg. 1]
"I'm still (very slowly) working on a hub-capable version which works with one USB cog. The host is freed from some of the the device connect/disconnect load that is handled by the hub. I have full-speed boot protocol keyboard/mouse working fairly well with up to four ports. Low-speed devices via hub has been a tougher nut to crack...." [thread pg. 5]
I wonder how many keyboards and mice are full speed as opposed to low speed. On Wikipedia's entry on the old PS/2 port, I found this about mice sampling/polling: "Both PS/2 and USB allow the sample rate to be overridden, with PS/2 supporting a sampling rate of up to 200 Hz[2] and USB supporting a polling rate up to 1 kHz as long as the mouse runs at full-speed USB speeds or higher." (emphasis added) So, I'd imagine that gaming mice are full-speed devices, but don't know about regular mice (or keyboards).
Offhand, I forget if the current USB host driver provides a way to report whether a device is connected at LS or FS. I seem to recall something about the DM and DP lines being used differently depending on the device speed.
Plugging in USB things to desktop box ...
1st mouse = 12 Mb/s
2nd keyboard (only one USB) = 1.5 Mb/s
Prop2 = 12 Mb/s
2nd mouse = 1.5 Mb/s
3rd mouse 1.5 Mb/s
USB2 hub (it's actually USB3, shows up as two hubs) = 480 Mb/s
4th mouse = 1.5 Mb/s
Combo mouse+keypad = 1.5 Mb/s
Thanks, evanh. So, including the combo device, that's one full-speed mouse and four low-speed mice, plus two low-speed keyboards. That's six out of seven devices that are low-speed ones. Following your lead, I tried checking the connection speeds of a keyboard and a couple of mice under the Device Manager of Windows 10, but I didn't see anything that told me the connection speed (1.5 or 12 Mb/s). Under Properties and Details and Properties again, there were several dozen little reports with various bits of info, but I didn't see anything that gave the connection speed. Maybe I missed it. Anyway, with so many keyboards and mice apparently being low speed (1.5 Mb/s) devices, it sounds like they wouldn't work with a hub-compatible P2 host driver that only worked with full-speed devices. Or am I missing something? But even if that's right, if such a driver does get released, perhaps a subsequent version could add support for low-speed devices. But we'll gladly and appreciatively take whatever we can get, of course.
Err, I misled you a little it seems, my main keyboard is an old PS/2. The listed keyboard is the sole USB keyboard I have.
I'm using the KDE Info Centre that comes with the Kubuntu distro. It in turn will be probing the Linux /proc (or /sys I keep forgetting which) structures I presume.
I haven't been reading all that closely. But I have faith in Garry anyway.
Ah, sorry about that. Anyway, Garry has surprised himself, I think, by what's possible in/with one cog (with a competent and dedicated code warrior, I mean). One limiting factor, though, is finding the time. So we'll (and by "we'll" I mean "I'll) have to be patient.
For reference, here's a link to a Hackaday announcement about a project in which Dmitry Samsonov is doing a USB host that allows "for four USB 1.1 devices to be connected directly to the ESP32 without a separate dedicated chip." Don't know if he has implemented a hub or whether he can handle four separate ports with one instance (perhaps the latter from the picture?). Dmitry has responded to the announcement in the comments. Anyway, posting here for what it's worth.
@garryj
Garry, in working over the hub support would you give a look at these nice and very cheap all-comprehensive-one-ic hub solutions?
Terminus FE1.1 and Terminus FE1.1S
That can be found also on a few boards:
Adafruit 2991 USB Hub on Digikey
Retrocution 2 and 4 ports hub (without connectors)
Waveshare 4 Port USB HUB HAT
and from many suppliers
FuturaElettronica / ElettronicaIn (Futura shop)
AliExpress
and many others
DigiPart
Gary mentioned in the first post of this thread that " SmartSerial.spin and std_text_routines.spinh files that are packaged with Spin2gui." Where do I find the "Spin2gui"
Edit: what I really want to find is source for "printf"
Thanks,
Jim
Hehehehe, printf() source code will be horrid to read. It'll be humongous too.
Spin2gui is FlexProp - https://forums.parallax.com/discussion/170730/flexprop-a-complete-programming-system-for-p2-and-p1/p1
Thanks @evanh ,
Jim
i suspect I have trashed 2 of my p2 pins as I forgot to put protection rs on the USB inputs to the p2.
Jim
Although the USB power pin is 5V, the signals are 3.3 V for low speed USB.
So, think it would be hard to break P2 pins that way...
Most USB chips are significantly ESD rated on the USB pins, and some suggest adding additional ESD parts on top of that high rating,
Eg the EFM8UB3 has 8 kV ESD protection, but their SCH and Eval boards also add 3-line ESD parts too.
I will have to set up a test to see if I bricked the pins. When I use the demo program, I have tried 3 different mice and the screen displays only the initialization data with no indicated failures. However, I do not see any output that would say that the mouse is being read. I am wondering if it has anything to do with the xtal and clock frequencies? I am using a Kiss eval board from ManatWork with a 25MHz xtal and a 200_000_000 MHz clock. I have made the changes in cons at the top of the file and with a 2_000_000 Baud clock I do see the serial printouts correctly. I use flexprop as my compiler and I am using base pin 16 with DM and DP on 22 and 23. Any suggestions? The Mice are 6~year old Radio Shack wireless and a new wired Ohn from Walmart. Also tried my 2 year old Logitec wireless all to no avail. Not super critical but I was experimenting with using an optical mouse as a way to get high rez position data off of a ball to use as a joystick.
Jim
EDIT correct pin numbers to 22 and 23 I guess I could not add when I posted this.
I believe I have seen cases where the 25 MHz xtal made some things not work.
But, if you got serial text to work, maybe you're OK.
Also, DM and DP have to be in a particular order, the driver file has a description of that.
But, just be sure to use the same order as in the examples.
Also, the pins have to be in pairs, that are next to each other. Don't think 23 & 24 will work.
What I have is basepin==16 and:
DM = USB_BASEPIN + 6 ' DM is "The Brain"
DP = USB_BASEPIN + 7 ' DP is passive
So, that's 24 & 25
Well spotted Rayman. Lower I/O # has to be an even number for the low-level pairing to work.
Has anyone had success with running this with a 200MHz clock? I was afraid that I had bricked io pins on one board so I set it up to run on my other board with exact same results. Using the test demo program it prints out the startup info and stops. I have tried three different mice. 2 wireless and 1 wired. I am not interested in the Keyboard, only the mouse data. Not sure where to go next unless I put debugging print statements throughout the code.
Jim
Works totally fine @ 320 MHz and above. But I've only used keyboards.
@RS_Jim did u see post above about PIN numbers ?
The ones you picked won’t work..