MicroMod Beta Testing

Downloaded the latest set of changes.

No change to the way normal and DMA versions work. Same as last revision. With the latest fixes for FlexIO it kind of works but only a few rows on top of the screen are seen and about the bottom 25%. The middle is black.

Tried the 'z' command to capture the last framebuffer but it would hard fault when in the middle of a flexIO continuous loop. Have a feeling need to stop updates - grab the framebuffer and the start again. But I did notice that when you toggle 'F' screen goes black again.
 
Note: I am doing some outside nice day activities, but in the process now of adding a Video mode...

That is I am setting up to do DMA, plus turn on the Async updates in continuous mode, with callbacks (So far only ILI9341_t3n has these).
So when the Screen update for top half screen done, will update that part, with new image, and when Frame completes will update the 2nd half, plus then tell camera to
swap buffers...

Should be fun :D
 
github finally got me the latest update ...

Using ILI9341 the "F" working perfectly and no frame confusion on 'wiggling' hand giving skew!
>> moving images all drawn in phase : No skew or tearing or any anomolies waving hands
>> Seeing :: redraw rate = 10.23 Hz
>> No Hang going between "F" on and "F" off with 'f' single in between ... except stopping "F" with 'f' causes alternate (1 or more - even 6?) black screen images between updates, but "F" on / "F" off / and repeat 'f' works 100% right

@mjs513 : need this change in HM01B0\examples\hm01b0_testv3\hm01b0_testv3.ino for 'f' to stop the 'AUTO' read from FlexIO:
Code:
    [B]case 'f':[/B]
    {
      tft.useFrameBuffer(false);
      [B][COLOR="#FF0000"]hm01b0.stopReadFlexIO();[/COLOR][/B]
//...

With that I can do 'z' DURING "F" without issue - using this ugly dedicated buffer :: DMAMEM unsigned char img[3 * 320*240];
>> There is something amiss that Faults show on 'data bus' with malloc, or it seems @maj513 still sees with 'z' during "F". We are using alternate displays it seems

As noted DMA still powers up a few frames centering and then good, I have not updated CORES.

Not seen view change from CAMERA to Selfie ... i.e. "left" hand displayed on screen right

<edit>: Note 'z' during "F" may not get a stable image from frameBuffer - as it toggles to frameBuffer2
> but it does work here with the ili9341
Made an edit to capture FlexIO current buffer *ptr like "F" uses, if not nullptr.
>> Will see if I can get git to do a PR ...

@mjs513 ... PR worked : github.com/mjs513/TMM-HB01B0-Camera/pull/15
 
Last edited:
Note: I am doing some outside nice day activities, but in the process now of adding a Video mode...

That is I am setting up to do DMA, plus turn on the Async updates in continuous mode, with callbacks (So far only ILI9341_t3n has these).
So when the Screen update for top half screen done, will update that part, with new image, and when Frame completes will update the 2nd half, plus then tell camera to
swap buffers...

Should be fun :D

Just an FYI - I just pushed up a branch with this code, that works pretty well with the ILI9341 display. (Don't have the calls in ST7735 ... Yet).

Pushed up a PR, so people can play... May want to update FlexIO code as well.

Basically the code runs with tft.updateScreen(true) so it is continuous updates. The DMA code in the display has call that allows the user code to be called when DMA completes a frame and optionally when it finishes half a frame. So the code for example sees you finished outputting the first half and starting up the second half, it then updates the other half...
 
Just an FYI - I just pushed up a branch with this code, that works pretty well with the ILI9341 display. (Don't have the calls in ST7735 ... Yet).

Pushed up a PR, so people can play... May want to update FlexIO code as well.

Basically the code runs with tft.updateScreen(true) so it is continuous updates. The DMA code in the display has call that allows the user code to be called when DMA completes a frame and optionally when it finishes half a frame. So the code for example sees you finished outputting the first half and starting up the second half, it then updates the other half...

Merge completed - good timing was doing @defragster's merge. Have to figure out my 9341 - really giving me a hard time working.
 
Merge completed - good timing was doing @defragster's merge. Have to figure out my 9341 - really giving me a hard time working.
Thanks @mjs513

Or do one or both of us need to integrate in code with ST7735_t3? Will take a quick look.

Thinking of ILI9341, has anyone purchased the Sparkfun Input and display Carrier board?
https://www.sparkfun.com/products/16985

I thought about it, but then wondered why this board costs: $60?
Mostly has SD, and ILI9341 display and a few OLEDs...

Likewise has anyone tried the big display carrier? https://www.sparkfun.com/products/17718
$20 has I believe SDIO SDCard, plus HDMI... But their description makes it sound like it an experimental board and no promises.
 
Seems I got that in testv3.

s and c work and D too. Not sure what the deal with SPARKFUN define is failed first time - worked without - then repower it worked turned back on?

d - cont DMA squiggle start worse than before - something tears the timing here on top part of screen?

Will look at "F" version - time for lunch
 
"F" seems to be working in CallBack w/code like DMA

Last run of DMA was torn down left edge after it centered instead of the top?
 
Thanks @mjs513

Or do one or both of us need to integrate in code with ST7735_t3? Will take a quick look.

Thinking of ILI9341, has anyone purchased the Sparkfun Input and display Carrier board?
https://www.sparkfun.com/products/16985

I thought about it, but then wondered why this board costs: $60?
Mostly has SD, and ILI9341 display and a few OLEDs...

Likewise has anyone tried the big display carrier? https://www.sparkfun.com/products/17718
$20 has I believe SDIO SDCard, plus HDMI... But their description makes it sound like it an experimental board and no promises.

Yeah broke down and tested the Sparkfun Input/Display Carrier board. The display is 9341 compatible. Did get it working with the 9341 library but had to add a command - invert display on, then it worked with what we normally use for the 9341 without the need for 2 extra libraries.

That big display looks interesting but does sound experimental - they kind of refer you to the Dazzler for real HDMI - Gameduino.
 
@mjs513 - Noticed the SFun display backlight was on during Pin Testing when it should have been off. Nice the single Teensy lib works and not a pile of others needed.

Saw SPI speed 30 MHz in _t3n - bumped to 60 and no good, set at 40 and it ran and "F" went up to 15 fps - but seems that was swamping the T.MM as lost keyboard input. So back to 30 MHz.
>> Wait it seems 'z' in "F" mode breaks
'z' will be broken more as the callBack code does not use frameBuffer the same way?

'z' is failing now - even after 's' with //SPARKFUN - enable that SPARKFUN and now SD write works? At least with 's'

It seems SPARKFUN enables camera in Selfie mode where left is left in image - yep, no SPARKFUN then in Camera mode Left displayed on Right.

Well as KurtE noted - it is nice out - should go out and get some grass cut in the sunshine.
 
I am looking to update the ST77xx code to allow the callbacks. But it looks like this still has my older variety of updateScreenAsync code for the IMXRT.

Earlier on I was frustrated, with the using of memory from DMAMEM including malloc, which when you did an update the updated data would not make it through consistently So you ended up with issues like parts of updates not making it through. So the code setup DMA from fixed buffers, that I would then copy data into, and would have to process an interrupt every 512 bytes or the like, and refill the buffer from the next section of the real frame buffer..

Later I changed some of the drivers to instead to output similar way as other devices, 2 or 3 DMASettings tied to each other, And simply output. For non-continuous mode, I simply do a:
arm_dcache_flush(_pfbtft, CBALLOC);
At the startup... Which is fine for non-continuous...

Sort of punted on continuous. I am looking to update here to do the same.

Note with the punt, I will probably simply handle it in my callback...
That is I can do something like: arm_dcache_flush(tft.getFrameBuffer(), 320*240*2);
...

Probably will finish tomorrow.
 
Didn't play much today just on and off. As you said it was a nice day. Day is pretty much done here now and they are talking rain for tomorrow so probably will play some more tomorrow.

One thing I noticed is that behavior is definitely different between 9341 and 7789 displays. Unless I missed something loo
 
Good luck @KurtE.

Will keep using the ILI9341 then perhaps swap to the ST7789 when your new work is done.

Not sure what is up with 'z' - it can work - but sometimes just aborts it seems.

Also REALLY odd the malloc mem faults - and that big DMA img is not good at sharing memory.
 
All
Had a strange thought - not sure where it came from must have been a nightmare. With the lack of PSRAM on the MM board is there a way to use the SDIO pins to simulate having a PSRAM and maybe telling the core to use that as EXTMEM? I know is not FlexSPI but was just a thought?
 
Saw the PR to mjs513 was taken -testing:

//#define USE_SPARKFUN 1:
SEEM GOOD :: s, c, D, f, F :: i.e. no signs of tearing or skewing or shift offset in the ILI9341 image
"d" :: (before FlexIO) DMA cont repeated tearing at the top - middle to bottom un-torn - but seeing recurring left to right shift of the whole image.
As noted 'z' is odd, 'p' not tested

#define USE_SPARKFUN 1:
<power off and ON to bootloader w/button- upload and run>
SEEM GOOD :: s, c, D, f, F :: i.e. no signs of tearing or skewing or shift offset in the ILI9341 image
'p' not tested
"d" :: (before FlexIO) DMA cont repeated tearing at the top - middle to bottom un-torn - but seeing recurring left to right shift of the whole image.
'z' only test was to grab the BAD image from DMA: The image saved properly for PC display
>> - "IF" that saved frameBuffer was the one used to display the tearing 'appears' to be on the display


For 'z' to work to capture broken images the data used to display has to be saved. Given A and B buffers maybe we should just save both ...
 
"V" works SO SMOOTHLY! it only works USE_SPARKFUN - comes up Very Dark without a good "Calibrating Auto Exposure" it seems, and at times it comes up iffy for a bit, one time it was running and went more like that odd light image I posted the other day.
> Current run got good calibration and running a good long time - selfie/mirro mode ... it looks like a mirror - no pulsing image redraw!
> Just did the odd brightest areas reflecting off my arm tops and head are shown black or black outlined Calibrating Auto Exposure
- pointing a bright flashlight delineates edges.
"D" came up okay

Just found this sitting in my git folder : Send the 'V' character DMA to TFT async continueous .

Not sure when it came in - but there it was.
 
Saw the PR to mjs513 was taken -testing:

//#define USE_SPARKFUN 1:
SEEM GOOD :: s, c, D, f, F :: i.e. no signs of tearing or skewing or shift offset in the ILI9341 image
"d" :: (before FlexIO) DMA cont repeated tearing at the top - middle to bottom un-torn - but seeing recurring left to right shift of the whole image.
As noted 'z' is odd, 'p' not tested

#define USE_SPARKFUN 1:
<power off and ON to bootloader w/button- upload and run>
SEEM GOOD :: s, c, D, f, F :: i.e. no signs of tearing or skewing or shift offset in the ILI9341 image
'p' not tested
"d" :: (before FlexIO) DMA cont repeated tearing at the top - middle to bottom un-torn - but seeing recurring left to right shift of the whole image.
'z' only test was to grab the BAD image from DMA: The image saved properly for PC display
>> - "IF" that saved frameBuffer was the one used to display the tearing 'appears' to be on the display


For 'z' to work to capture broken images the data used to display has to be saved. Given A and B buffers maybe we should just save both ...

Good Morning all
Just gave our latest set of updates a spin. Tested the same as @defragster and agree all is working well. The only thing not tested was the 'z' command.
 
"V" works SO SMOOTHLY! it only works USE_SPARKFUN - comes up Very Dark without a good "Calibrating Auto Exposure" it seems, and at times it comes up iffy for a bit, one time it was running and went more like that odd light image I posted the other day.
> Current run got good calibration and running a good long time - selfie/mirro mode ... it looks like a mirror - no pulsing image redraw!
> Just did the odd brightest areas reflecting off my arm tops and head are shown black or black outlined Calibrating Auto Exposure
- pointing a bright flashlight delineates edges.
"D" came up okay

Just found this sitting in my git folder : Send the 'V' character DMA to TFT async continueous .

Not sure when it came in - but there it was.

The last PR incorporated from @KurtE included the 'V'ideo command.

Tested with both Sparkfun and non-Sparkfun. Only thing is for DMA video/continuous it does take a while for the image to synch into a image stream which we know. But thats it.
 
Yep - Will hopefully figure out what the syncing up is...

Yesterday, I made a first pass of code editing to ST7735/89 DMA code. Need to start testing.

First need more coffee, and head to town and ...
 
Yep - Will hopefully figure out what the syncing up is...

Yesterday, I made a first pass of code editing to ST7735/89 DMA code. Need to start testing.

First need more coffee, and head to town and ...

Good luck @KurtE. Be interesting see how it works.

Thinking about changing the name of the test sketch in prep for release to: HM01B0-KitchenSink :) Then start breaking some of the code out for demo purposes.

Not sure where we going with the library at this point - support all three methods - normal, DMA and FlexIO? Leave user option on configuration - Sparkfun or non-Sparkfun. I know minor stuff at this point but like thinking ahead and maybe get a jump.

Was also thinking about something I did way back in T4 testing - using the Arducam to take a snapshot and the use CMSIS-NN for image classification: https://forum.pjrc.com/threads/57433-Teensy-4-0-Image-Classification-w-CMSIS-NN?highlight=cmsis-nn. Be interesting if I can get it working with this camera at some point. Or try tensorflow lite
 
I will probably testing soon, had a few diversions this morning.

Like, my updates to FlexIO was incomplete, I was in the process of saying there are 8 timers and shifters not just 4... But some of the tables were not updated for the new sizes, so it was not working.
While I was at it I tested simple Serial Transmit only on MicroMod. Changed it to use pin 4 (D0 on Machine Learning) and Serial3 (RX A1 on Machine Learning) and it worked.

Also started getting ready to play with maybe making a rev of my ILI9341 board with T4.1 and camera , to see how hard to adapt to MicroMod. Did not do much yet.

So far just imported some of the Eagle libraries from Sparkfun into Diptrace. And for example made a copy of their component and made it easier for me to work with:
That is I added the Teensy Pin numbers in () to each of the pins so it is easier for me to figure them out.
Maybe this one I will make bigger like maybe the ILI9488 size... (may add extra gunk) for options. Like duplicate pin out for Adafruit ST... displays as well.
But so far just screenshot.jpg
 
Afternoon all
@KurtE - looks like you been busy this morning and afternoon between the new board design and fixing ST7735 lib. Kind of been a bit distracted with running errands again and in backyard :) Will give it a try and let you know as well.

Will down load and give it a try - was trying something we did with the CSI code but the case statement is giving me a hard time and not sure why. Maybe you can tell me. I am using this case statement:
Code:
     [COLOR="#FF0000"] case 0x30:[/COLOR]
      {
        Serial.println(F("ACK CMD CAM start single shoot. END"));
        send_image();
        Serial.println(F("READY. END"));
        break;
     }
but its only reading it as 0 and not the constant hex. Not sure why. Used to work.
 
@all I just pushed up a new st7735_t3 branch: https://github.com/KurtE/ST7735_t3/tree/t4x_dma_no_copy

With the WIP code, that appears like it might be working on Micromod with the V command.

Note, will need to edit the Kitchen sink and remove the test/error in the sketch (about line 424) and of course configure for ST7789

@KurtE
Just gave your 'V' mode a try with the ST7789 and....
1. Sparkfun config - worked very nicely, however when I exited video mode the TMM was basically hung. Could not enter any other commands and had to do a restart.
2. Non-Sparkfun - Video all broken into different pieces, basically out of synch. Has same problem when you exit video mode - not still experimenting on this one.

UPDATE 1: non-sparkfun. Changed frame rate to 15 and video quality 100% better - shows a little tearing but thats about it. 'd' continuous is seems to be perfect.

UPDATE 2; Sparkfun at 15fps not good - update between frames is really noticeable which is not with the non-sparkfun config
 
@mjs513 does the "case 0x30:" work as "case 48:" ?

I've got outdoor things to do as well. Spring sun is sprouting trees in deck cracks and a pickup firewood to unload.

I did GIT that ST7735 lib ... Would be nice to have a second setup to avoid display swapping $10 SFun cam on a T_4.1? KurtE does all your DMA work have the needed pins for T_4.1 (T_4.0) - and an SPI display?
Seems we all got this - but that goes to the question of how Teensy useful/critical this camera is?
View attachment 24416
 
Back
Top