How do the GPIO test points compare to what is available on Axoloti Core?

This question comes from Blindsmyth and others.

In general, anything that is possible via IO pins on the original hardware is possible on the new hardware. The processors are pin compatible. The pin assignment is exactly the same by default for all legacy features. The GPIO test points that existed on the original Core hardware have the same names and assignments. The processor itself has 176 pins. The design attempts to make every potentially useful processor feature available at a test point. There’s a diagram that shows the test point pinout at the bottom of the reference manual page.

The ultimate source of truth about “What can processor pin X do?” is the processor datasheet (linked at the bottom of the reference section). The H7 has several additional peripherals beyond what the F4 offers. The pin assignment established in the original hardware is just one possible variation.

Does this mean that axocontrol from thonk will work with it? It would nudge me even more to get an akso board :slight_smile:

The arrangement of the pins on axoloti is different from Akso. So - yes, you could wire an AxoControl to an Akso, but you couldn’t just plug it together like with Axoloti.

So does Also have the same amount of pins that can accept potentiometers/ switches (qty 15)?

@BruttoBello The total number of IO test points is greater than what was available on Core and all of the original pins are supported. See the pinout diagram in the reference section for details. There are various new IO possibilities with the additional pins.

Does anyone want to work with me on a diagram such as we had for Axo?

I’m proficient at graphics, but not at deciphering data sheets. Someone sends me/works with me to decode all the pin info and I draw it up for all to enjoy?



Yes: I would like to help with this.
Caveat: My time is finite: I have a nacent design/build company and a three-year-old.

But I’d love to help to develop a handy graphic like Paul’s that helps to explain the akso.
A big head start would be if someone (@nsm) could provide a vector (any non-raster) version of the “akso_pinout_bottom.png” graphic for use as a background.

In the meantime, I’ll start working up a spreadsheet from the datasheet.


So, I spent a little time building a spreadsheet against the datasheet.
I added the I/O structure definition as the first step to decoding what type of input each GPIO could tolerate. I haven’t delved into I2C, PWM, Serial or SPI, but I did manage to at least record the alternate and additional functions, which give some insight into those uses… it’ll just be a matter of checking against the datasheet to confirm.

I have not begun to compare this against the pinout image nor have I begun to integrate it with the pinout description of the actual Akso. I suspect I’ll have a couple questions once I’ve started that exercise. A schematic would help to make sure I’m comparing apples to apples.

Spreadsheet here, but it’s very preliminary and really is of little use in its current state.

With all that said, during this I installed the Asko Patcher software to see if its GPIO objects matched my initial findings and it appears that the GPIO objects in the Akso patcher have not been updated from the original Axoloti Patcher; that is, they only reflect the Axoloti’s GPIOs & those definitions: Whereas the Akso’s chip appears to have around 75 GPIO pins available, the Axoloti has only around 20 GPIO pins available, yet the GPIO objects only list 20 pins available.
I need to look into this a little further, but if that is indeed the case, then this needs to become a Github issue so that someone can update the Patcher’s GPIO objects to reflect the Akso’s pins.

Obviously, this exercise and that can/should inform each other, but if that is going to be the case, I would hope that others with more expertise in embedded design than me confirm the results of my findings… once I’ve had some.

1 Like

Great Job @consumer. Thank you very much. I just have started to play with my Akso around and I am very lost with pins, specially coming from Axoloti where everything is very straightforward, what was expectable taking in account that Axoloti has been tested longer and have a bigger community.

If it could be of any help, there are some topics in forum related to Gpios and may give any clue:


It would be awesome to have a clear spreadsheet similar to the one used in Axoloti. I am afraid not to be very helpful with that but I will be aware just in case I can give a helping hand.

Thanks @xoanxil,
That second link gets me a bit further… in fact, issue #3 that @nsm opened addresses an earlier point I made, although in my opinion, the issue should be expanded to include all GPIO that hasn’t been taken advantage of in the Patcher’s “Factory” GPIO Objects.
In the first link, @nsm is saying that when one is building (i.e. programming) objects, they need to call the desired pin… That’s helpful advice if you know what all the pins are capable of doing.
Hopefully, this exercise will start to clear that up and at the same time somebodies will program the factory patcher GPIO objects to include all the possibilities.

I’ll take another look at this in the coming days or weeks and begin to fold in this info, integrating the Akso’s pinout description.

Man… this project is nascent. I hope that it can rally enough support around it to take off.

1 Like