Search results

  1. Y

    error: causes a section type conflict with

    Seems like removing a call to AudioMemory(4); resolves the issue, but I need to call AudioMemory(). Is there another workaround? UPDATE:: Looks like if I change where I'm calling AudioMemory() I can get around the problem.
  2. Y

    error: causes a section type conflict with

    I'm getting the following error during compiling. Any idea how to resolve it? AudioStream.h:110:30: error: data causes a section type conflict with fb static DMAMEM audio_block_t data[num]; The fb variable is declared as: #define PIXEL_SIZE uint16_t #define RENDER_BUFFER_SIZE 800 * 200...
  3. Y

    USB Host port Turn off power from user code

    Works. void USBHost::setPower(bool state) { if (state) { #ifdef ARDUINO_TEENSY41 IOMUXC_SW_MUX_CTL_PAD_GPIO_EMC_40 = 5; IOMUXC_SW_PAD_CTL_PAD_GPIO_EMC_40 = 0x0008; // slow speed, weak 150 ohm drive GPIO8_GDIR |= 1 << 26; GPIO8_DR_SET = 1 << 26...
  4. Y

    Teensy 3.2 End Of Life

    Paul, I assume PJRC will continue to make the T3.x bootloader chip available. Do you have any idea how long it will continue to be available?
  5. Y

    Custom Audio board for T4.1 using IN2 OUT2 MCLK2 LRCLK2 BCLK2

    This will work right? I assume it will, but I thought I would ask first before I build my custom device.
  6. Y

    USB Host port Turn off power from user code

    Thanks. I'll experiment and post the results.
  7. Y

    USB Host port Turn off power from user code

    I'm playing around with using a USB C connector for my USB host port. As part of the USB C spec, power needs to be turned off until you verify that the connected device is an upstream device. How can I toggle the power on/off for the USB host port on T4.1?
  8. Y

    Custom T4.1 Move R6 from under the BGA

    I'm working on a new custom T4.1, and I'm having trouble getting all the pins I need broken out of the BGA. To make a little more space for routing, I was hoping to move R6 from its usual position (directly under the BGA), to a new position right next to the bootloader chip. This should be...
  9. Y

    Using a DMA channel to move data from DMAMEM to EXTMEM

    I haven't had time to implement and benchmark its performance yet, but I just wanted to say thanks.
  10. Y

    Using a DMA channel to move data from DMAMEM to EXTMEM

    I honestly know almost nothing about DMA channels, but I'm curious about moving some data from a buffer in DMAMEM to another one in EXTMEM (PSRAM). Is that something I can do? Is the method basically the same as described in the following thread? Thanks for any insights you can share...
  11. Y

    What does this tell you about my SPI signal?

    I had the SDO (MISO) hooked up incorrectly. Everything is working fine now.
  12. Y

    What does this tell you about my SPI signal?

    Thanks guys. I switch to 10x and it's looking more realistic. Now I'm seeing a significant amount of ringing. I suspect this could be the cause of my issue?
  13. Y

    What does this tell you about my SPI signal?

    I'm trying to get an LCD panel working with a custom T4.1 device, but I'm getting mostly garbage on the screen, so I'm thinking I have signal integrity issues. Here's a pic of the SPI CLCK on my oscilloscope. I'm guessing I can slow down the SPI interface and get the LCD working properly, but...
  14. Y

    USBHost_t36 USB Mass Storage Driver Experiments

    I'm quite certain that the issue you highlight here is responsible for a problem I'm seeing where my T3.6 device will hang when sending MIDI to multiple devices connected to its host port. https://forum.pjrc.com/threads/73129-USBHost-send-MIDI-Issue Do you have a fix in mind for...
  15. Y

    USBHost send MIDI Issue

    The test has now ran overnight without locking up.
  16. Y

    USBHost send MIDI Issue

    I'm unfortunately seeing a MIDI issue in the USBHost_T3.6 library. With moderate levels of MIDI traffic between and host Teensy 3.6 and multiple child MIDI devices (T3.2), the host eventually hangs, usually after a few minutes, depending on how heavy the traffic is. My tests have shown that...
  17. Y

    Teensy 4.1 - ESD protection for bootloader reset

    Thank-you. I'll protect all three.
  18. Y

    Teensy 4.1 - ESD protection for bootloader reset

    I'm going to be doing EMC testing on a T4.1 based device soon, and I feel I should probably protect the RESET line, but I'm not entirely sure which line(s) I need to protect. Does anyone have any experience with this?
  19. Y

    USB Host Port hotplug MIDI Device issue

    Yes. It turned out to be a bug with the Mass Storage driver. Should be fixed in Teensydruino 1.58. I say 'should' because I'm still using the workaround JIC, so I don't actually know if the bug that was fixed also fixed this particular issue, but I suspect it did.
  20. Y

    tgx: a 2D/3D graphics library for Teensy.

    I have been busy with other things, but finally have some time to look into this some more. I was playing around today with Vindar's ili9341_t4 driver, and I noticed that putting the 'internal frame buffer' onto PSRAM actually works pretty well when using double buffering and differential...
  21. Y

    T3 Bootloader Chip future availability

    I have about a 1000 MCUs on order for T3.x devices that will ostensibly arrive early next year (fingers crossed). What is the future availability of the T3 bootloader looking like? I don't want to be stuck with a bunch of MCUs that I can't turn into working devices.
  22. Y

    tgx: a 2D/3D graphics library for Teensy.

    An 8 bit color palette would probably work for me. I tried very hard to get my ram1 usage down enough to fit a 480x32 16bit buffer, but couldn't do it. Lots of space left in ram2. Is it possible to have a buffer that spans across ram1 and ram2?
  23. Y

    tgx: a 2D/3D graphics library for Teensy.

    I have 2 PSRAM chips on this device which I can use, but it's slow. Putting one buffer in DMAMEM and the other in normal ram, doesn't leave a whole lot of RAM1 for my UI. I'll see if I can do some changes to free up more RAM1.
  24. Y

    tgx: a 2D/3D graphics library for Teensy.

    Double buffering with 32bit or 16bit color at 480x320 just isn't going to work on T4.1--not enough memory. I have no shortage of digital pins for this project, so I might be better off using a parallel interface.
  25. Y

    tgx: a 2D/3D graphics library for Teensy.

    Thanks for the info Kurt. GTX in combination with with his ILI9431_T4 driver is crazy fast. I don't really have a good understanding of how it works, but I think it's figuring out which pixels have changed, and only updates those. I would have been happy to stick with the ili9431, but it's...
  26. Y

    ILI9488_t3 - Support for the ILI9488 on T3.x and beyond...

    False alarm. I had accidently commented out.. #define ENABLE_EXT_DMA_UPDATES
  27. Y

    ILI9488_t3 - Support for the ILI9488 on T3.x and beyond...

    Couldn't get the UpdateAsyncCont_Test example to work properly on T4.1. I can see "Starting up DMA Updates" in the serial monitor after I send some input, but the screen just reads "*** Press key to start ***" the whole time.
  28. Y

    tgx: a 2D/3D graphics library for Teensy.

    So I did manage to get gtx working with the ILI9488 driver, but it's incredibly slow. No double buffering, no differential buffers really makes things crawl.
  29. Y

    tgx: a 2D/3D graphics library for Teensy.

    @vindar Any chance on getting a ILI9488 driver that's compatible with gtx?
  30. Y

    USBHost_t36 USB Mass Storage Driver Experiments

    As far as I can tell, readSectorsCallback() is still forcing the user to wait. It would probably be more useful it was a non-blocking operation that triggered the callback when the read was complete.
  31. Y

    USBHost_t36 USB Mass Storage Driver Experiments

    Are readSectorsCallback() and its related methods being used?
  32. Y

    USBHost_t36 USB Mass Storage Driver Experiments

    I managed to make it so that commands are initiated in user code (the first call queue_Data_Transfer), but then all the subsequent calls related to the command are handled in the callbacks. Seems to work nicely. I'll clean up my code and share in case anyone wants to try it out.
  33. Y

    USBHost_t36 USB Mass Storage Driver Experiments

    Ya, I agree that user code should have to wait while the data is read / written. Things would get pretty messy otherwise. In my non-blocking USBDrive init, I do the initialization as a state machine inside of Task() and then call startFileSystem() after the initialization is complete, which...
  34. Y

    USBHost_t36 USB Mass Storage Driver Experiments

    I'll try it out today, but I feel like it's using duct tape to fix a problem. Obviously commands need to begin in user code, but subsequent calls to queue_Data_Transfer should probably be done inside the callbacks so that they are initiated in the isr(). With the fix to pipeIn, my...
  35. Y

    USBHost_t36 USB Mass Storage Driver Experiments

    Thank-you so much. This fixes the issue for me. I can't tell you how many hours I have spent pouring over the UBSHost code desperately trying to fix this issue.
  36. Y

    USBHost_t36 USB Mass Storage Driver Experiments

    What about.movimg.the calls to msGetCSW() to the input or output callbacks. Wouldn't that be safer?
  37. Y

    USBHost_t36 USB Mass Storage Driver Experiments

    I'm about to go to bed, but I also noticed that the MassStorageDriver is currently not checking for stalled transfers, instead treating them as complete. If a transfer is stalled, don't we need to retransfer?
  38. Y

    USBHost_t36 USB Mass Storage Driver Experiments

    Is the solution to the problem to ensure that all transfers are queued in the isr()?
  39. Y

    USBHost_t36 USB Mass Storage Driver Experiments

    I do need BigBuffer. A tested using several months ago using MIDIDevice, and was the same problem with the hub. I actually came up with a workaround get the hub working again, but not a proper fix. Of course it's a bad thing to do, but it's a hint. With the recent changes to the...
  40. Y

    USBHost_t36 USB Mass Storage Driver Experiments

    Thank-you again for taking the time to test. I've been making posts for months trying to get help resolving these issues, but few seem to really care. Much appreciated. The 'solution' I mention in post #750 is not a real solution. I'm pretty sure removing those lines will prevent the teensy...
  41. Y

    USBHost_t36 USB Mass Storage Driver Experiments

    I've found something. If a delay is added before a transfer is removed from the async followup list, the test completes reliably. Sounds like the issue is might be that we are calling queue_Data_Transfer() while the completed transfer is still being removed? And adding the delay ensures...
  42. Y

    USBHost_t36 USB Mass Storage Driver Experiments

    I suspect if you comment out the lines that queue a transfer in claim() midi.cpp, the hub will denounce properly when you remove the drive. // if an IN endpoint was found, create its pipe if (rx_ep && rx_size <= max_packet_size) { rxpipe = new_Pipe(dev, rx_ep_type, rx_ep, 1, rx_size); if...
  43. Y

    USBHost_t36 USB Mass Storage Driver Experiments

    I just tested with a powered hub and the result is the same.
  44. Y

    USBHost_t36 USB Mass Storage Driver Experiments

    Can you confirm that the device connected to your computer is T3.6 and the speed is set to 180 Mhz? No, I'm not testing with a powered hub at the moment.
  45. Y

    USBHost_t36 USB Mass Storage Driver Experiments

    I also conducted the test with T4.1 as the device connected to the computer, and it ran without issue.
  46. Y

    USBHost_t36 USB Mass Storage Driver Experiments

    Alright. I've found something else. If I reduce the speed of the T3.6 connected to the computer from 180 Mhz down to 96 Mhz, the test always completes.
  47. Y

    USBHost_t36 USB Mass Storage Driver Experiments

    @mjs513 I performed your test as best I could---I was still using T3.6 devices. I performed the test 10 times, each time I power cycled the teensy connected to the computer, leaving the hub, flash drive, and second teensy connected. Out of the ten tests, only once did it complete. while...
  48. Y

    USBHost_t36 USB Mass Storage Driver Experiments

    You're talking about this code? if (stat & USBHS_USBSTS_UAI) { // completed qTD(s) from the async schedule println("Async Followup"); //print(async_followup_first, async_followup_last); Transfer_t *p = async_followup_first; while (p) { //println("ISR: transfer USBHS_USBSTS_UAI")...
Back
Top