Standard Discussion #2
Comments
|
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.. |
|
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. |
|
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. 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. PIN assignment should be strict as needed and flexible as possible.
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 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. |
|
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. |
|
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 |
|
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. 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. (maybe we can rename this issue to "Standard Discussion" or so?) |
|
ok! here's a start of the maker boards, please add boards that are missed, links to compatibility or not, etc. |
|
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 : |
|
See also the commit from @flummer he did the same thing in markdown. I think thats better to stay in git for collaboration. Just for reference here is the official M.2 mechanical and electrical spec by the PCI group: |
|
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:
|
|
Limor and pt discussed this repo on the stream a few minutes ago: https://youtu.be/46zAO_3-ozY?t=781 |
|
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. |
|
I will probably be off-topic here, but I would be much more interested in a Molex SlimStack kind of interface:
|
|
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. |
|
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:
|
|
good stuff, did some updates
|
|
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. |
|
@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. |
|
@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). |
|
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? |
|
@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. |
|
When I look at the pinouts, it seems like:
|
|
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.
- USB (High Speed or Full Speed)
- I2C
- SPI
- UART
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 ***@***.***> 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
<#2 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFATFAQV7PGVJSXVSGDR723SMW6SPANCNFSM4S5SFHCQ>
.
|
|
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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
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
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. |
|
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 |
I guess might as well post some random ideas/observations, to start the discussion, they might be a bit chaotic ;)
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)
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!
The text was updated successfully, but these errors were encountered: