Sorry, I did not go all the way up on the SS to those pins... I have now...
Exactly.
Pushed up current version to fork of defragsters github project and issued PR
https://github.com/Defragster/EVKB_1060/pull/1
Sorry, I did not go all the way up on the SS to those pins... I have now...
Exactly.
Pushed up current version to fork of defragsters github project and issued PR
https://github.com/Defragster/EVKB_1060/pull/1
Sorry, I did not go all the way up on the SS to those pins... I have now...
Exactly.
Pushed up current version to fork of defragsters github project and issued PR
https://github.com/Defragster/EVKB_1060/pull/1
Sorry, I did not go all the way up on the SS to those pins... I have now...
Exactly.
Pushed up current version to fork of defragsters github project and issued PR
https://github.com/Defragster/EVKB_1060/pull/1
Thanks, @mjs513 (and others), I updated again the dogbone... excel document all of the LCD pins on the right hand side of the
board were filled in. I think it should look like:
Will send the document back to you and/or could try to do PR with...
B0_00 is LCD_CLK, B0_01 is LCD_ENABLE, B0_02 is LCD_HSYNC.
I guess you could have either a 24-bit LCD, or a 10/16 bit camera without running into conflicts. But still, not with the current board due to the missing CSI data pins.
Thanks, @mjs513 (and others), I updated again the dogbone... excel document all of the LCD pins on the right hand side of the
board were filled in. I think it should look like:
Will send the document back to you and/or could try to do PR with...
@KurtE the dev board has all the eCLDIF pins exposed. Starting from B0_00 to B1_13 I believe.
I posted here a few weeks back that I got it working on a 24 bit display with SDRAM.
LCDIF, CSI, and PXP all have their own masters. Their priorities (against each other) are controlled by the SIM_MAIN NIC registers. The documentation hints that LCDIF has a bunch of cache memory tucked away inside of it, that isn't directly...
@KurtE the dev board has all the eCLDIF pins exposed. Starting from B0_00 to B1_13 I believe.
I posted here a few weeks back that I got it working on a 24 bit display with SDRAM.
I think the way they organised the pins was intended for an 8-bit camera connected to CSI and a 16-bit (parallel) display connected to LCDIF. Anything higher in either case and you run out of pins due to them being shared between the modules.
@KurtE the dev board has all the eCLDIF pins exposed. Starting from B0_00 to B1_13 I believe.
I posted here a few weeks back that I got it working on a 24 bit display with SDRAM.
True, I have not really studied the LCDIF as I don't think we have had any boards that have enough pins exported to use. I might take a look
and see if we added the 3 or 5 pins mentioned in yesterdays post about CSI... If both would be covered...
True, I have not really studied the LCDIF as I don't think we have had any boards that have enough pins exported to use. I might take a look
and see if we added the 3 or 5 pins mentioned in yesterdays post about CSI... If both would be covered...
The set up is:
Teensy4.1
Adafruit bmp388 over I2C
openSUSE Leap 15.3
Arduino 1.8.19
teensyduino 1.59
I got a interestring result with the function micros() in combination with one/two do while loops.
The code with OneLoop measures and...
Looks like the method:
int vprintf(const char *format, va_list ap) { return vdprintf((int)this, format, ap); }
Was added last year (May 2023)
Wonder if they should have not put the implementation of it within print.h
but instead into print.cpp...
You're right... the mono code uses 9 blocks while the stereo one uses 10 (maximum). So I increased the audio memory to 11, and it works!
Then, I started to become crazy because increasing the audio memory is the first thing I tried. So, I did a...
They're using LCDIF (and PXP) to output to the display... which is pretty tricky considering the amount of pins shared between CSI and LCDIF... but the main note is they're explicitly not using the eDMA module which is where the slowdown seems to...
Try using AudioMemoryUsage() to monitor how many of the 10 audio memory blocks are used up. Or use AudioMemoryUsageMax() to check whether you have at any point used up all the memory.
My guess, admittedly from only a quick glace at your code, is...
I find it odd that SDRAM is not working well with FlexIO & DMA..
On the original version of the devboard, @Dogbone06 has just standard T4.1 PSRAM, and I was able to use a frame buffer in there with my Micromod 8080 library without any issues...
That was an interesting forum post especially if you read all the way through it. The fix they recommended was basically to change both BCMRX registers to 0x81...
LCDIF, CSI, and PXP all have their own masters. Their priorities (against each other) are controlled by the SIM_MAIN NIC registers. The documentation hints that LCDIF has a bunch of cache memory tucked away inside of it, that isn't directly...
That was an interesting forum post especially if you read all the way through it. The fix they recommended was basically to change both BCMRX registers to 0x81...
@mjs513, looks interesting. Wonder what the differences are from the DMA and non-dma? Other than the obvious. Like when we are not using DMA operation, the new data is written to the cache, and only later, when necessary, it flushes it out to...
I find it odd that SDRAM is not working well with FlexIO & DMA..
On the original version of the devboard, @Dogbone06 has just standard T4.1 PSRAM, and I was able to use a frame buffer in there with my Micromod 8080 library without any issues...
We finally have DMA working properly on the MicroMod and presumably the SDRAM Dev Board (not tested yet). My MicroMod quit while testing the 8080 mode for the ER-TFTM101-1 display. Had to reposition the MCU board in the connector. It's working...
Thanks for the quick response. I can see the code is now using the right (?) library, but the error is still the same:
C:\Users\*****\AppData\Local\Arduino15\packages\teensy\hardware\avr\1.59.0\libraries\ShiftPWM\CShiftPWM.cpp: In destructor...
Hello Paul, thanks for taking the time to answer my question. I have reviewed all the libraries and their respective licenses. For those under the MIT license, everything seems straightforward.
However, with libraries licensed under LGPL 2.1...
Here is the mnimal code (using the original i2s objects) reproducing the problem:
#include <Audio.h>
#include <arm_const_structs.h>
#include <utility/imxrt_hw.h>
#include <SD.h>
#include <SPI.h>
File dataFile;
const int...
Switching back from platform teensy 5.0.0 to older platform with:
platform = teensy@4.18.0
does the trick.
But why does teensy 5.0.0 rise this problem?
Thanks for reminding me about that example. I had already looked at it could not work out what it actually did! I will go back to and rejig it for platformio.
TLDR: https://mongoose.ws/wizard/
This is more like a framework announcement rather than a question.
Some explanation: this is a visual tool for building networking functionality with no experience in network and frontend programming.
The tool...
I find it odd that SDRAM is not working well with FlexIO & DMA..
On the original version of the devboard, @Dogbone06 has just standard T4.1 PSRAM, and I was able to use a frame buffer in there with my Micromod 8080 library without any issues...
Hi,
I get this message building my project under PlatformIO for Teensy3.6 after some package updates.
Project worked before but now build shows:
.platformio\packages\framework-arduinoteensy\cores\teensy3/Print.h:118:62: error: 'vdprintf' was not...
Update regarding this:
Further review of the board showed some left over flux on pins 5 & 6 of the BAS40-05V. (Potentially shorting these pins out)
Measuring the button cell battery attached it is dead (<1v but cannot sustain any load)...
We finally have DMA working properly on the MicroMod and presumably the SDRAM Dev Board (not tested yet). My MicroMod quit while testing the 8080 mode for the ER-TFTM101-1 display. Had to reposition the MCU board in the connector. It's working...
We finally have DMA working properly on the MicroMod and presumably the SDRAM Dev Board (not tested yet). My MicroMod quit while testing the 8080 mode for the ER-TFTM101-1 display. Had to reposition the MCU board in the connector. It's working...