Mailing list archives : pcb-rnd

Date:Mon, 25 Sep 2023 13:32:44 +0200 (CEST)
Subject:Re: [pcb-rnd] new: sch-rnd funcmap for handling alternate function
in-reply-to:6183 from Majenko Technologies <>
replies: 6186 from Majenko Technologies <>
On Mon, 25 Sep 2023, Majenko Technologies wrote:
>That is really nice. However I have another use case: remappable pins. How
>would this work with the situation where one function can be assigned to any
>one of a list of potential pins? Effectively in the lihata file you would
>have multiple pins each with a massive list of potential functions. Can you
>duplicate functions on different pins? Can you "lock out" functions so if
>it's chosen on one pin it can not be chosen on any other pin until it's
>removed from that first pin?
That PIC has some multiplexers! What makes it tricky is that you can't 
multiplex every function to every port, but you have some random 
I've had a similar device at work, an atmel arm MCU where you have an UART 
with RX and TX and a group of pins you can map RX and TX to almost 
arbitrarily, except a few combinations are forbidden.
Then come FPGAs (and PALs and other programmable logic arrays) where you 
have even more flexibility on mapping.
When I designed funcmap, I was considering these cases and I concluded the 
only way all cases could be handled properly would be "constraint 
programming" (CP). In practice this means you'd get a language where you 
could write composite logical expressions to specify what can (not be) 
done in the function assingment and then the code would verify that your 
final assignment doesn't violate any of those expressions.
But I've abandoned this idea. I decided the stock funcmap feature would 
handle the simple but common cases while I could keep the UI and the 
configuration reasonably simple. Then anything not fitting this needs 
another mechanism somewhere else. 
My considerations leading to this decision:
1. if a feature gets overly complicated, it simply doesn't get used
I am thinking about it this way: How many different MCUs do you have with 
that flexible mapping? And how many different MCUs of those do you use a 
year? I'd say maybe 2..3 different such MCUs a year would make one a heavy 
user of this feature. Now the question is, how far would you go to learn a 
new feature to handle a "2..3 times a year" problem? 
My conclusion was that a CP solution would be so complicated to learn and 
remember that with such "2..3 times a year" usage it just wouldn't worth 
(And I think that 2..3 is a real optimistic estimation in favor of 
complicated MCUs... In my practice, I meet such a device once every 
decade, probably. The rest do fit in the current fucmap, MCUs and CPUs I 
used. Well, yes, I am not a big fan of the PIC series, I don't use those.)
2. complicating the simple case
The other problem with such a generic solution is that it would make the 
simple case real complicated. I think vast majority of the devices are 
still as simple as to directly fit into the current, limited funcmap 
implementation, plus there are a few percent that are sligtly more 
complicated but can still be fit into the system with a minor abuse^1.
3. GUI + CLI
For most advanced features, it's usually not very hard to make a CLI-only 
solution and it's not very hard to make a GUI-only solution. The hard part 
is to make both, and especially make them follow more or less the same 
With the current setup, I think I managed to achieve that. With a CP 
approach, I couldn't figure how to do that. I even couldn't figure 
how the GUI alone would offer a simple way to select functionality.
^1: creating virtual function groups; e.g. if you have an SPI device that 
can use 3 different combinations of pins, just define 3 SP strong groups 
for that. Like if it's called SPI2 in the datasheet, then SPI2a, SPI2b and 
Best regards,

Reply subtree:
6185 Re: [pcb-rnd] new: sch-rnd funcmap for handling alternate function from
  6186 Re: [pcb-rnd] new: sch-rnd funcmap for handling alternate function from Majenko Technologies <>
    6187 Re: [pcb-rnd] new: sch-rnd funcmap for handling alternate function from
      6188 Re: [pcb-rnd] new: sch-rnd funcmap for handling alternate function from Majenko Technologies <>