Portenta H7: Pin Table - How complete should it be? Compatible with MBED version? #68
Comments
|
@KurtE |
|
I just pushed up again an updated copy of the GIGA/Portenta XLS document. Added a new page where I tried to see just how many pins of athe PA0-PK7 are used. Answer almost all of them. I did it by trying to extract all of the pin numbers from the main connectors J1, J2, plus pins on the board. Places like SDRAM, Ethernet, ... Also then added on to each row the AF functions for each pin... starts off like:
|
|
Quick update: First issue, I ran into was, spi was not setup in the overaly. So I added it (spi2). And started testing it... Found that the exported SPI from the H8 connects up to the SPI1 pins on the breakout board. When defining the SPI object, I believe that it uses pins 8-10 which I was using in the sketch for RESET, DC, CS. So hooked up to those pins, and then ran the Graphic test program and nothing showed up on the screen, but I was seeing Expected HIigh signal to be 250ms and Low 100ms, but:
It was inverted I looked at the overlay file and found that all of the GPIO pins were marked, like: <&gpiok 6 GPIO_ACTIVE_LOW>, So I updated the table to be like the GIGA and rebuilt the kernel... And now:
Will probably generate a PR for this initial stuff. Will then depending on things, may try to add all of the other |
This is a partial fix for: arduino#68 the spis line was not in the zephyr,user { section of the ovleray file. I added it with one entry: spis = <&spi2>; Updated: the GPIO table, that only the LEDS should be defined with GPIO_ACTIVE_LOW.
|
Update: I updated the pins list, to be compatible with the MBED version. Except there are some issues with the Analog pins. In particular: MBED version. For the _C type pins, I set them up the same was as was done for the GIGA. But, I don't know what is suggested for the ALT0 pins, like A4 and A5. I also don't know the full relationship between the pin and the complementary pin. That is May have to experiment to find out! Again not sure how to encode ALT0 yet. Maybe another hack on the gpioz and deadbeef? EDIT: Forgot to mention: I updated the sketch I used to check the pin numbers which also shows the Port/pin number |
|
@KurtE - synched up with your config and overlay files. And running now - only tested i2c so far |
|
@mjs513 and myself, have been trying out different things on Zephyr and currently the Portenta H7 and H7 Lite. As mentioned earlier in this issue, we have setup a version that matches the MBED Portenta H7 pin numbering. I originally purchased the H7 (and Hat carrier), it was simply to see how it compared with the GIGA. It was unclear to me at the time,
Not sure if this is what other users do or don't do? Matching the MBED version. However one side effect is the: simple example sketch Examples->basic->blink will now Faults. And the lookup code in Arduino.h sums them: So it says: LED_BUILTIN is 214, which is beyond the end of the table. And the code does not check... and later faults. Easy fix in this case, is to simply define it in variant.h Secondary notes: Looks like the Portenta C33 order of pins in MBED is completely different. More organized by major functionality groups. Not sure if any of the 122 pins in that table map down to same pin or not. Now back to playing |
|
Sorry for arriving so late Mike, I'm absolutely in favour of dropping the mbed compatibility after pin 13 (MKR header), so we can adopt a saner table and strategy and eventually there's no need for the extra patch. This applies to #71 |
|
@facchinm - Not sure how this would work? So assuming I have my Portenta plugged into another board, currently I have: Mid carrier, Hat Carrier and breakout board. How would one plug in a device and use any of the other pins that are exposed? I can imagine exposing most all of the pins that are exposed directly by the pins on the Portenta, plus LEDS and most if not all of them on the High density connectors, except for those which are used for very specific things like SDRAM, or USB or ... I am still wondering about creating an PinName enum (maybe copy from MBED) and have the pinName duplicate functions, much in the way you have pure_analog pins. It should also include a function to map from name to number... Why I think we probably need something is without it, converting and or testing between the MBED version and the Zephyr version will be a PIA. That is suppose I wish to use the pin labeled: GPIO4 on the Mid Carrier, What do I pass to the APIs?
I see it is PE_3, now how do map this to digital Pin? Suggestions? |
|
My gut feeling here is that we should provide a "Portenta pinout" with the abstract names as macros/enums in either the core or zephyr, so the final user with any carrier will be able to call
I searched the public web a bit for usages of the exact pin number and I couldn't find any example except "catchall" sketches, so I'm quite confident it wouldn't break anything |
|
Thanks @facchinm, I agree with you, that there is some need something like this. And it is not new for zephyr, similar issues on MBED version. For example this thread that was opened in the last day: Currently on MBED, you have the Alternate functions that use enum PinNames in the header file PinNames.h Which has all of the mappings for the PA_0-PK_7 mappings. It also has some of the generic mappings like LED_RED. My gut says you will need something that you may need multiple ways to map: Another main reason one needs to understand which pin is which, is many of them are used for multiple things, both on the I really wish some of the documentation on the carrier boards was easier to find some additional information:
On the Breakout board, you end up using the first couple pages of the schematic to figure out which pin is which: Hat Carrier: The first one I purchased when I bought the H7, is more of a challenge. I ended up mapping the pins, by:
So I did my own Excel document with all of the mappings. I do appreciate that one can find most of this information with the documentation you have generated, and I did not
Question is what to do in the short term? Thanks
|
This is a partial fix for: arduino#68 the spis line was not in the zephyr,user { section of the ovleray file. I added it with one entry: spis = <&spi2>; Updated: the GPIO table, that only the LEDS should be defined with GPIO_ACTIVE_LOW.
|
@facchinm @pillo79 @mjs513 and all: Sorry for yesterday's book. Hope some of it makes sense. 😆 I am wondering about doing sort of a mixed solution for the pins. That is I believe the pin table that I have in the current PR, could be slimmed down, to maybe only have on it the pins that can be used. Like the main pins that are on the Portenta H7s, Plus probably a lot of the ones on the different carriers, like the GPIOs and the PWMS, ADCs, ... more or less all of the pins that one Then Port over the Portenta's MBED PinName as overloads. I have a sketch that reasonably works where I: The whole sketch including a header file with the slightly stripped down version of the PinNames.h (removed all of the ones that had things like | ALT0 zephyr_pin_names_test-250307a.zip And I have a .cpp file that processes them as a quick and dirty. I am not an expert in the Device Tree APIS and the like, so there is probably a cleaner way for one to get the Current way is I hacked up the overlay and added: And then build a table in the same way as GPIO does... pinMode is similar, If I go farther with this, I would probably have it first call: PinNameToIndex and if index is found, call Thoughts? |
This is a partial fix for: arduino#68 the spis line was not in the zephyr,user { section of the ovleray file. I added it with one entry: spis = <&spi2>; Updated: the GPIO table, that only the LEDS should be defined with GPIO_ACTIVE_LOW.
This is a partial fix for: arduino#68 the spis line was not in the zephyr,user { section of the ovleray file. I added it with one entry: spis = <&spi2>; Updated: the GPIO table, that only the LEDS should be defined with GPIO_ACTIVE_LOW. H7 - ADC hack for D19,D20 Hack the two pins for A4 and A5 to say they are Z pins This fixes issue where the constants A4 and A5 were computed as the sum of two pin numbers as PC_2 and PC_3 pins are duplicated on these boards. Note: accessing those pins directly by index like 18, 19 will probably not work Update PinNames.cpp Remove debug Serial.print H7: Add in Dual pads into pin names PinName: digitalRead, analogRead, analogWrite Added a few more override functions. Brings up questions, with the analog ones. More on the PR Portenta H7: First cut add PinNames to the H7M7 variant Note: the overload function definitions are in the PinNames.h PinNames.cpp - duplicates the pin table, as the main pin table is defined static within zephyrCommon.cpp Not sure if to move some up to there but sort of specific to Portenta H7 maybe X8, maybe GIGA... Also I sort of still have a lot of the MBED names within the pin names, Probably should be weeded out Maybe some place should define breakout board specific namings? Portenta H7M7 - Add Camera and port table Start of Pin names stuff Portenta H7M7 support for analogWrite/analogRead @mjs513 and I added/modified the device tree for this board, with the tables to support PWM (analogWrite) and analogRead on some of the Analog pins. Note: there are some issues with A4/A5 in that those pins are also on the same pins that support SPI. And when SPI is enabled, the GPIOC pin configuration is setup by the device tree to be MODER to be set for Alternat function and their AF set to 5. The analogRead code does not does not update these tables and as such analogRead fails. We found that if y ou disable SPI then they work better. I currently left the SPI enabled. Probably need to add something that when analogRead is called that it updates the GPIO registers to make it work. I am ecurrently experimenting with a hack in my test sketch that appears to change the MODER of those pins back to 3, but so far that does not appear to be sufficent: ``` static const struct gpio_dt_spec arduino_pins[] = {DT_FOREACH_PROP_ELEM_SEP( DT_PATH(zephyr_user), digital_pin_gpios, GPIO_DT_SPEC_GET_BY_IDX, (, ))}; void pinModeAnalog(pin_size_t pinNumber) { gpio_pin_configure_dt(&arduino_pins[pinNumber], GPIO_INPUT /*| GPIO_ACTIVE_HIGH */ | GPIO_MODE_ANALOG); } ``` On the analogWrites, this code has optionally in place that allows duplicate pins in the device tree GPIO list, by changing how I read in the PWM table from the Tree, instead of summing all of the matches in the GPIO tree, it instead saves the GPIO Port and pin number and uses them for the compare. Again this depends on if we wish for the Pin numbers for the functions like digitalRead/digitalWrite to match those used by the MBED version. I still have the last 3 truncated K5-K7 which are used by the LEDs and fault but depending on directions, can find other solutions. enable spi2 Update arduino_portenta_h7_m7.conf to enable memc resolves: arduino#74 needed to add: CONFIG_MEMC=y to have the SDRAM enabled and as such not fault if you do anything with the SDRAM library. Also enabled CONFIG_DMA=y As not sure if that was needed but is in the GIGA .conf file Update arduino_portenta_h7_m7.overlay Add dma sections to remove the build warnings Portenta H7: update digital-pin-gpios to be same as MBED version Update arduino_portenta_h7_m7.overlay Added in the other two Wire objects to match the MBED version. i2cs = <&i2c3>, <&i2c1>, <&i2c4>; I checked it out with simple wire scanner sketch that checks Wire, Wire1 and Wire2. And then tried adding QWIIC Button first to the I2C0 section of breakout board and it was found on Wire. Moved it to I2C1 section and found with Wire1 and then moved to I2C2 section and found on Wire2
@pillo79 @facchinm @mjs513 and all:
We are starting to play with the Portenta H7. I have one of the H7 and one of the H7 lite processors and a breakout board and a Hat Carrier.
Starting to go through some of the basic testing. Earlier when I played with it using MBED, I added pages to my GIGA pin out excel document:
https://github.com/KurtE/Arduino_GIGA-stuff/blob/main/Documents/Arduino_GIGA_R1_pins.xlsx
Which still needs to be cleaned up.
It looks like the current state of the pin table in the overlay is pretty limited:
Which does align with the MBED version for D0-D14, however LEDR on MBED is something like pin 23 and here currently pin 15.
On MBED the table looks like:
Where you have pins PA_0-15, PB_0-15... PJ_0-15, PK_0-7
Which obviously some of these pins point to other pins with the same underlying hardware pin...
Some probably do not connect up to anything.
If I print out number of digital pins and count of pins I see:
So main questions include:
a) Should the pin out match the MBED version?
b) My assumption is that all of the pins that could be used for digital stuff that are exported through the connectors should have a pin number assigned to them. For example you have several of the UARTS defined which is great, but I would also expect that for those uarts that a sketch does not utilize, I could use the RX and TX and on some of them RTS and CTS pins, as normal IO pins.
Thoughts?
The text was updated successfully, but these errors were encountered: