Shop OBEX P1 Docs P2 Docs Learn Events
Working full-speed (12 Mb/s) bit-banging USB Host controller - Page 5 — Parallax Forums

Working full-speed (12 Mb/s) bit-banging USB Host controller

1235

Comments

  • william chanwilliam chan Posts: 1,326
    edited 2010-10-19 01:03
    Hey,

    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.

    Anybody? Mike Green?
    Please help.
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2010-10-19 06:33
    Showing my complete ignorance, again, but isnt there a speed issue as you get further away from the P0 end ?
  • william chanwilliam chan Posts: 1,326
    edited 2010-10-19 07:32
    As far as I know, the speed is the same as long is it is within P0 to P7.
    After all, a literal is a literal.
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2010-10-19 08:28
    What I was remembering was that the low cog has less OR gates in the way of the output pins.
  • william chanwilliam chan Posts: 1,326
    edited 2010-10-19 19:25
    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.
  • MacTuxLinMacTuxLin Posts: 821
    edited 2010-10-21 21:53
    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).
  • ionymousionymous Posts: 29
    edited 2010-11-08 16:22
    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?
  • scanlimescanlime Posts: 106
    edited 2010-11-09 22:02
    ionymous wrote: »
    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 :)

    Cheers,
    --beth
  • ionymousionymous Posts: 29
    edited 2010-11-16 16:29
    I saw this bluetooth module advertised with "HID software stack".
    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?
  • jazzedjazzed Posts: 11,803
    edited 2011-01-29 13:23
    Hey,

    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.
  • Cluso99Cluso99 Posts: 18,066
    edited 2011-01-30 02:02
    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.
  • jazzedjazzed Posts: 11,803
    edited 2011-01-31 12:35
    Micha, If you're around ....

    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=01
    

    Any help at all in understanding why services are not available would be great.
    Thanks.
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2011-02-01 01:19
    Clusso

    "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)
  • HumanoidoHumanoido Posts: 5,770
    edited 2011-02-01 03:53
    Excellent - you're on the list here!
  • StardiskStardisk Posts: 1
    edited 2011-04-03 09:20
    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.
  • ProcessingData...ProcessingData... Posts: 208
    edited 2011-04-15 13:19
    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.
  • Cluso99Cluso99 Posts: 18,066
    edited 2011-04-15 17:45
    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.
  • LtechLtech Posts: 366
    edited 2012-11-19 13:26
    @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

    sombody has it work ?

    Thanks
  • jmgjmg Posts: 15,140
    edited 2012-11-19 15:03
    Cluso99 wrote: »
    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.


    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.

  • Heater.Heater. Posts: 21,230
    That is mightily impressive.
  • jmgjmg Posts: 15,140
    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!

    Wow.
    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.

    Using a Pin is tolerable.
    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

    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 ?
  • Cluso99Cluso99 Posts: 18,066
    April 1st ???
  • Heater.Heater. Posts: 21,230
    That's a serious lot of code in the linked repos for an April Fools day prank.
  • yetiyeti Posts: 818
    edited 2017-04-01 13:27
    Apropos April 1st...

    Look at the bottom of http://scanlime.org/2010/04/its-alive-bit-banging-full-speed-usb-host-for-the-propeller/:
    This entry was posted in Propeller and tagged bit-banging, usb on April 1, 2010.
    ...that's far too much April 1st to be a prank!
    ;-)
  • 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.

    jmg wrote: »
    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 ?

    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.

    jmg wrote: »
    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 ?

    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!



  • pjvpjv Posts: 1,903
    Just wondering......

    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)
  • jmgjmg Posts: 15,140
    The low speed receiver can theoretically tolerate a 5% offset. I've tested neither of these limits.
    Does that mean the low-speed version uses a DPLL to resync on edges, so it more clock tolerant ?

    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...
Sign In or Register to comment.