Call to arms | Teensy + SDRAM = true
- Thread starter Dogbone06
- Start date
Double row is possible, I hope that we can cut a few pins away to allow for simpler routing. And when you guys make the complete list of pins, you can not which pins should ideally have short traces, and I will abide to that.Merged - can be seen for comment as
EVKB_1060/docs/DogBoneSDRAMv1.xlsx at main · Defragster/EVKB_1060
EVKB for 1062 tests and notes. Contribute to Defragster/EVKB_1060 development by creating an account on GitHub.github.com
@Dogbone06 -, etc:
Wondering if the edge single row might work as a double row for DB_V 5.0 to shorten the pin array for shield creation (p#993) and shorter signal runs? Especially adding a few more pins? Though I see about 16 GND pins in the rows now? Not sure if that helps anything? Maybe a 90 rotated added row across somewhere?
The many grounds and power pins are just to make life simple when testing and because there was room for it.
mjs513
Senior Member+
Trying to figure out how PXP works but it is giving me a headache - I posted something on the PXP thread. Trying to figure out how scaling works to say downsize an image. But all in good time - examples are few and far in between
wwatson
Well-known member
Whew!! Everything seems to be working correctly on all three systems including the last issue which was on the T41 using ASYNC IRQ to display an image. It was exhibiting the same problem as a skewed DMA displayed image. It turned out to be missing checks for a completed IRQ transfer. Added that and it works perfectly.
Here are the links to all three versions of the Ra8876LiteTeensy library:
Teensy 4.1
MicroMod
SDRAM Dev Board
After finishing up these libraries I downloaded them onto another computer and tested all examples. I think most of the bugs are gone.
BUT...
Here are the links to all three versions of the Ra8876LiteTeensy library:
Teensy 4.1
MicroMod
SDRAM Dev Board
After finishing up these libraries I downloaded them onto another computer and tested all examples. I think most of the bugs are gone.
BUT...
KurtE
Senior Member+
I just pushed up a slightly updated Excel document, where I moved the AD_B1_03 pin down into the new pin area at the end of the list. Also fixed some of the color coding, but I know that some more work on this can be done. I already fixed a couple LPUART... ones hae not pushed...
Sorry, hard for me to give much advise on what more that should be added or removed. For me, mostly interested in how it works as an extension to the capabilities of the current released Teensy boards. Like the MMOD has support for CSI, but only has the processors builtin RAM to work with....
As was mentioned if you added in all of the missing AD_B1_XX pins, this would enable CSI on this board. Likewise I believe you already have enough pins to be able to use the LCD subsystem and you have a fair number of FlexIO pins.
What Capabilities each of you want/need from a board like this? For me it would be far more interesting if PJRC was wanting to come out with a board similar to this. Or alternatively, someone like Sparkfun or Adafruit or even a Tindie like offering. And likewise if PJRCis supportive of making the core and libraries more compatible with setting up board variants. As I mentioned before I mostly play with this board using the variant I set up which is not perfect. There are several subsystems, which I did not update, and then there are issues, like you are based off of MicroMod, but there are a lot of MM pins that are now used for SDRAM and/or you choose not to actually include that pin on the board. What should then be done to the Arduino pin table? Do you leave all of the MMOD pins in the table, maybe somehow disable those that can not be used, and add the new pins to the end? Or do you reorder all of the pins?
But more to task at hand: Capabilities this board may support, pins missing to support, or most likely can not support...
SDRAM: I assume you have enough pins for that.
USB: ditto
USBHost: I believe you support this with the 4.5? - Don't know if you have other hardware to support it? That is the T4.1 has power management chip and pin to turn on USBHost...
SDIO: I believe your 4.5 has support for this.
PSRAM/FlexSPI flash storage: I don't believe you can support this? As I believe all of the FLEXSPI2 pins are used by the EMMC.
ELCD: I believe you have enough pins for this?
CSI: the new pins should allow this system to be used.
SerialX: Some of the MMOD Serail pins are not available (EMMC plus maybe other pins not run) But some of the newer pins have Serial capabilities. Should go through and see: How many of the 7 Serial ports that are defined for MMOD work as is. And likewise how many could work...
Edit: looks like some of them should work.
Serial1 uses USART6 RX:0 TX:1
Serial2, USART3, RX:16,45 TX: 17,44
Serial3, USART2, RX:15, TX:14
Serial4, USART4, RX:7, TX:8
Serial5, USART8, RX:21, 39 TX:20, 38
Serial6, USART1, RX25, TX:24
Serial7, USART7 (NO pins except in SDRAM)
Serial8, USART5, RX:60, TX:59
Notes: Micromod does not have Serial8, Usarts for Serial 2 and 4 are swapped between MMOD and Teensy 4 or 4.1,
Some of these pins like 34-39 are in SDIO, only on DB4.5... pins >45 or so are added pins and not in the Cores mapping...
SPI/Wire/PWM/Analog - like SerialX
Audio: ditto
FlexIO: My library has not been updated to use any of the new pins. Might consider updating it to look up by generic names., like I hacked up for the CSI stuff...
FLEXIO1: 0 pins available (all of them are on EMC_XX pins)
FLEXIO2: all 32 pins
FLEXIO3: all 32 pins (With the new pins)
Note: for many of these things, if you are interested in lets say how many GPIO1(6) pins are on this board. You can open up excel on the page,
do a find for GPIO1_ click on the find all, click on the value tab you will see something like:
Which tells you have: 2, 3, 12, 13, 16-31
Note: if the location is on rows less than 45 it is in the EMMC section...
To maybe be continued:
Not sure what details anyone needs here. so probably all for now.
Kurt
Last edited:
KurtE
Senior Member+
Note: I edited the previous post to show the SerialX objects that the DB4.5 plus the 6 pins suggested to be added
(all of the missing AD_B1_xx pins).
For Arduino SPI objects:
SPI is setup to use the LPSPI4 object: With the pins as mentioned: We have a full set of pins:
Sorry got lazy and did not convert these to pin numbers/names.
For SPI1 which uses LPSPI3, we have enough pins that could be used:
Note: The pins 100-102 are some of the suggested new pins for CSI
SPI2 which is LPSPI1:
The ones I marked in RED are in the SDRAM pins. Pins 68-71 are not on DB4, were I believe
added for DB4.5 and are the SDIO pins. And again just bare minimum pins...
So I believe one could experiment with the SPI object to use it in SPI4 bit mode. Like potentially maybe with one
of the chips that one might solder onto the bottom of the T4.1 board.
Given it's a non-production board I think it would be fine to skip the current limiter / ESD protection. The 4.0 devboard works fine in host mode but I always either use a hub or make sure not to hotplug anything directly to the board, just to be safe.
I am ready to make a DevBoard Gen 5, as soon as I get a list of pins. I'll let you guys sort out what functions are needed. My goal is to allow all your ideas to become reality. When I sall "all", I mean all of you who got a Gen 4 board. As you are the elite of the forum that pushes development. And thus together we bring posabilities to the community.
As soon as I get a complete list of pins to use, I'll abide to that list and make 10pcs of gen5 and ship 1pcs to each one of you, free of charge just as the last time.
As soon as I get a complete list of pins to use, I'll abide to that list and make 10pcs of gen5 and ship 1pcs to each one of you, free of charge just as the last time.
KurtE
Senior Member+
Sorry, from my standpoint, not much I can add, I think those of you who are using these boards to potentially create some new products or the like need to finalize.I am ready to make a DevBoard Gen 5, as soon as I get a list of pins. I'll let you guys sort out what functions are needed. My goal is to allow all your ideas to become reality. When I sall "all", I mean all of you who got a Gen 4 board. As you are the elite of the forum that pushes development. And thus together we bring posabilities to the community.
As soon as I get a complete list of pins to use, I'll abide to that list and make 10pcs of gen5 and ship 1pcs to each one of you, free of charge just as the last time.
But: if it were me, I would probably continue with your existing pins plus fill in the remainder of the AD_B1_xx pins, which provides support
for CSI, plus fills in FlexIO3. The ones I believe that are currently missing are in the table below:
| New T5 15/A1 | AD_B1_03 | USB_OTG1_OC | QTIMER3_TIMER3 | LPUART2_RX | SPDIF_IN | ENET_1588_EVENT2_IN | GPIO1_IO19 | USDHC2_CD_B | KPP_COL06 | GPT2_CAPTURE1 | FLEXIO3_FLEXIO03 |
| New T5 | AD_B1_04 | FLEXSPIB_DATA03 | ENET_MDC | LPUART3_CTS_B | SPDIF_SR_CLK | CSI_PIXCLK | GPIO1_IO20 | USDHC2_DATA0 | KPP_ROW05 | GPT2_CAPTURE2 | FLEXIO3_FLEXIO04 |
| New T5 | AD_B1_05 | FLEXSPIB_DATA02 | ENET_MDIO | LPUART3_RTS_B | SPDIF_OUT | CSI_MCLK | GPIO1_IO21 | USDHC2_DATA1 | KPP_COL05 | GPT2_COMPARE1 | FLEXIO3_FLEXIO05 |
| New T5 | AD_B1_12 | FLEXSPIA_DATA01 | ACMP_OUT00 | LPSPI3_PCS0 | SAI1_RX_DATA00 | CSI_DATA05 | GPIO1_IO28 | USDHC2_DATA4 | KPP_ROW01 | ENET2_1588_EVENT2_OUT | FLEXIO3_FLEXIO12 |
| New T5 | AD_B1_13 | FLEXSPIA_DATA00 | ACMP_OUT01 | LPSPI3_SDI | SAI1_TX_DATA00 | CSI_DATA04 | GPIO1_IO29 | USDHC2_DATA5 | KPP_COL01 | ENET2_1588_EVENT2_IN | FLEXIO3_FLEXIO13 |
| New T5 | AD_B1_14 | FLEXSPIA_SCLK | ACMP_OUT02 | LPSPI3_SDO | SAI1_TX_BCLK | CSI_DATA03 | GPIO1_IO30 | USDHC2_DATA6 | KPP_ROW00 | ENET2_1588_EVENT3_OUT | FLEXIO3_FLEXIO14 |
Not sure if there are low hanging fruit for other pins to remove, as again depends on what you are needing for whatever projects you are
trying to do.
mjs513
Senior Member+
I agree from what I remember and posted before.
BriComp
Well-known member
I would like to add my two-penneth.
As I see it groups of pins have many particular functions.
Might it not be a good idea to also route the pins to functional connectors. It is likely that some connectors will have an overlap of pins. That does not matter.
If the pins required for a certain display happen to overlap with those for FLEX-IO so be it (I am not saying they will, I am just putting forward a hypothetical situation).
Think of some potential uses for the board and route the pins to additional connectors such that the uses might be more easily achieved.
I am assuming that all the connections will come out to one (or two) lines of pins. What I am suggesting is further connectors which are use specific.
As I see it groups of pins have many particular functions.
Might it not be a good idea to also route the pins to functional connectors. It is likely that some connectors will have an overlap of pins. That does not matter.
If the pins required for a certain display happen to overlap with those for FLEX-IO so be it (I am not saying they will, I am just putting forward a hypothetical situation).
Think of some potential uses for the board and route the pins to additional connectors such that the uses might be more easily achieved.
I am assuming that all the connections will come out to one (or two) lines of pins. What I am suggesting is further connectors which are use specific.
KurtE
Senior Member+
I totally agree with @BriComp that it would be great.
However, if that is not feasible or too many options. As long as the boards are reasonably laid out and preferably as I mentioned earlier, I would create a quick and dirty shield that does the things I want.
Today, for example I assembled I slightly updated board I did for the T4.1, to test the cameras using CSI. I also did a quick and dirty shield that plugged into a Sparkfun ATP board with the Micromod for testing a whole lot easier to test:
Assuming all of the pins mentioned are on it. I would probably end up with two 20 pin Camera connectors,
one for CSI, the other for FlexIO.
Would probably have display connectors for ILIxxx TFTS, plus one for Adafruit like display...
Might look into what type of setup to use the ELCD subsystem. or maybe parallel display? ...
But others probably have other ideas of what they would like to do.
However, if that is not feasible or too many options. As long as the boards are reasonably laid out and preferably as I mentioned earlier, I would create a quick and dirty shield that does the things I want.
Today, for example I assembled I slightly updated board I did for the T4.1, to test the cameras using CSI. I also did a quick and dirty shield that plugged into a Sparkfun ATP board with the Micromod for testing a whole lot easier to test:
Assuming all of the pins mentioned are on it. I would probably end up with two 20 pin Camera connectors,
one for CSI, the other for FlexIO.
Would probably have display connectors for ILIxxx TFTS, plus one for Adafruit like display...
Might look into what type of setup to use the ELCD subsystem. or maybe parallel display? ...
But others probably have other ideas of what they would like to do.
mjs513
Senior Member+
Would agree as long as the edge pin connectors are suitable to add a adapter on top it would be better. This is the adapter I made for the sdram board (note positions are off for the display and camera - have to move them fo the next iteration).
The idea is to make the gen5 to have the pins needed, then from that I have already planned to make a shield for the two screens that @Rezo has in his possesion. Other shields can be done by you guys as well. And of course the Gerber files and all will be shared here for the gen5 as well. So that it's easy for you to make the shield with the correct spacings and such.
mjs513
Senior Member+
Oh just one more thing, Would be nice if you could maybe substitute a couple 5v pins for the 3.3v pins. Would make it easier when creating a shield.
Not exactly sure what you mean, the Devboard has many power pins. I think that you mean that a few of them should move over to the shield right? Anything like that is fully possible.
I would be greatful if someone could make a "todo" list, what pins to add, what other things to add. I will do that as I want to try to please everyone in the project.
mjs513
Senior Member+
Thats exactly what I mean. Route a couple to the 1x40 header so a shield can get access.
As for a todo list. As far as I know @KurtE gave it to you in post #1009:
| New T5 15/A1 | AD_B1_03 | USB_OTG1_OC | QTIMER3_TIMER3 | LPUART2_RX | SPDIF_IN | ENET_1588_EVENT2_IN | GPIO1_IO19 | USDHC2_CD_B | KPP_COL06 | GPT2_CAPTURE1 | FLEXIO3_FLEXIO03 |
| New T5 | AD_B1_04 | FLEXSPIB_DATA03 | ENET_MDC | LPUART3_CTS_B | SPDIF_SR_CLK | CSI_PIXCLK | GPIO1_IO20 | USDHC2_DATA0 | KPP_ROW05 | GPT2_CAPTURE2 | FLEXIO3_FLEXIO04 |
| New T5 | AD_B1_05 | FLEXSPIB_DATA02 | ENET_MDIO | LPUART3_RTS_B | SPDIF_OUT | CSI_MCLK | GPIO1_IO21 | USDHC2_DATA1 | KPP_COL05 | GPT2_COMPARE1 | FLEXIO3_FLEXIO05 |
| New T5 | AD_B1_12 | FLEXSPIA_DATA01 | ACMP_OUT00 | LPSPI3_PCS0 | SAI1_RX_DATA00 | CSI_DATA05 | GPIO1_IO28 | USDHC2_DATA4 | KPP_ROW01 | ENET2_1588_EVENT2_OUT | FLEXIO3_FLEXIO12 |
| New T5 | AD_B1_13 | FLEXSPIA_DATA00 | ACMP_OUT01 | LPSPI3_SDI | SAI1_TX_DATA00 | CSI_DATA04 | GPIO1_IO29 | USDHC2_DATA5 | KPP_COL01 | ENET2_1588_EVENT2_IN | FLEXIO3_FLEXIO13 |
| New T5 | AD_B1_14 | FLEXSPIA_SCLK | ACMP_OUT02 | LPSPI3_SDO | SAI1_TX_BCLK | CSI_DATA03 | GPIO1_IO30 | USDHC2_DATA6 | KPP_ROW00 | ENET2_1588_EVENT3_OUT | FLEXIO3_FLEXIO14 |
This is addition to the pins you already have on the board.
KurtE
Senior Member+
Again I am not the expert on what every one wants... However if it were me I would probably do something like:
Note: this is a mucked up version of the page. Yellow areas show the existing AD_B1_xx pins.
The 6 Orange cells near them, I would add in the 6 missing AD_B1_xx pins as mentioned before.
I would probably also change a couple of the GND pins to +5V I show a couple of the GNDs at upper left as maybe.
Also if it were me, the pins on the right hand side of the board, that have MMOD pins (I show those in black) would be really nice if
pin numbers were shown on the board as well format of it... leave to you like B1_00(10) or B1_00/10
Would be nice if the ones in red or new ones were also given numbers... Then will muck up a variant with them, to use.
But again that is just me.
Edit: Also, if it were me, I might do things like shrink the board some and/or double rows. But the above shows
what I think are the minimal changes to add the CSI pins.
Last edited:
mjs513
Senior Member+
I agree = double rows would probably make it more difficult to connect a adapter shield
KurtE
Senior Member+
I can argue both ways and sometimes I even answer myself
like, larger boards like this where the pin locations are sort of random implies long tangled jumpers, which I get tired of fighting , so end up making shields. Larger boards, more expensive the shield, which I tend to screw up at least the first time. But I know I am probably the only one that does that.
I also agree that a lot of double rows can be a real pain, especially with shields you want to connect and later disconnect without breaking the shield.But Arduino does make boards like mega, due, GIGA, with some double connector.
I personally don’t care either way, I thought someone suggested it earlier, so I mentioned…
personally I wish the board had connectors for camera, one CSI other flexio. Connectors for display like ili9341, RA8875/6 both spi and eLCD… but maybe asking for a little too much
defragster
Senior Member+
@defragster put that (or adding a single 90° Cross row) out wondering if the denser pin presentation would better fit 100mm (?) limit on low cost 'machine made' boards and limit the wire length for physical wires as well.
The (image above p#1018) right side is just ~32 port pins - but the left has ~15 GND intermixed. Perhaps minor shifting for new added pins and 5.5V is all that is needed.
mjs513
Senior Member+
@Rezo asked on the PXP thread if I tested on the SDRAM board. When last night and this morning did some timing tests using a HM0360 camera and a ILI9488 (SPI) display at QVGA resolution.
Well before I show the timings there is definitely something off. If I use RAM/DMAMEM to capture an image it works fine:
When using SDRAM for both buffers:
There is definitely a color shift - white areas look yellowish (most obvious)
Now for the timings
UPDATE: see this post on more timing comparisions for non-camera images.
Note: running sdram at 198Mhz and EXTRAM at 132Mhz,
Well before I show the timings there is definitely something off. If I use RAM/DMAMEM to capture an image it works fine:
When using SDRAM for both buffers:
There is definitely a color shift - white areas look yellowish (most obvious)
Now for the timings
Code:
Teensy 4.1
Source/Dest Buffer: xxxxx
==========================================================================
Extmem/Extmem: Capture time (millis): 175, PXP time(micros) : 89, Display time: 63
DMAMEM/Extmem: Capture time (millis): 199, PXP time(micros) : 89, Display time: 62
DMAMEM/RAM: Capture time (millis): 195, PXP time(micros) : 32, Display time: 62
RAM/DMAMEM: Capture time (millis): 141, PXP time(micros) : 56, Display time: 61
SDRAM DEV BOARD
==========================================================================
SDRAM/SDRAM
Capture time (millis): 152, PXP time(micros) : 89, Display time: 61
Capture time (millis): 236, PXP time(micros) : 89, Display time: 62
RAM/DMAMEM:Capture time (millis): 156, PXP time(micros) : 57, Display time: 62UPDATE: see this post on more timing comparisions for non-camera images.
Note: running sdram at 198Mhz and EXTRAM at 132Mhz,
Last edited:
KurtE
Senior Member+
AFAIK...
Sorry, I should have looked it up, but was at car dealer having service done and replying on phone...