Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Standard Discussion #2

Open
arturo182 opened this issue Oct 24, 2020 · 31 comments
Open

Standard Discussion #2

arturo182 opened this issue Oct 24, 2020 · 31 comments

Comments

@arturo182
Copy link
Collaborator

I guess might as well post some random ideas/observations, to start the discussion, they might be a bit chaotic ;)

  • The terminology should be catchy and easy to understand, like Feather - FeatherWing
  • The carrier connector should be well documented, it seems m.2 has multiple connector configurations, both in the number of pins and notch location. The MicroMod connector is a TE 2199230-4, I'm also ordering a few LOTES APCI0108-P001A connectors from LCSC to confirm that they are a compatible cheaper replacement.
  • The dimensions of the processor board should be well defined, including the location and the size of the lock screw.
  • Speaking of dimensions, also the constraints should be defined, is the processor board allowed to be wider or longer as long as the connector and pinout are compatible?
  • I think having multiple allowed lengths of the processor board would be a good idea, as the current micromod spec of 22x22 mm limits the actual usable size to 22x15mm (because of the screw cutout), it would be nice to be able to have at least a 20x20 square.
  • Multiple lengths could be done by having the carrier boards have multiple standoffs like computer motherboards:
    image
    This however poses a problem where there might be some places on the back of the processor board where taller parts could not be placed because they would collide with the standoffs (Like if you used the 3rd standoff, the first 2 would be under the board and in the way)
  • For the pinout, having an option to have JTAG pins (instead of or in addition to SWD, TBD) would make the spec more attractive to the FPGA community
  • Would be nice to at least try to agree on which GPIOs are used for specific functions, so example code would be more portable. For example, if all LCD-having carriers used the same GPIO for LCD "DC" pin, or same GPIO for a Neopixel.
  • Having ready-to-go symbols, footprints, and templates for KiCad, Eagle, EasyEDA, etc. would make it a lot easier for people to use the spec.

I know this might look like a list of demands, but these are just my thoughts so start a discussion, and I'm open to changing my opinion on many of the items above, so let's get talking!

@skerr92
Copy link

skerr92 commented Oct 24, 2020

I think this is pretty thorough, and pretty reasonable especially in regards to potential issues with providing the three size options.

What I would like to see is how we might use this standard as well to enable broader use of m.2 for expansion boards similar to the breakout modules we would over i2c (Stemma/Qwiic) and SPI.

Perhaps what can we do to ensure breakout m.2 modules provide the same connectivity across brands and products.

I like the idea of having a core m.2 with my favorite MCU and a bunch of additional m.2 that I can plug in a Wifi module, environmental sensors, etc..

@Tonymac32
Copy link
Contributor

Terminolog, well, look at my boards I am not good at names. 🙂 The only thing that pops into my head seeing an M.2 get installed is "shingle", which is awful. 😆

Connectors: defining the key should be sufficient. You are correct that there are many. I propose 2 keys initially, 1 for processor modules, and one for peripheral modules. I think this decision should go hand in hand with pinout, as the keys obviously displace pins.

For board layout I guess my first thought would be to start with the M.2 mechanical specification (22 mm wide with predefined lengeths IIRC), adding constraints for what key goes with what module, and if we are to propose allowing connectors on the modules themselves. If we can agree on use cases that won't be able to fit the 22, then a careful discussion about the absolute maximum width should happen, being careful to avoid overburdening the carrier boards with empty footprint area. (Single board computers often demonstrate this well, having allowed footprint for physically large RAM and then using small ones)

For the edge fixation, I see some offsets going on with different designs, to avoid fitting into official PC M.2 slots that's probably wise. This could in theory address the Processor/Peripheral keying without disturbing the connector as well, have then be mirrored perhaps.

@tjaeger
Copy link
Contributor

tjaeger commented Oct 24, 2020

For the sake of baseline Info. M.2 i specified by PCI SIG and not only defines mechanical specs but also electric and use cases.
For the Form factor there is a set of specs - which i think makes sense to generally adhere to.
Any limitation here imposes limitations to the maker.

I think it also has to be clear that this is not "M.2 (PCISIG)" compatible (dont screw it in your laptop) but rather utilising the mechanical footprint.

Ideally there is a set of "recommended" sizes, eg 22x30, 30x30, 22x50- Carrier boards should mention what sizes can fit.
I'd recommend only 2 lengths (eg 30 and 50) to limit the number of standoff locations and rather add some options for width.
I recommend ONE key (eg KEY-E) as a standard, otherwise the "key" constraints the use-case. A user shall have all options to put on the module whatever is supposed to go there (MCU only, Display only, MCU and Sensor etc).

PIN assignment should be strict as needed and flexible as possible.
like:

    • Mandatory (eg power)
    • Recommended (eg one I2C)
    • Optional (SPI, 2nd I2C etc)
    • User-defined (but no power!)

Looking at PCISIG pin assignment at least "critical pins" (eg PWR) should be copied, to avoid damage if one plugs this into a Laptop.
I think it makes sense to adhere to whatever is in the standard and if needed (eg 3V3/GND, DpDn locations, RXTX, I2C etc)
image

@arturo182
Copy link
Collaborator Author

I believe the idea is to stay compatible with Sparkfun's MicroMod, so no changes to the pinout or connector type could be made, but I think @ptorrone would have to clarify the intention here.

@nitz
Copy link
Collaborator

nitz commented Oct 24, 2020

I definitely feel it would be in not only our interests, but the community as a whole to stay compatible with MicroMod as much as possible. I personally had imagined expanding on the MicroMod pinout with secondary and tertiary pin functions in the same way you'd see an arduino compatible do with different features any particular pin would have.

If there has to be a variant or deviation that wouldn't be compatible, the offset of the screw cutout could be flipped to the other side of the board, thus usable as a second "keying" to not only denote the variation but prevent incompatible connections. Obviously this would be less than ideal as it would be a complete fork, so I'd hope to avoid such a thing if possible.

@folknology
Copy link

We should also take notice if the Makerdiary spec, they seem to have stuck with the M2 E-Key electricals. There is also the IOT M2.com and their design a good source of information

@timonsku
Copy link
Collaborator

timonsku commented Oct 24, 2020

I agree with @arturo182 points in terms of features, especially keeping in line with the M2 size options would be nice. I very much agree with @tjaeger point of having basic electrical compatibility to M.2 but checking the MicroMod standard and the M.2 Key E (and possible other keys) it seems that they luckily went with that decision as well and have stayed compatible to M.2 which is very good news because that gives us freedom to change things but stay at least compatible with the basics like power and IOs. Even their position of USB2.0 is the same as with M.2

The biggest issue with the MicroMod standard is that it's super specific to the purpose of pins.
In my opinion a standard like this should only define the electrical characteristics like power and IO voltage and only have a fixed position for very specialized IO like USB that is usually not muxable freely on chip.

Once that is defined (and I don't think there is much to do) I would add official suggestions for bus positions. That could happen in different profiles so that there is maybe 1-2 MCU profiles/alt functions and an FPGA profile that defines where things like SerDes should be positioned.
That way we have a common baseline but just like with Feather you can't always guarantee every bus is available on any given chip so its ok to leave things out but if you have it you have a guideline telling you where to put stuff to stay as compatible as possible.
Having flexibility is I think much more valuable than enforcing perfect compatibility and just shutting out a huge a mount of hardware.

(maybe we can rename this issue to "Standard Discussion" or so?)

@ptorrone
Copy link
Member

boards

ok! here's a start of the maker boards, please add boards that are missed, links to compatibility or not, etc.

https://github.com/adafruit/M.2

@ptorrone ptorrone changed the title Random thoughts Standard Discussion Oct 24, 2020
@folknology
Copy link

folknology commented Oct 25, 2020

In order to find a way through this we need to understand what's out there and try to find the best solution for all possible. In order to help this process I started a public spreadsheet with all the known pinouts side by side to make things easier to see and work out. This needs to be a group effort, please fill in the blanks and add any missing pins or new columns etc.. If you find a mistake correct it and add a note to the comment history (only if you need to), have fun :
https://docs.google.com/spreadsheets/d/1Y1rSo8eR6aVXJpc8Yw2x1O7Ea9YH3B0ZWHGSv71AJ8k/edit?usp=sharing

@timonsku
Copy link
Collaborator

See also the commit from @flummer he did the same thing in markdown. I think thats better to stay in git for collaboration.
https://github.com/adafruit/M.2/blob/main/comparison.md

Just for reference here is the official M.2 mechanical and electrical spec by the PCI group:
http://read.pudn.com/downloads794/doc/project/3133918/PCIe_M.2_Electromechanical_Spec_Rev1.0_Final_11012013_RS_Clean.pdf

@flummer
Copy link
Contributor

flummer commented Oct 25, 2020

It's nice with colors in the Google sheet, but I like the version tracking etc. that it gives when part of the repo. I pasted 4 columns from the .md file into the Google sheet, but it will likely get tedious to keep them in sync manually ;-)

Options for colors in the markdown file:

  • Adding HTML with CSS (lots of noise in diffs, etc.)
  • Adding colored dots emoticons (a bit of a hack, but cleaner in source form)

@arturo182
Copy link
Collaborator Author

Limor and pt discussed this repo on the stream a few minutes ago: https://youtu.be/46zAO_3-ozY?t=781

@Tonymac32
Copy link
Contributor

Went ahead and made a PR to add the PCI group Key E pinout to the table for a base reference. One thing I saw was a reassignment of grounds for I/O, specifically in the high-speed area of the connector. Ground separated differential pairs aren't entirely uncommon, should be a discussion point.

@Fabien-Chouteau
Copy link

I will probably be off-topic here, but I would be much more interested in a Molex SlimStack kind of interface:

https://www.molex.com/molex/search/deepSearch?pQuery=productname%253A%2522SlimStack%2522%2540pitchmatinginterface%253A%25220.40mm%2522

  • Smaller footprint
  • no need for screw

@flummer
Copy link
Contributor

flummer commented Oct 26, 2020

It's interesting to look at the rated durability of this type of connectors:

  • TE M.2 (eg. 2199230-4) is rated for 60 cycles
  • Molex SlimStack (eg. 513380674) is rated for max 30 cycles

For production or finished projects, those numbers are probably not a problem, but for development it might be pushing it a little.

@nitz
Copy link
Collaborator

nitz commented Oct 26, 2020

We use the Molex SlimStack on several products at my day job. While they definitely work great in many applications, they have some pretty glaring drawbacks that don't meet a lot of what I look for from my hobby side of thinking:

  • Like @flummer mentioned, they're definitely rated lower cycles. They don't come nearly as close as what some of the M.2 ones can with the right plating. (That said, I've definitely got more than 30 cycles out of them)
  • The products we use them on have all been in a case (3D printed, Injection molded, or otherwise.) Bare boards on my desk, they have a tendency to pop out even from just a slight jostle. In a case that accounts for it, that's not a problem, but that's not always a luxury from the enthusiast PoV. The screw is half the draw to me of the M.2, as that is basically a guarantee that your daughterboard isn't going anywhere.
  • Requires two connectors. Since it's a pair of mating connectors, both the host board and daughterboard have to have a (non-identical) connector. This means someone working on their own daughterboard would have to solder a connector with very fine pins in order to use it, vs what is mostly a footprint that would require no soldering.
  • Related to above: cost. Two connectors are just going to drive up prices of both sides.
  • I'm quite sure that the Molex ones like that take up a larger footprint than the typical M.2.

@ptorrone
Copy link
Member

good stuff, did some updates
https://github.com/adafruit/M.2

boards2

@timonsku
Copy link
Collaborator

Fur durability of the M.2 also keep in mind that these spring contacts are overall very durable. That durability rating keeps in mind the full spec which offers a multi GHz interface. So PCI-e might not be guaranteed anymore after 60 cycles but when it comes to power and lower speed signals these connectors will last hundreds if not thousandth of cycles.

@timonsku
Copy link
Collaborator

@ptorrone It would be interesting to hear from limor and you how much interest you actually have in getting in on a standard like this. None of these are the same and like Arturo said to me earlier, you have a bit of a choosing power here which direction the community goes. That is if "we" stay mostly compatible with one of them and liberate it a bit to work in more circustmance that work well for most in the community.
Right now its a bit unclear to me if you just like to document these or also want to get in on it :)

@ptorrone
Copy link
Member

@PTS93 we did a video last night about the m.2 https://youtu.be/46zAO_3-ozY?t=780

i'm interested in what the community wants to make with m.2 form factor boards.

if/when we (adafruit) make something, it will be the most compatible and we'd contact the current makers to see if they're interested in working together on a standard (and will document it here, etc).

@timonsku
Copy link
Collaborator

Great. What would be most valuable to hear for you from our side as users and or makers of hardware that would use such modules?
Currently we all very much focus on the pinout itself but I guess we don't have much of a use case discussion yet. (Maybe that should be a separate issue.)

@ptorrone
Copy link
Member

@PTS93 what would be good to know is what users would want to use/make with these, some example projects that are waiting for a m.2 board, and from the makers of hardware... what they/want need from partners that could make all this work. sounds like 2 separate threads, each useful and will help each other.

@flummer
Copy link
Contributor

flummer commented Oct 26, 2020

When I look at the pinouts, it seems like:

  • The Google board follows PCI spec and will likely work in a computer, and I have a feeling that is also the intended use case.
  • The makerdiary board also follows the specs relatively close, puts SWD on a few vendor pins, and have some high speed diff lines as reserved.
  • The boards from Particle seem to have their very own pin distribution, only pin 1 and 7 have matching GND and stuff like USB isn't on the PCI spec pins.
  • The Sparkfun pinput follows some of the PCI spec, maybe enough to not catastrophically destroy stuff, but it seems like they wanted to have a lot of signals like CANbus, audio and USB host and I guess they ran out of vendor pins.
  • The SNAPZZ board have a lot of NC pins and I think the rest could have been following PCI spec but only a few does.
  • I think the WRTnode does follow PCI fairly close, but it's the B key
  • The Sipeed one seems to be 5V, so that is likely also a bit off.

@Tonymac32
Copy link
Contributor

Tonymac32 commented Oct 26, 2020 via email

@arturo182
Copy link
Collaborator Author

arturo182 commented Oct 27, 2020

I think as many peripherals as possible should be specified; we are trying to create a standard after all, and if boards can just put their peripherals wherever they wish, then what's the point of a standard. I want to be able to put 3 different modules in a carrier with an SPI LCD and be confident they will all work.

Like I said in the first post, I'd go as far as to have the standard suggest which GPIOs should be used for things like LCD DC or Neopixel because with Feathers, even though it's not a part of the standard, it's now very common that the LED next to the USB connector is D13, LCD DC is D10, LCD CS is D9, SDCard CS is D5. This is great because the same example code can be used between multiple boards, and it just works.

I think making the standard require all processor boards to be 5V-tolerant would be quite a burden on the processor board creators since most ARM MCUs are 3.3V and not 5V-tolerant so you'd need level shifting. It's probably better to leave that to the carrier boards if they wish to have 5V stuff on them.

As for making the "final" choice, it seems we have a bit of a circular dependency. I, as a maker, would like to make the selection based on the popularity of the standard, so I'd wait for Adafruit to make a decision which one they want to go with, but Adafruit wants to wait for makers to start making boards so Adafruit can see which one is the most popular one and go with that. Circular 😅

I'm not sure what's the best way to proceed; I like the summary from @flummer. If we go by the process of elimination, then Sipeed and WRTnode would be out cause one is wrong voltage, the other is the wrong key. That leaves us with five options. I'm not sure if compatibility with the computer PCI spec is a priority or even desired; it seems Sparkfun put the screw notch off-center to explicitly show that a MicroMod should not fit in a PC, and maybe that's actually a good thing; it's a foolproof way to show the incompatibility.

One more thing that should probably be looked at when considering the standard is the commitment from the creators of the existing solutions. Is the Google board just a one-off, or are they planning to continue creating more similar modules? I can't really speak for other companies, but looking at the way Sparkfun announced the MicroMod, it does seem they see it as the future of their embedded designs, and they will most likely follow with more processor and carrier boards and accessories for them in the near future. You have to have the critical mass to have an ecosystem.

@Tonymac32
Copy link
Contributor

There is always a careful line to walk with standards. Too strict is just as bad as too vague. In this case my feeling is to clear up the power/ground requirements, then define what the minimum set of peripherals should be and their associated pins, which I was giving a proposal for what that minimum list might look like. A proposal could be to have the Feather pins be that minimal peripheral set, perhaps. And certainly not define anything in hardware that can be handled in software.

For 5-volt tolerance I would only propose a subset of pins, certainly not all, because yes, that would require level shifting. That brings me to a point I forgot to make earlier, there should be optional pins, meaning they are not required to be populated. An ESP32 for example can not fill that connector, neither can most M0 or M3 micros, etc.

  • This also highlights a need to frame carrier vs processor board.

For "Final" choice, I don't think there should be one anytime soon. I think we should draft an "initial" choice and discuss it. Otherwise yes, the situation is circular 😄

PCI spec compatability: non-essential. Basic power-ground and high-speed lane spacing is nice as a pattern. Compliance to the point of allowing interoperability with what exists as best as possible is as far as we should take that.

  • The off-center notch in the Sparkfun is certainly a good idea in my opinion, to keep someone from slapping one of these in a laptop

Creator commitment: Agree. Sparkfun has 3 processor boards and 3 or so carriers. The others appear to be 1 each so we would ideally find out from them what their future intentions are to help weight the compromises needed to make more work.

So, are we in favor of starting a draft of a specification to begin discussing something a little more solidly? I think Adafruit will follow whatever we dream up if it is reasonable and they're interested.

@Electro707
Copy link

This is just my 2-cents, but I think that the standard should include some basic peripherals as mentioned (even some more like LCD, I2S, CAN, etc). More importantly tough each pin should have a specified direction. I could see a case where a module with a given program is taken out of one motherboard and put into another, and without pin directionality in the standard the module/motherboard could cause one to fry (if one is outputting 3.3v while the other is outputting 0v on startup), especially for the general purpose pins.
As for power, due to most ARM processors only tolerating 3.3v that should be the standard for I/O pins, but the module should be made to tollerate 5v for it's power input.
This next point is specific, but for I2C (or any protocol the requires pull-up resistors) the pull-up resistors should be on the module board. Not sure if that applies to this standard tough, just figured I should mention it.

@timonsku
Copy link
Collaborator

The power input to the module should definitely not support anything other than 3.3v, that would otherwise completely defeat the purpose and be in-compatible to absolutely any standard out there so far that uses the E Keying.

@Mynasru
Copy link

Mynasru commented Feb 1, 2021

Before Sparkfun released their MicroMod standard, I was working on a similar modular system using M.2 with different keying for different type of modules (e.g. MCU, modems, sensors). In the end I'm just using Micromod for the MCU and custom baseboards for the specific aplication. The only thing I'm realy missing is more definitions of board sizes. And it might be nice to make a Micromod+ standard for more powerfull MCUs or FPGAs with differential pairs etc.

@samuk
Copy link

samuk commented Jan 18, 2023

I'm designing a MicroMod carrier for a robot project

I intend to use Sparkfun pinout & 2230 nut placement dimensions, but additionally, allow space for 3030 & 3042, and provide an additional mounting hole for 2242/3042

standard

Once that robot has reached v1 I may then

  • Do an ESP32 in the 2242 package size as cheaply as possible
  • Edit this Feather/Thingplus board to accept either 2230 or 2242
  • Do a 2242 carrier board in the dimensions and pinout of the ESP32-DEV-C

Any help with that would be great, If Adafruit were to put out an ESP32 in 2242 I think that would essentially define/expand the Sparkfun Micromod standard to include 2242 boards.

@samuk
Copy link

samuk commented Feb 27, 2023

Just noticed this text from Sparkfun "We currently plan to only have 22x22mm MicroMods Processor Boards (note the ‘2222’ text) but this may grow in the future." https://learn.sparkfun.com/tutorials/designing-with-micromod/all#how-to-design-a-micromod-processor-board

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests