Has anybody tried changing the Propeller pins for USB?
I tried changing to P4 and P5 but it doesn't work. It returns with error -150.
' USB data pins. We make a couple assumptions about these, so if you want to change these it isn't as
' straightforward as just changing these constants:
'
' - Both DMINUS and DPLUS must be <= 8, since we use pin masks in instruction literals.
' - The vcfg and palette values we use in the transmitter hardcode these values,
' but they could be changed without too much trouble.
DMINUS = 4
DPLUS = 5
I ran through the code a few times but couldn't find the vcfg and palette values that need to be changed.
But we are changing pins here, not cogs.
The code remarks by Micah also mentions that P0 and P1 pin can be easily changed to any other pins less than P8.
My problem is I don't know how to do it.
Hi,
You work is great! I'm eager to test but instead of using a 6MHz crystal, can I use a 12MHz crystal and pll8x? (as that's the only crytal I have at the moment).
I was hoping to get my propeller working with the wiimote.
I was excited to find this thread, but Micah hasn't posted here or to any other thread in a while. And I was excited to see ribbotson's Wiimote work.
Has any further progress been made?
I'm around, I just have had other things going on
If I remember correctly, at this point the RFCOMM code should be pretty solid- but for wiimote (or any other input devices) you'll want L2CAP sockets. So for now, you can either use ribbotson's code, add clean L2CAP socket support, or wait for someone else to do it
I've been emailing back and forth with a representative from the company to learn about it. She says what they currently have to offer is the LM400 module which they can load with special HID firmware. http://www.lm-technologies.com/business/product_item.php?item_id=5
The LM400 has a header with uart interface and a 12 pin header.
It sounds like it's about $40.
Would this product make interfacing a wiimote via bluetooth easier?
Has anybody tried changing the Propeller pins for USB?
I tried changing to P4 and P5 but it doesn't work. It returns with error -150.
I thought I would post this before I lose it some how
This is micha's usb-fs-host.spin low level driver that allows connecting on any pin pair. It works if built with bstc -Ox -D ANYPIN. The base pin can be changed by setting BUS_START_PIN to you DMINUS pin number.
I've run bluetooth-test.spin and was able to discover and pair with the Propeller blue-tooth device on my Netbook PC.
I'll do more testing. My current plan is to use this on at least one port of the MicroPropPC.
Any help testing the driver as is would be greatly appreciated.
Thanks.
Postedit:
Well, it's not ANYPIN just yet. It's Pin P0/1, P8/9, P16/17, P24/25 ... my testing was with P24/25.
I guess a different pixel pattern could be used for the waitvid instructions though ....
Also, I forgot the # on tx_sof: shr t1,#BUS_START_PIN ... that coincidentally worked.
Seems like I have a reason to get bluetooth running between a pair of props. I am going to get a pair of cheap bluetooth USB sticks from www.buyincoins.com for less than $1.50ea inc postage. I have dealt with them via eBay before and they were great.
I do have some things to do first, but this is now firmly on my list.
I've been testing the USB stack with your version 1.0 usb-fs-host.spin unmodified.
I find that test-enumerate.spin fails intermittently - is this normal?
Also, I can pair, but can't discover services on 2 different adapters I've tried.
Here's an test-enumerate endpoint dump from one of the devices:
"Seems like I have a reason to get bluetooth running between a pair of props. I am going to get a pair of cheap bluetooth USB sticks from www.buyincoins.com for less than $1.50ea inc postage. I have dealt with them via eBay before and they were great."
I seem to recall people saying that some of the cheap BT dongles have a common MAC, that would stop them inter communicating
I have been beating on this and have made progress to the point that I need to know of a bluetooth dongle that is a known compatible dongle.
I consistently get Error -150 and and Error 170. Any advice on a known good bluetooth dongles would be great.
So, according to the "features" list for the propeller 2, the speed limitations will be overcome for communicationg with USB devices?
The primary values that seem to be settled on for now are 8 COGs, 128K Hub RAM (tentatively Beau Schwabe has said 256K is still a possibility), 32K ROM, 92 I/Os, and 160Mhz.
160MHz is only part of the story. The cogs execute 1 instruction per clock cycle, so that is 4x plus clock 2x = 8x faster. Hub is 2x (1 in 8) plus clock 2x plus quad longs can be accessed 4x = 16x. Add to that some additional hardware for counters and bit shifting etc. Chip said there would be some hardware to support USB but no details. You can be pretty sure USB will be fairly easy, at least v2.0.
@jazzed I can pair, tranmit and recive, but can't discover services on 2 different adapters I've tried..... Same trouble ! got a sitecom anr china bluetooth
I just need to get discovering part working, for presance detecting
160MHz is only part of the story. The cogs execute 1 instruction per clock cycle, so that is 4x plus clock 2x = 8x faster. Hub is 2x (1 in 8) plus clock 2x plus quad longs can be accessed 4x = 16x. Add to that some additional hardware for counters and bit shifting etc. Chip said there would be some hardware to support USB but no details. You can be pretty sure USB will be fairly easy, at least v2.0.
Plus Prop II now time-slices (threads) too, so USB will likely shrink down to a single cog, or code-size issues may push a general solution to two COGs.
On Prop II you can "fill-up" a COG much better.
Due to the worldwide shortage of Propeller 2 chips and 6 MHz crystals for the Propeller 1, we have decided to support USB host with the standard 5 MHz crystal. Yes, you can teach an old chip new tricks!
The trick was using the counters as a shift register. You need a spare IO pin for this to work. The code currently uses P8 for that. It can be changed if needed. The counter-augmented receiver could be adapted for 96 MHz for those who want to overclock. I targeted 80 MHz because that's the standard Propeller clock frequency.
I also added support for low speed devices to enable Human Interface Devices like keyboards and mice. I think I spent more time on the low speed receiver than the full speed receiver. I thought adding low speed support would be easy, but it took me a couple tries to get a good low speed receiver. Also, this new code uses one less cog.
We may eventually combine these forks into a single repository.
Many thanks to scanlime for writing a working USB host. I don't think I would have been motivated enough or knew enough about USB to write this all from scratch. Maybe now I could do it. I sure learned a lot about USB doing this.
Due to the worldwide shortage of Propeller 2 chips and 6 MHz crystals for the Propeller 1, we have decided to support USB host with the standard 5 MHz crystal. Yes, you can teach an old chip new tricks!
The trick was using the counters as a shift register. You need a spare IO pin for this to work. The code currently uses P8 for that. It can be changed if needed. The counter-augmented receiver could be adapted for 96 MHz for those who want to overclock. I targeted 80 MHz because that's the standard Propeller clock frequency.
I also added support for low speed devices to enable Human Interface Devices like keyboards and mice. I think I spent more time on the low speed receiver than the full speed receiver. I thought adding low speed support would be easy, but it took me a couple tries to get a good low speed receiver. Also, this new code uses one less cog.
The part about there being a shortage of Propeller 2 chips and crystals, that's a joke. Oh, wait. There is a shortage of Propeller 2 chips. )-;
I was wondering, "Could USB work at 80 MHz?" I put together a small test program that sent 12 mbps data with the video generator and tried to receive it on another cog. It was fairly straightforward. Likely easier than the existing 2 cog interleaved receiver. Being fairly familiar with the Propeller 1 verilog code may have been a huge advantage here.
At this stage, I was hooked. I just had to go all the way and get the USB host working at 80 MHZ. Why? Because it would be amazing! Never actually used it in a project. I figured publishing on April 1 would be fun and that gave me the extra motivation I needed to get my code merged with the new upstream changes.
Can you add some stats to the readme file ?
- Code Size, COGs needed, any caveats, tested data speeds for read / write ?
The full speed receiver operates at a fixed clock rate. So, the end of the packet must not be shifted more than half a bit time. For a 64 byte packet, a 450 ppm offset will result in a phase shift of .25 bit times at the end of the packet. The low speed receiver can theoretically tolerate a 5% offset. I've tested neither of these limits.
5364 bytes for test-hid.spin
There is detailed documentation at the top of usb-fs-host.spin.
The part about there being a shortage of Propeller 2 chips and crystals, that's a joke. Oh, wait. There is a shortage of Propeller 2 chips. )-;
I was wondering, "Could USB work at 80 MHz?" I put together a small test program that sent 12 mbps data with the video generator and tried to receive it on another cog. It was fairly straightforward. Likely easier than the existing 2 cog interleaved receiver. Being fairly familiar with the Propeller 1 verilog code may have been a huge advantage here.
At this stage, I was hooked. I just had to go all the way and get the USB host working at 80 MHZ. Why? Because it would be amazing! Never actually used it in a project. I figured publishing on April 1 would be fun and that gave me the extra motivation I needed to get my code merged with the new upstream changes.
Can you add some stats to the readme file ?
- Code Size, COGs needed, any caveats, tested data speeds for read / write ?
The full speed receiver operates at a fixed clock rate. So, the end of the packet must not be shifted more than half a bit time. For a 64 byte packet, a 450 ppm offset will result in a phase shift of .25 bit times at the end of the packet. The low speed receiver can theoretically tolerate a 5% offset. I've tested neither of these limits.
5364 bytes for test-hid.spin
There is detailed documentation at the top of usb-fs-host.spin.
Welcome to the forum, and thanks for the new code!
The full speed receiver operates at a fixed clock rate. So, the end of the packet must not be shifted more than half a bit time. For a 64 byte packet, a 450 ppm offset will result in a phase shift of .25 bit times at the end of the packet.
What parts did you test this talking to/from ?
Older USB devices use crystals (as still do HS-USB parts like FT2232H series)
Newer USB devices have a DPLL that uses the 1ms frame rate to sync, with step sizes usually > 0.1%.
That means those parts could be off by > 450ppm ?
Maybe that imposes some upper packet or data rate, in order to keep timing ?
This would be an excellent enhancement, SaucySoliton. Full speed USB at 80MHz with only 2 PASM driver COGS and 3 pins. I like the sound of it and now want to try to setup something to first try it out with a mouse / keyboard and then see if I can get some full speed device enumerated too. If it works as stated at 80MHz it will be very impressive indeed. Can't wait to try it...
Comments
Has anybody tried changing the Propeller pins for USB?
I tried changing to P4 and P5 but it doesn't work. It returns with error -150.
I ran through the code a few times but couldn't find the vcfg and palette values that need to be changed.
Anybody? Mike Green?
Please help.
After all, a literal is a literal.
The code remarks by Micah also mentions that P0 and P1 pin can be easily changed to any other pins less than P8.
My problem is I don't know how to do it.
You work is great! I'm eager to test but instead of using a 6MHz crystal, can I use a 12MHz crystal and pll8x? (as that's the only crytal I have at the moment).
I was excited to find this thread, but Micah hasn't posted here or to any other thread in a while. And I was excited to see ribbotson's Wiimote work.
Has any further progress been made?
I'm around, I just have had other things going on
If I remember correctly, at this point the RFCOMM code should be pretty solid- but for wiimote (or any other input devices) you'll want L2CAP sockets. So for now, you can either use ribbotson's code, add clean L2CAP socket support, or wait for someone else to do it
Cheers,
--beth
LM780
http://www.lm-technologies.com/business/product_item.php?item_id=1
I've been emailing back and forth with a representative from the company to learn about it. She says what they currently have to offer is the LM400 module which they can load with special HID firmware.
http://www.lm-technologies.com/business/product_item.php?item_id=5
The LM400 has a header with uart interface and a 12 pin header.
It sounds like it's about $40.
Would this product make interfacing a wiimote via bluetooth easier?
I thought I would post this before I lose it some how
This is micha's usb-fs-host.spin low level driver that allows connecting on any pin pair. It works if built with bstc -Ox -D ANYPIN. The base pin can be changed by setting BUS_START_PIN to you DMINUS pin number.
I've run bluetooth-test.spin and was able to discover and pair with the Propeller blue-tooth device on my Netbook PC.
I'll do more testing. My current plan is to use this on at least one port of the MicroPropPC.
Any help testing the driver as is would be greatly appreciated.
Thanks.
Postedit:
Well, it's not ANYPIN just yet. It's Pin P0/1, P8/9, P16/17, P24/25 ... my testing was with P24/25.
I guess a different pixel pattern could be used for the waitvid instructions though ....
Also, I forgot the # on tx_sof: shr t1,#BUS_START_PIN ... that coincidentally worked.
I do have some things to do first, but this is now firmly on my list.
I've been testing the USB stack with your version 1.0 usb-fs-host.spin unmodified.
I find that test-enumerate.spin fails intermittently - is this normal?
Also, I can pair, but can't discover services on 2 different adapters I've tried.
Here's an test-enumerate endpoint dump from one of the devices:
Found device 0A5C:2121 Raw device descriptor: 12 01 00 02 E0 01 01 40 5C 0A 21 21 00 01 01 02 00 01 Device configuration: Interface ptr=03B5 number=00 alt=00 class=E0 subclass=01 Endpoint ptr=03BE address=81 maxpacket=0010 Endpoint ptr=03C5 address=82 maxpacket=0040 Endpoint ptr=03CC address=02 maxpacket=0040 Interface ptr=03D3 number=01 alt=00 class=E0 subclass=01 Endpoint ptr=03DC address=83 maxpacket=0000 Endpoint ptr=03E3 address=03 maxpacket=0000 Interface ptr=03EA number=01 alt=01 class=E0 subclass=01 Endpoint ptr=03F3 address=83 maxpacket=0009 Endpoint ptr=03FA address=03 maxpacket=0009 Interface ptr=0401 number=01 alt=02 class=E0 subclass=01 Endpoint ptr=040A address=83 maxpacket=0011 Endpoint ptr=0411 address=03 maxpacket=0011 Interface ptr=0418 number=01 alt=03 class=E0 subclass=01 Endpoint ptr=0421 address=83 maxpacket=0019 Endpoint ptr=0428 address=03 maxpacket=0019 Interface ptr=042F number=01 alt=04 class=E0 subclass=01 Endpoint ptr=0438 address=83 maxpacket=0021 Endpoint ptr=043F address=03 maxpacket=0021 Interface ptr=0446 number=01 alt=05 class=E0 subclass=01 Endpoint ptr=044F address=83 maxpacket=0031 Endpoint ptr=0456 address=03 maxpacket=0031 Interface ptr=045D number=02 alt=00 class=FF subclass=FF Endpoint ptr=0466 address=84 maxpacket=0020 Endpoint ptr=046D address=04 maxpacket=0020 Interface ptr=0474 number=03 alt=00 class=FE subclass=01Any help at all in understanding why services are not available would be great.
Thanks.
"Seems like I have a reason to get bluetooth running between a pair of props. I am going to get a pair of cheap bluetooth USB sticks from www.buyincoins.com for less than $1.50ea inc postage. I have dealt with them via eBay before and they were great."
I seem to recall people saying that some of the cheap BT dongles have a common MAC, that would stop them inter communicating
(I think, 03:30 start this morning)
I consistently get Error -150 and and Error 170. Any advice on a known good bluetooth dongles would be great.
I just need to get discovering part working, for presance detecting
sombody has it work ?
Thanks
Plus Prop II now time-slices (threads) too, so USB will likely shrink down to a single cog, or code-size issues may push a general solution to two COGs.
On Prop II you can "fill-up" a COG much better.
The trick was using the counters as a shift register. You need a spare IO pin for this to work. The code currently uses P8 for that. It can be changed if needed. The counter-augmented receiver could be adapted for 96 MHz for those who want to overclock. I targeted 80 MHz because that's the standard Propeller clock frequency.
I also added support for low speed devices to enable Human Interface Devices like keyboards and mice. I think I spent more time on the low speed receiver than the full speed receiver. I thought adding low speed support would be easy, but it took me a couple tries to get a good low speed receiver. Also, this new code uses one less cog.
The latest USB host code can be found on github.
For 80 MHz, full speed and low speed:
https://github.com/SaucySoliton/propeller-usb-host
For 96 MHz, full speed only:
https://github.com/scanlime/propeller-usb-host
We may eventually combine these forks into a single repository.
Many thanks to scanlime for writing a working USB host. I don't think I would have been motivated enough or knew enough about USB to write this all from scratch. Maybe now I could do it. I sure learned a lot about USB doing this.
Wow.
Using a Pin is tolerable.
Did you test the clock tolerance of this ?
Can you add some stats to the readme file ?
- Code Size, COGs needed, any caveats, tested data speeds for read / write ?
Look at the bottom of http://scanlime.org/2010/04/its-alive-bit-banging-full-speed-usb-host-for-the-propeller/: ...that's far too much April 1st to be a prank!
;-)
I was wondering, "Could USB work at 80 MHz?" I put together a small test program that sent 12 mbps data with the video generator and tried to receive it on another cog. It was fairly straightforward. Likely easier than the existing 2 cog interleaved receiver. Being fairly familiar with the Propeller 1 verilog code may have been a huge advantage here.
At this stage, I was hooked. I just had to go all the way and get the USB host working at 80 MHZ. Why? Because it would be amazing! Never actually used it in a project. I figured publishing on April 1 would be fun and that gave me the extra motivation I needed to get my code merged with the new upstream changes.
The full speed receiver operates at a fixed clock rate. So, the end of the packet must not be shifted more than half a bit time. For a 64 byte packet, a 450 ppm offset will result in a phase shift of .25 bit times at the end of the packet. The low speed receiver can theoretically tolerate a 5% offset. I've tested neither of these limits.
5364 bytes for test-hid.spin
There is detailed documentation at the top of usb-fs-host.spin.
Welcome to the forum, and thanks for the new code!
You transmit in one cog, and receive in another cog in the same Chip presumably. Hence the clocks to those two cogs are synced.
Does your code still always work if the cogs are in different chips?
Cheers,
Peter (pjv)
What parts did you test this talking to/from ?
Older USB devices use crystals (as still do HS-USB parts like FT2232H series)
Newer USB devices have a DPLL that uses the 1ms frame rate to sync, with step sizes usually > 0.1%.
That means those parts could be off by > 450ppm ?
Maybe that imposes some upper packet or data rate, in order to keep timing ?