Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 3 of 3

Thread: USB on teensy 3.2

  1. #1
    Junior Member
    Join Date
    Jan 2018
    Location
    Veldhoven, The Netherlands
    Posts
    2

    USB on teensy 3.2

    I've written some code on a teensy 3.2 that arrived a week ago. It is very economical and feature rich processor board. I am an old-fashoned coder: I like Makefiles, *.c and *.h and there it stops. I made good use of what I could find on the Internet on compilers, code examples, download utilities and such. If I had to do 1% of that code from scratch, I would not be nearly as far as I got now. But ... (and you were expecting this otherwise I would not be posting) ... there is a but too.

    1) It was far easier to find code than it was to find documentation on that code.

    2) Maybe it is my misunderstanding or maybe it is an oversight, but it seems that the usb_isr() (and then likely the other isr()s too) is implemented wrong. It is a plain C function and does not save the processor registers. These registers might contain useful intermediate information at the precise moment that interrupt arrived and they are ruined by the code that is executed during the ISR. A simple fix for this is to declare the isr as follows:

    void __attribute__((interrupt)) usb_isr(void)
    {
    ...
    }

    This way the compiler saves the registers that are used as scratch registers and it restores them upon return.

    3) Another problem I found is that the yield() function does not call the usb_isr(). Without calling this routine frequently from the application code, the communication might starve. When the hosts initiate communication, the hosts causes interrupts and then the line stays open for that reason. But if the host only listens, then the communication will die quickly without this fix.

    I have implemented code for bit-banging the GPIO pins for controlling neo-pixels. The code works well and it even allows interrupts after every pixel. It currently handles 3 strings in parallel and this can be increased without impact on the timing. The string length is limited by the memory size (4 bytes per pixel) and the refresh rate that you find acceptable. If case there is interest in that code, I have attached them to this message.

    Regards,
    Thom.
    Attached Files Attached Files
    Last edited by thom; 01-18-2018 at 11:23 AM.

  2. #2
    You're my kind of coder, Thom. Keep up the good work.

  3. #3
    Junior Member
    Join Date
    Jan 2018
    Location
    Veldhoven, The Netherlands
    Posts
    2
    I found some bugs in untested parts of the code. Here is an update.
    Attached Files Attached Files

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •