MicroMod Beta Testing

I started a quick carrier board design which brings out the pins and attempts an alternate 4 bit camera connection which should leave all the audio pins available.
Does anyone know the correct distance from the M.2 standoff from the edge of the PCB?

This worked for me (measurement from the connector index hole which is better defined than the card edge...)

Screenshot 2021-04-06 153217.jpg

If gerbers help: https://github.com/luni64/mmStep/tree/main/Production
 
Last edited:
Paul, I assume you have seen all of their stuff on Sparkfun, like the M.2 connectors: https://www.sparkfun.com/products/16549
With their datasheet https://cdn.sparkfun.com/assets/9/c/e/b/6/MicroMod_M.2_Connector_Datasheet_TE_2199230-4.pdf

But I have played around and imported some of their libraries into Diptrace as I don't like Eagle...
I just imported their ATP board and then did a measure... This is in mils

Is this what you are looking for?
screenshot.jpg

P.S Would be great if it had SDIO and USB Host :D

Edit here is from their pattern, I did this one in millimeters
screenshot2.jpg
 
The library says the circle is at x=4 mm (90° turned), the edge of the board at 11mm. 11-4 = 7mm

Normally, dimensions are in mm and this is the case here, too. Some crooked value makes no sense, so 7mm looks reasonable.
 
This afternoon I started playing with the ATP board with the MicroMod... I first hooked up an ST7735 display along with its SD card reader. Got that to work, with the non standard pins. Left pin 10 for CD so it would work with the MTP stuff...

I then added a OV7670 and started hacking on the OV7670 code I have in a hacked up library doing GPIO reads...

Making some progress, Here is a picture. Hopefully I obscured the MMOD module sufficiently...
..
It is grabbing some data, does not look correct, could be timing or wrong pin order or....
One thing I had to remember that was using GPIO6 on T4 or T4.1, but now using GPIO7... Will need to remember that when I change the DMA code.

I have not updated the code on github, but if curious,

Morning all
See you been busy while I was sleeping :) Think we may be having a similar problem with the clock. Playing around with the HB01 I found the cameraReadRegister function was working right when I tried reading the modelId. Using Paul's version worked so that is now what I am using. I also figured out the simple way to display grayscale so have it somewhat working but still no descent image:
IMG-0341.png

Am attaching the zip of the corrections I made
 

Attachments

  • HM01B0.zip
    16.1 KB · Views: 53
@mjs513 Good morning to you as well. I think my clock was doing OK like colors are wrong. I probably need/want to solder on male pins on the outside of the ATP to make it easier to hookup logic analyzer and then I can see the signals.

Also to double check my wiring, that I did not connect wrong pins and/or again double check that the Pins map to the correct GPIO 7 numbers...
 
@mjs513 Good morning to you as well. I think my clock was doing OK like colors are wrong. I probably need/want to solder on male pins on the outside of the ATP to make it easier to hookup logic analyzer and then I can see the signals.

Also to double check my wiring, that I did not connect wrong pins and/or again double check that the Pins map to the correct GPIO 7 numbers...

Well thats good news about the clock. Not sure its a clock problem with me either - I have adjusted the clock frequency up and down and does seem to help. Also tried playing with frame rates. Seems like I fix one thing and another breaks :)
 
I should mention, that I had sort of dropped working on the OV7670 code that was GPIO based and was earlier then spending more times on the CSI version for the T4.1... So may also want to look back at the CSI code to see if I am missing something.

As for Color versus Monochrome, depends on what I want to do. At least to me, very few photos catch my eye as much as a good Ansel Adams Monochrome photo... And for our own stuff we have nice Color camera which is great and also a nice Monochrome one as well. But now back to breaking more things :D
 
Ok, 7mm it is!

Here's roughly what I have for a breakout board with alternate camera pins.

micromod_breakout.jpg

As you can see, I also routed pins 0-23 to a Teensy 4 layout so we can plug in shields for testing.

The 24 pin FFC camera connector is on the bottom side, underneath the SD socket.

Did I miss any pins or other important things?
 
@Paul - looks good. For my own debug stuff I often like the two USB Host pins with spots that I can solder in pins... Makes it easier to hook up LA to see what new devices are doing.
 
@Paul
As @KurtE said looking good. I especially like that you ditched the COPI/CIPO for MOSI/MISO and brought out a 5v pin. Adding the display connector was a great idea. Looks like the SDCard is using the SDIO pins.
 
Use INPUT_DISABLE

Thanks for that.

Busy morning here - the PJRC Carrier board looks good.

Having USB-C would be okay - or better. Assuming using that connector is how the SFun ATP board presents more power to the board?

Using the ATP Carrier the USB_Host can power an external HDD or an unplugged powerable USB HUB/HDD with a Flash device. On a T_4.1 USB_Host neither HDD powers up - though on the HUB/HDD only the connected Flash does show.

Though maybe that complicates the carrier build with some extra part for the higher USB-C current?


Pullups on i2c? ATP doesn't seem to have them but other carriers tend to.
 
@defragster I am guessing, that yes if you went to USB-C you would probably need/want to change what the USB Host power circuit might be.
That is I think the T4.1 and probably this one is using https://www.digikey.com/en/products/detail/texas-instruments/TPD3S014DBVR/5138394

I think this one outputs .5amp...

With the display pins, I am guessing that you are probably looking to have the display go off the end of the board in in your case probable use some mounting board where you would then put stand offs? Alternative is it goes on the backside of this board... In which case you might want holes for standoffs. Assuming it does end up right in the middle of the shield.
 
Suppose SFun ATP docs would show the circuit for their USB-C and power to the board and HOST connect. Maybe too much for a quick/simple board - but it would be nice to have that power - especially with display and HOST capabilities - camera draw likely low ( at least the SFUn cam is low ).
Also previous post noted the ATP layout prevents power feedback from that 'powered hub'.

Yes, quick glance seemed to have Display on MCU side over hanging the PCB - or if on bottom with the Camera connector it would be like opposite the MCU SFun display Carrier - except SFun cabled and taped the display to the PCB, so having a way to stabilize the display would be a nice addition.
 
Suppose SFun ATP docs would show the circuit for their USB-C and power to the board and HOST connect.

Looks like Sparkfun's ATP carrier board lacks any sort of USB host current limiting or even a 100 or 150 uF capacitor.

As far as I can tell none of their other boards do USB host, so they're probably not yet familiar with the requirements for hot plugging USB.
 
Looks like Sparkfun's ATP carrier board lacks any sort of USB host current limiting or even a 100 or 150 uF capacitor.

As far as I can tell none of their other boards do USB host, so they're probably not yet familiar with the requirements for hot plugging USB.

On a 'good' day "unlimited" power is nice :(
> Sounds like your attention will be good for having it made right, as usual.
 
@Paul @mjs...

I am playing now with OV7670 and I know I ran into this also earlier where the VSYNC line is glitchy... If I turn on the glitch filter in LA it does not show it, but turned off I do... I think I need to add that sort of filter into the camera reading code.

Soldered on outside pins on ATP, hooked up LA and I can see first issue:
screenshot.jpg
This image shows maybe a few frames. The top line should be an indicator of where frames start. Notice the glitches. The last line is a digitalWriteFast around the call to read frame... When called the code should synchronize up to start of a frame and start pulling it in. it should have gone through to most likely the end of a frame... So it is not in sync.

Closer up you can see the simple Parallel analyzer converting the 8 signals to values using the pixel clock as the clock.

screenshot2.jpg

Will add in my own glitch filter on the Vsync...
 
Just about ready to give on this camera but you know me I wont

Anyway just to see if the camera really works or not I installed a Sparkfun Artemis Processor Board into the Machine Learning board and loaded up there example sketch. It failed almost immediately on calibrating Auto Exposure.
Code:
Turned on camera regulator
Camera started successfully
Calibrating Auto Exposure...
seems like I am not the only one as there is an issue in the Github library. @Paul you might want to check this post out about the 1.8v regulator: https://github.com/sparkfun/SparkFun_HM01B0_Camera_ArduinoLibrary/issues/3#issuecomment-786766783
 
Yeah tell me about. Seems like I'm doing good since at least I get something. I can't even put a LA on the board to see whats going. And before you ask I can't hook it up to the ATP board since there is no 1.8v regulator on it. On well.

Going have to give you new lib a try tomorrow. Way past my bed time :)
 
Back
Top