@KurtE - @Paul
Just did the same thing and getting the same errors. Could have sworn we fixed those errors a while ago. Wil wait for the PR
@KurtE - @Paul
Just did the same thing and getting the same errors. Could have sworn we fixed those errors a while ago. Wil wait for the PR
@KurtE - @PaulStoffregen
Merge Completed!
No need for warning in the file - @KurtE removed references to extMem_t4 as well.
Thanks Kurt
Thanks. I've pulled in the latest here. I hope to be packing up 1.53-beta3 within the next 24 hours, and a final 1.53 release before the end of this week.
Still on my todo list is bringing in one or both of the native ethernet libraries...
Sorry probably should have done that earlier. Actually I keep meaning to get back to ILI9488 library and maybe see if we can rework how the buffers works, that is we have 3 different versions of the Frame buffer code:
a) 8 bit buffers that use color lookup table to map to 18 bit colors - Uses secondary buffers for the converted data to DMA to screen. (Default for T3.5/6)
b) 16 bit buffers that upshift during outputs to 18 bit colors - Uses seondary buffers... Default now for T4.x
c) 32 bit buffers that are stored in 18 bit (24 bit colors) that do direct DMA without having to muck with data
Currently to switch from b) to c) you have to compile the library with that option, either through editing header file, which effects every project that uses the library on T4.1 and won't then work on those that don't have external memory... There is a hack for __has_include that can enable per sketch, but this has to be stored in some place NOT in sketch... like a bogus library
Would like to create some form of sub-class or run time option to choose the frame buffer type.... But that is beyond this scope
@Paul - Wondering about PR for SPI, that may be needed to make SPI work on T4.x with Snooze... Still other issues.
https://github.com/PaulStoffregen/SPI/pull/59
That is it gives some implementation to SPI.end() for T4.x
Again on T4, not sure best way to leave SPI pins... So punted to use INPUT_DISABLE...Code:void SPIClass::end() { // only do something if we have begun if (hardware().clock_gate_register & hardware().clock_gate_mask) { port().CR = 0; // turn off the enable pinMode(hardware().miso_pin[miso_pin_index], INPUT_DISABLE); pinMode(hardware().mosi_pin[mosi_pin_index], INPUT_DISABLE); pinMode(hardware().sck_pin[sck_pin_index], INPUT_DISABLE); } }
Also still did not fully fix the hibernate issue ...
Side note, which I have not yet put up change for.
The current code does something like:
I then print out the FCR register and it did not take the 15... Finally figured out that is because we have the SPI still in RESET mode, so changing those registers does not take.Code:port().CR = LPSPI_CR_RST; // Lets initialize the Transmit FIFO watermark to FIFO size - 1... // BUGBUG:: I assume queue of 16 for now... port().FCR = LPSPI_FCR_TXWATER(15);
But if I add in:
The delay is probably not necessary... But then the values do take as I took it out of Reset mode... Probably late to add something like this for this release?Code:port().CR = LPSPI_CR_RST; delay(1); port().CR = LPSPI_CR_RRF | LPSPI_CR_RTF; // Lets initialize the Transmit FIFO watermark to FIFO size - 1... // BUGBUG:: I assume queue of 16 for now... port().FCR = LPSPI_FCR_TXWATER(15);
EDIT: Also with the ::end above not sure if it would a good idea to then turn off the clock gate Mask that was set in begin?
Ethernet both work. The NativeEthernet library does require an additional library to be installed. Its dependent on the FNET library. Seems relatively easy to work with. Used it for the temperature measurements with the T4.1.Originally Posted by PaulStoffregen
@manitou's lwio library works as well but I keep forgetting you have to hack the boards.txt file:
so you would have to do something like this (thanks @defragster)Code:// lwip perf // to use IDE hack -I into boards.txt #include "lwip_t41.h" #include "lwip/inet.h" #include "lwip/dhcp.h" #include "lwip/udp.h" #include "lwip/tcp.h" #include "lwip/stats.h"
Code:Added this for this machine to boards.txt: teensy41.build.flags.common=-g -Wall -ffunction-sections -fdata-sections -nostdlib -IT:\tCode\libraries\lwip\src\include
Paul - can you OSH_Share that board? Connections are the same on the RA8876 correct? Assume those extra parts are pullup resistors for SPI pins?
Looking at your shared I see an alternate Ethernet ( oshpark.com/shared_projects/wUFt1emZ ) - the parts layout shows the prior board with surface mount parts instead of the single through hole cap.
Good morning @Paul and @defragster...
The furn of it is for which version of which displays do you have this setup for?
My boards are a little more funky as I set them up to maybe handle a few different configurations.
One reason I am mentioning this is for example if you purchase the 5" RA8875 The board for this has two different connectors:
Disregarding pin headers versus FFC connectors. But unless the board has changed the SPI connections are on the small connector area.
But instead of if you buy the 4.3" display - Then they use the one connector, like you show.... I also think their 7" use this as well.... Don't know for sure as I don't own one.
But this connector is compatible with at least the RA8876 I ordered and I am using.
Doc for this display: https://www.buydisplay.com/download/..._Datasheet.pdf
Also did you do anything special with the MISO pin to tri state it?
Does your breakout setup to also handle the different Touch screen options? Where for example the capacitive touch (I2C connections)? Pins 33-35... I have not played with this part for awhile. Don't remember if this display also have an option for resistive touch instead of capacitive?
But lots of fun!
Sure, here it is.
https://oshpark.com/shared_projects/GQplc8wy
Looks like they've designed most of their displays with the same 40 pin connector pinout. But I haven't specifically checked the RA8876 ones. Best to download the PDF for each and check the pinouts.Connections are the same on the RA8876 correct?
Those 2 resistors are for the I2C signals. I connected them to the pins for the capacitive touch chip.Assume those extra parts are pullup resistors for SPI pins?
I've updated that one with a new photo. I didn't bother with a parts placement diagram, since it has only 3 parts which are very distinct shapes.Looking at your shared I see an alternate Ethernet ( oshpark.com/shared_projects/wUFt1emZ ) - the parts layout shows the prior board with surface mount parts instead of the single through hole cap.
PJRC will soon start selling a DIY kit with this newer PCB, the Cetus magjack, capacitor, headers and ribbon cable assembly. I wanted to make the kit all through hole parts and as affordable as possible (the Cetus part is less expensive), which is why we waited until the newer board was ready.
Yes, it shows now on :: oshpark.com/profiles/PaulStoffregen - didn't show as posted.
Got the CAP touch 7" RA8876 so will skip that and look at PDF to wire one up.
Cool on the lower cost through hole ethernet kit! - yes just one obvious cap to solder. I got boards and parts for the prior UDE SMD assembly.
Let's wait to change the SPI initialization, until after 1.53. Committing a late change to the empty end() function doesn't seem risky, but changing how the hardware it initialized is more risk than I want to commit right now.
Understood, which I sort of figured as well and have not pushed up the change... I did try to remove the clock bit at the end of the end method and did not help the Hibernate code...
So I am out of ideas for helping get snooze work for that test case.
@PaulStoffregen - are you playing on pulling in The spiff library. If so be careful which branch. If you want I can pull it into a separate repository.
Probably not for 1.53. I did bring in NativeEthernet and did some testing with it today.
I have 3 issues remaining on my list, all involving the installer. Was planning to package up 1.53-beta3 soon, which will probably be very close to the final 1.53 release. My hope is to finalize 1.53 by the end of this week. Then I'm going to spend a couple weeks on making a Teensy 4 bootloader chip available. Then back to a combination of documentation and starting 1.54, where I really want to focus on the many filesystem and filesystem-like libraries & features. SPIFFS and which flash chips we'll officially support (hopefully at least one large NAND chip) will probably be part of that filesystem stuff for 1.54.
Good Morning - sorry i missed this last night. Sounds like a plan.
Know its early but any thoughts on which NAND chips you are looking at or what FLASH Chips yet or should I just be patient. Think i know the answer to that one though.
Winbond W25N01GVZE1G
https://www.winbond.com/hq/product/c...artNo=W25N01GV
https://www.digikey.com/product-deta...GCT-ND/7393545
I designed the wide SOIC8 footprint on Teensy 4.1 with alternatively mounting this WSON8 part onto those pads.
Probably best to start a new thread if you want to chat about the details. Perfectly fine to discuss on this forum. But please know I will not be working on NAND flash support until we're shipping Teensy 4 bootloader chips, so don't expect me to be active on that thread. After 1.53, getting a bootloader chip released is my top priority. Realistically, I'll probably also spend some time on much-needed website updates and documentation before getting into improved file & filesystem abstraction and other storage media (the main focus planned for 1.54).or should I just be patient.
@PaulStoffregen
Thanks for the info Paul.
Website updates and documentation have to be first as the site does need some updating. That's going to be a job and a half.
When you dangle little tidbits I get curious and sometimes its hard not to resist asking the question
@PaulStoffregen
Was just using MTP responder with T4.0 and remembered an issue we were have with using MTP above 450 Mhz. Basically above 450Mhz MTP responder would not work. The fix was relatively easy but took a while to find.
@WMXZ found that if you made the following change to usb.c it would work at the higher speeds:
See post #277 in the MTP responder thread.Code:file: usb.c function: usb_transfer_status changed #if 0 to #if 1
Would it be possible to incorporate this into 1.53? I had made the change in 1.52 and was using it about a month and didn't see any adverse affects to USB.
Interesting question and answer on 128 MB NAND Paul and mjs513! There was an NXP email the other day - in following the link there was a NAND setup question - not sure if it has any info not elsewhere.
RE: "See post #277 in the MTP responder thread." - I made that change and MTP worked - wasn't sure of it was turned off for some reason?
Probably should start a new thread for NAND memory.
as for MTP change = that mode wasn't put into the 1.53 core so we have to edit it each time.
Aware 'MTP change' was not and may not be in TD 1.53 - but just adding I also made the change - it is gone now. Just adding note in case Paul knows for sure why that was done and should not be undone - or if it does have a path forward.
Indeed - NAND intro deserves a new thread - of course QSPI Flash - other than SPIFFS - never got much notice or simple examples for use that I saw or tested. But with 16MB to manage TD 1.54 filesystem work should cover that - and the NAND as well for 128 MB of storage.
Received my 7in RA8875 display and hooked it up. Ran the ManyGauge example sketch with a T4.0 at 600Mhz without issue.
Also ran benchmark.ino and FontTest4 with no problem at default SPI clock for the display.
Just wanted to let you know.
Entropy won't compile on my 4.0. I'm using PlatformIO in VS Code so I think it's pulling an old library and I don't really know how PlatformIO works with Teensyduino updates. Is there a link to the latest Entropy library so I can just include it locally with my sketch?
I'm wrapping up 1.53 now. Let's wait just a day or two, then ask Ivan to take a look at why it's not compiling on PlatformIO.
Thanks for testing. My 5 inch RA8875 arrived yesterday. Looks like it has a different pinout, so I'm going to put off testing it for a while. I'm feeling pretty good about RS8875 - certainly good enough to release 1.53.
Posting Permissions
Reply With Quote