| ID: | 6185 |
| From: | rn...@igor2.repo.hu |
| 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 <ma...@majenko.co.uk> |
| replies: | 6186 from Majenko Technologies <ma...@majenko.co.uk> |
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 constraints. 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 bothering. (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 logic. 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. Footnotes: ^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 SPI2c. Best regards, Igor2
Reply subtree:
6185 Re: [pcb-rnd] new: sch-rnd funcmap for handling alternate function from rn...@igor2.repo.hu
6186 Re: [pcb-rnd] new: sch-rnd funcmap for handling alternate function from Majenko Technologies <ma...@majenko.co.uk>
6187 Re: [pcb-rnd] new: sch-rnd funcmap for handling alternate function from rn...@igor2.repo.hu
6188 Re: [pcb-rnd] new: sch-rnd funcmap for handling alternate function from Majenko Technologies <ma...@majenko.co.uk>