Hi, I’d like to adopt MicroMod as a way to save adding a USB-Serial adapter on every prototype processor board we want to try. This would mean a USB cable connecting to a MicroMod carrier board with the USB-Serial chip and voltage regulators onboard and then we’d only need to place the microcontroller on the processor board. Using this approach we could prototype many processor boards and keep a carrier board as a programming and debug interface board.
The snag I can see is that the microcontrollers we intend to go on the processor board don’t have USB or SWD. The latter is not a problem, as I can repurpose some of the GPIOs for their programming interface. However, debug print is only available over UART, yet the MicroMod standard implies I can’t remain compliant while using a UART for debug prints. Is this a hard rule in the standard and using UART for debug will break compliance, or can this flex for the case I have outlined?
Realistically, keeping compliance isn’t a vital requirement for us as we only intend for internal use, but it would be nice to keep. I see the note saying “use a USB-Serial IC on your processor board and USB interface for debug print” but that just adds cost and complexity to every processor board prototype we’d want to try. Sparkfun official thoughts would be very welcome on the topic. Thanks for all the work you’ve put into the standard too.
Simon
A Micromod carrier board does NOT have a USB/serial. The USB D+ and D- are connected to the Micromod connector for the processor board (pin 3 and pin 5). Most have the possibility to add an SWD/JTAG, but it is not populated.
Have a look at https://www.sparkfun.com/products/16885. This is the ATP carrier board, click “documents” (middle /right hand) and you get good information e.g. the hookup-guide and schematics
Hi paulvha, thank you for replying to my post. I realise that I wasn’t clear. For my intended application, I would like to create a custom carrier board, as well as a custom processor board. So comparing my intended carrier board to the one you linked to, I would include a USB-Serial on that, to save me repeatedly including a USB-Serial chip on every processor board we prototype.
I looked at the references here: https://learn.sparkfun.com/tutorials/de … h-micromod, which is where I read in the pinout table that the UARTs are not to be used for debug print (or programming, I presume). These are the notes pertinent to the UART pins:
Note: UART1/2 must be unencumbered (not attached to a USB-to-serial conversion IC).
Note: UART0 is not shown. Primary debug serial is done over USB. Serial.print() should print over USB, not TX1.
Are these notes solely from a processor board perspective, for example if you were making an ESP32 processor board that you wanted to be compatible with Sparkfun’s MicroMod ATP Carrier Board, the necessary USB-Serial programming IC would be on the processor board and connected to the ESP32’s programming UART. However, that UART should not be connected to either of the MicroMod UARTs. But if the UART is only connected to the microcontroller on the processor board (because I have placed my USB-Serial IC on the carrier board), does that count as unencumbered? From the perspective of my processor board, I would say yes. From the perspective of my carrier board, maybe?
Could someone clarify how a UART is intended to be used on a carrier board with peripheral boards and a processor board? How does the peripheral board designer know which UART their peripheral can use out of the two available, to avoid conflicts with other perhipherals that also use UART? Do all UART-based peripherals need to have the option to switch between? Perhaps even more fundamentally, to which board are the Rx and Tx labels on the pinout referenced - the processor board or the peripheral board? SPI has its CIPO and COPI labelling to orientate the connections but the UART documentation is not clear on this. Perhaps I have missed an obvious convention or section of the documentation but extra details would be greatly appreciated.
Hoping for a Sparkfun “standards” rep to indicate their view on what I was planning on doing and hopefully clear up some of my ambiguity over the UART parts of the MicroMod spec.
As you plan to create your own carrier board, you are actually not stuck to the definitions of Sparkfun.
The way I see it:
USB0: that is the primary connection to the PC: USB D+ /D- . The processor board needs to be able to translate the USB signals to the relevant UART0 / primary UART signals. In case the processor does not have that capability it is advised to use a CH340E (although any FTDI can handle that). I have NOT seen any carrier/processor board using HOSTUSB connections, which should/could be used in case the processor HAS built-in USB-> UART capability (like a SAMD51). So Sparkfun is not using its own standards to the letter.
UART1 / UART2: in case the processor supports multiple Serial ports use these pins. If not, do not connect them. Also, Sparkfun expects that the signals on these pins are UART and NOT USB hence “UART1/2 must be unencumbered (not attached to a USB-to-serial conversion IC).”
As you build your own carrier board … tweak it to what you need
Thanks again paulvha.
I am still wondering about the Tx Rx pin orientation (ie is Tx the processor Tx or the peripheral Tx?). I assume this is all processor orientated and I will go and check the SAMD51 or another processor board to verify. The pinout tables should probably clarify this, unless I’m being thick or have missed where this is already specified in the docs.
The directions are defined in this document. https://cdn.sparkfun.com/assets/learn_t … QuNDAuMC4w
All pinout tables in this section are written from the Processor point of view when referencing signal directions.
Thank you for clarifying that point - I hadn’t seen it before. The Technical Specifications section of https://www.sparkfun.com/micromod doesn’t appear to be as clear.