| ID: | 6186 |
| From: | Majenko Technologies <ma...@majenko.co.uk> |
| Date: | Mon, 25 Sep 2023 13:51:35 +0100 |
| Subject: | Re: [pcb-rnd] new: sch-rnd funcmap for handling alternate function |
| in-reply-to: | 6185 from rn...@igor2.repo.hu |
| replies: | 6187 from rn...@igor2.repo.hu |
--000000000000c540dc06062e6b21 Content-Type: text/plain; charset="UTF-8" Most of the microcontrollers I use have a similar multiplexer in them. All the PIC32 chips I use (which I use extensively - multiple different models many times over the course of a year), RP2040, ESP32, etc. In fact most modern MCUs and SOCs now are multiplexed across multiple pins and not static routes to individual pins. Many use global multiplexers (any function to any pin), but not all (like the PIC32), which have limited arrangements. In a good year I can be doing two or three designs a month with different combinations of MCUs that all have different pin assignment systems. For instance I did one recently that had two ESP32s and a PIC32 all with complex MUX arrangements to work out. The idea of creating multiple groups (SPI2a etc), certainly for the PIC32, wouldn't work. You can have any, or all, of the pins assigned, and in any combination of pins, not just "SPI2a is this and that pin, SPI2b is these other two pins", etc. The "locking out" would be a nice thing to have but not necessary, so we can ignore that. I have no problems having big lists of functions for each individual pin defined as long as the system will allow me to have the same function listed under different pins. As long as the scripting support is there to query these things then a sanity check script (or DRC script or something) could be crafted to check that you don't have the same function assigned to multiple pins in your design, so that's something that doesn't really need to be handled in the plugin itself. I have no problem with that kind of approach (move things into scripts - you know I love playing with scripts). So basically my question boils down to: "It's unclear in the documentation whether it is possible to have the same function listed as available for multiple pins" - and what the knockon effects of listing a function in such a way would be to the rest of the plugin as it stands now. On Mon, 25 Sept 2023 at 12:33, <rnd2@igor2.repo.hu> wrote: > > > 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 > > > -- *Matt Jenkins* Majenko Technologies https://majenko.co.uk --000000000000c540dc06062e6b21 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Most of the microcontrollers I use have a similar mul= tiplexer in them. All the PIC32 chips I use (which I use extensively - mult= iple different models many times over the course of a year), RP2040, ESP32,= etc. In fact most modern MCUs and SOCs now are multiplexed across multiple= pins and not static routes to individual pins. Many use global multiplexer= s (any function to any pin), but not all (like the PIC32), which have limit= ed arrangements. In a good year I can be doing two or three designs a month= with different combinations of MCUs that all have different pin assignment= systems. For instance I did one recently that had two ESP32s and a PIC32 a= ll with complex MUX arrangements to work out.</div><div><br></div><div>The = idea of creating multiple groups (SPI2a etc), certainly for the PIC32, woul= dn't work. You can have any, or all, of the pins assigned, and in any c= ombination of pins, not just "SPI2a is this and that pin, SPI2b is the= se other two pins", etc.=C2=A0</div><div><br></div><div>The "lock= ing out" would be a nice thing to have but not necessary, so we can ig= nore that. I have no problems having big lists of functions for each indivi= dual pin defined as long as the system will allow me to have the same funct= ion listed under different pins. As long as the scripting support is there = to query these things then a sanity check script (or DRC script or somethin= g) could be crafted to check that you don't have the same function assi= gned to multiple pins in your design, so that's something that doesn= 9;t really need to be handled in the plugin itself. I have no problem with = that kind of approach (move things into scripts - you know I love playing w= ith scripts). <br></div><div><br></div><div>So basically my question boils = down to: "It's unclear in the documentation whether it is possible= to have the same function listed as available for multiple pins" - an= d what the knockon effects of listing a function in such a way would be to = the rest of the plugin as it stands now. <br></div></div><br><div class=3D"= gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, 25 Sept 2023 at = 12:33, <<a href=3D"mailto:rnd2@igor2.repo.hu">rnd2@igor2.repo.hu</a>>= wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px = 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br> <br> On Mon, 25 Sep 2023, Majenko Technologies wrote:<br> <br> >That is really nice. However I have another use case: remappable pins. = How<br> >would this work with the situation where one function can be assigned t= o any<br> >one of a list of potential pins? Effectively in the lihata file you wou= ld<br> >have multiple pins each with a massive list of potential functions. Can= you<br> >duplicate functions on different pins? Can you "lock out" fun= ctions so if<br> >it's chosen on one pin it can not be chosen on any other pin until = it's<br> >removed from that first pin?<br> <br> That PIC has some multiplexers! What makes it tricky is that you can't = <br> multiplex every function to every port, but you have some random <br> constraints.<br> <br> I've had a similar device at work, an atmel arm MCU where you have an U= ART <br> with RX and TX and a group of pins you can map RX and TX to almost <br> arbitrarily, except a few combinations are forbidden.<br> <br> Then come FPGAs (and PALs and other programmable logic arrays) where you <b= r> have even more flexibility on mapping.<br> <br> <br> When I designed funcmap, I was considering these cases and I concluded the = <br> only way all cases could be handled properly would be "constraint <br> programming" (CP). In practice this means you'd get a language whe= re you <br> could write composite logical expressions to specify what can (not be) <br> done in the function assingment and then the code would verify that your <b= r> final assignment doesn't violate any of those expressions.<br> <br> But I've abandoned this idea. I decided the stock funcmap feature would= <br> handle the simple but common cases while I could keep the UI and the <br> configuration reasonably simple. Then anything not fitting this needs <br> another mechanism somewhere else. <br> <br> My considerations leading to this decision:<br> <br> 1. if a feature gets overly complicated, it simply doesn't get used<br> <br> I am thinking about it this way: How many different MCUs do you have with <= br> that flexible mapping? And how many different MCUs of those do you use a <b= r> year? I'd say maybe 2..3 different such MCUs a year would make one a he= avy <br> user of this feature. Now the question is, how far would you go to learn a = <br> new feature to handle a "2..3 times a year" problem? <br> <br> My conclusion was that a CP solution would be so complicated to learn and <= br> remember that with such "2..3 times a year" usage it just wouldn&= #39;t worth <br> bothering.<br> <br> (And I think that 2..3 is a real optimistic estimation in favor of <br> complicated MCUs... In my practice, I meet such a device once every <br> decade, probably. The rest do fit in the current fucmap, MCUs and CPUs I <b= r> used. Well, yes, I am not a big fan of the PIC series, I don't use thos= e.)<br> <br> <br> 2. complicating the simple case<br> <br> The other problem with such a generic solution is that it would make the <b= r> simple case real complicated. I think vast majority of the devices are <br> still as simple as to directly fit into the current, limited funcmap <br> implementation, plus there are a few percent that are sligtly more <br> complicated but can still be fit into the system with a minor abuse^1.<br> <br> <br> 3. GUI + CLI<br> <br> For most advanced features, it's usually not very hard to make a CLI-on= ly <br> solution and it's not very hard to make a GUI-only solution. The hard p= art <br> is to make both, and especially make them follow more or less the same <br> logic.<br> <br> With the current setup, I think I managed to achieve that. With a CP <br> approach, I couldn't figure how to do that. I even couldn't figure = <br> how the GUI alone would offer a simple way to select functionality.<br> <br> <br> <br> <br> <br> Footnotes:<br> <br> ^1: creating virtual function groups; e.g. if you have an SPI device that <= br> can use 3 different combinations of pins, just define 3 SP strong groups <b= r> for that. Like if it's called SPI2 in the datasheet, then SPI2a, SPI2b = and <br> SPI2c.<br> <br> <br> Best regards,<br> <br> Igor2<br> <br> <br> </blockquote></div><br clear=3D"all"><br><span class=3D"gmail_signature_pre= fix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"l= tr"><div><div dir=3D"ltr"><b>Matt Jenkins</b><div>Majenko Technologies</div= ><div><a href=3D"https://majenko.co.uk" target=3D"_blank">https://majenko.c= o.uk</a></div></div></div></div></div> --000000000000c540dc06062e6b21--
Reply subtree:
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>