search

adafruit / M.2

Discussion, files, spec, and more for a M.2 standard for makers
31 stars 8 forks source link

Standard Discussion #2

Open arturo182 opened 3 years ago

arturo182 commented 3 years ago

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

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

folknology commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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:

arturo182 commented 3 years ago

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

Tonymac32 commented 3 years ago

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 commented 3 years ago

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

flummer commented 3 years ago

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

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

nitz commented 3 years ago

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:

ptorrone commented 3 years ago

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

boards2

timonsku commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

When I look at the pinouts, it seems like:

Tonymac32 commented 3 years ago

I think the specific pin functions (outside of power/ground), should be disregarded for maker purposes. It's unlikely anyone here wants 1.8V signalling, and we probably don't need that many differential pairs surrounded by ground pins (one of the MicroMods biggest deviations is eliminating some of those grounds for extra 'low speed' signals).

That said, a few "basic" peripherals should probably have specified positions.

Specifying 3.3 or 5V I think would be important. Should some of the pins be 5V tolerant? Thinking of AVR in particular here, or should the carrier board handle that level shifting should someone want to make an Uno carrier?

On Mon, Oct 26, 2020, 2:36 PM Thomas Flummer notifications@github.com wrote:

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.

ā€” You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/adafruit/M.2/issues/2#issuecomment-716745607, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFATFAQV7PGVJSXVSGDR723SMW6SPANCNFSM4S5SFHCQ .

arturo182 commented 3 years ago

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 commented 3 years ago

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.

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.

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 1 year ago

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

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 commented 1 year ago

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