T
Reaction score
0

Latest activity Postings About

    • T
      I do finally have this working! The solution was to put in a delay between usb.begin() and serial.begin() I'm guessing it was just happening too quickly and so the BAUD was not being correctly set to 9600 as needed by the device. Here's the...
    • T
      TeensyG reacted to KurtE's post in the thread USBHost_t36 and FTDI device - so close! with Like Like.
      You are right, that the bigbuffer was setup to handle USB High Speed devices, which typically have transfers of 512 bytes instead of 64 bytes, as well as higher speeds. the ,1 was a hack as by default it will only claim high speed serial...
    • T
      TeensyG reacted to KurtE's post in the thread USBHost_t36 and FTDI device - so close! with Like Like.
      You might try adding userial.flush(); after the writes To see i it helps
    • T
      I had that same thought and tried that before posting here. Sadly it didn't make any difference :-/
    • T
      Thanks for your reply. VID\PID = 0403:6001 I did run HIDDeviceInfo.ino with Debug: port change: 10001803 connect begin reset port change: 10001005 port enabled end recovery new_Device: 12 Mbit/sec new_Pipe enumeration: enumeration...
    • T
      Thanks for the suggestion, but it hasn't made any difference unfortunately.
    • T
      You might try your tests using just "USBSerial serial(myusb);". I suspect that the FTDI is only a Full-Speed link, not the 480Mb/second High-Speed for which USBSerial_BigBuffer was designed. Just today, I found that BigBuffer will crash the...
    • T
      I believe that, without the "-n" command line option included, the "echo" command in linux will terminate the data to be sent with either CR, or LF, and possibly CR/LF. You might try adding additional characters to your rCmd array & inserting...
    • T
      OK, well shucks, did you also try these (in case the device doesn't like CR/LF together . . . hoping that one of them provides the missing magic): byte rCmd[] = {255, 3, 1, 13}; - OR - byte rCmd[] = {255, 3, 1, 10}; then using...
    • T
      No not explicitly although I have tried {255, 3, 1, 13, 10} and {255, 3, 1, 10, 13}, although using RealTerm (a great tool!) I can confirm that neither CR nor LF are needed, just the 3 numbers.
    • T
      I have noticed that using RealTerm under Windows I can get the same bad behaviour (flashing comms lights, but no control) if I set the BAUD to anything other than 9600 (8n1). So this has me wondering, is this just an issue with the BAUD of the...
    • T
      Thanks for your reply. I have previously tried that by defining: byte rCmd[] = {255, 3, 1, 13, 10}; and then, userial.write(rCmd, 5); But sadly it still doesn't work.
    • T
      I'm using a Teensy 4.1 with USBHost_t36 to control an 8-relay USB box, specifically a KMTronic box. It works great! So I bought another one. Unbeknown to me the first KMTronic uses CDC, whereas the second one I bought uses FTDI and doesn't...
  • Loading…
  • Loading…
Back
Top