| ID: | 6188 |
| From: | Majenko Technologies <ma...@majenko.co.uk> |
| Date: | Mon, 25 Sep 2023 15:32:49 +0100 |
| Subject: | Re: [pcb-rnd] new: sch-rnd funcmap for handling alternate function |
| in-reply-to: | 6187 from rn...@igor2.repo.hu |
--000000000000d41c3606062fd584 Content-Type: text/plain; charset="UTF-8" SCK's only on one pin though. Sure, it's used in multiple groups, but only from one pin. So that's a different beast. I'll enjoy using this system for the older simpler 8-bit MCUs then, and leave the big boys to manual annotation and keeping it all in my head. On Mon, 25 Sept 2023 at 14:47, <rnd2@igor2.repo.hu> wrote: > > > On Mon, 25 Sep 2023, Majenko Technologies wrote: > > >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. > > Then funcmap is not for you - it's for a simpler subset of the problem. > > <snip> > > >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 > > It's not just a "locking out". It's that you want to specify somehow that > you have an SPI2's MISO that needs to be on exactly one pin, and only if > SPI2's MOSI and SCK are also mapped somewhere, but you can't map MISO > anywhere, but only from one of 5 different pins. > > This can be done elegantly if you specify all these rules with logical > expressions. And that leads to CP (whether the programmer admits that or > not). > > >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). > > Sure, but that only means you are going to code your own CP. Which is > fine. That's why I said I was going to keep funcmap simple, and for those > who want to solve more complicated tasks and think it's worth investing > more time, there are other means. > > Funcmap is based on attributes. You can write a script that looks at > symbol attributes and terminal attributes and compute new attributes on > the concrete model level. > > That's a bit differen from funcmap's operation, because funcmap is > operating on the abstract model, during compilation. But later on I want > to expose the API for scripting such plugins too, plugins that create new > views, hooking into the compilation process. > > The only thing you won't have with that is the local lib mechanism, so > your sheets will start depending on external map files (or you will need > to copy those into symbol attributes within the sheet, but then work out > how to update them, how to keep copies of those attributes in multiple > symbols using the same map.) But if your compilation relies on user > scripts, your sheet is not portable anyway, so depending on external map > files is probably not a big deal then. > > > > >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. > > In funcmap you can have the "same functionality" assigned to multiple pins > but it's not gong to do what you need for your case. The docmentation has > an example of this for SCK, which is both in SPI and in USI. It's the same > function name but 2 different functions one levle up (SPI or USI) but then > one more level up it's again the same thing, the same hardware. Anyway, > SCK is a 'multi' functionality (see the DRC section of the doc). So the > code can still help you enable SPI or USI, it can still verify that if you > wanted SPI you have all SPI enabled, or if you wanted USI you have all USI > enabled. > > However, there's a limitation: if you enable SCK only, and no other USI or > SPI, it won't figure. And that's already because we don't have a full CP > just very simple heuristics. > > > So all in all: funcmap won't work for your heavily multiplexed case. For > that, you'll need a different solution. Later on I could code a plugin > doing something more generic, but then it has to be really generic, not > just a special case for your use case. Plus it will have to fit all > requirements I wrote in my previous reply, I don't want to add code that > works only on GUI, only on CLI or that is so complicated to configure that > nobody will ever use. So far I couldn't come up with a plan how to do > that. You could try to work it out, and propose a complete, coherent > system. > > > Best regards, > > Igor2 > > > > -- *Matt Jenkins* Majenko Technologies https://majenko.co.uk --000000000000d41c3606062fd584 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>SCK's only on one pin though. Sure, it's used= in multiple groups, but only from one pin. So that's a different beast= .</div><div><br></div><div>I'll enjoy using this system for the older s= impler 8-bit MCUs then, and leave the big boys to manual annotation and kee= ping it all in my head.<br></div></div><br><div class=3D"gmail_quote"><div = dir=3D"ltr" class=3D"gmail_attr">On Mon, 25 Sept 2023 at 14:47, <<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-l= eft:1px solid rgb(204,204,204);padding-left:1ex"><br> <br> On Mon, 25 Sep 2023, Majenko Technologies wrote:<br> <br> >Most of the microcontrollers I use have a similar multiplexer in them. = All<br> >the PIC32 chips I use (which I use extensively - multiple different mod= els<br> >many times over the course of a year), RP2040, ESP32, etc. <br> <br> Then funcmap is not for you - it's for a simpler subset of the problem.= <br> <br> <snip><br> <br> >The "locking out" would be a nice thing to have but not neces= sary, so we can<br> >ignore that. I have no problems having big lists of functions for each<= br> <br> It's not just a "locking out". It's that you want to spec= ify somehow that <br> you have an SPI2's MISO that needs to be on exactly one pin, and only i= f <br> SPI2's MOSI and SCK are also mapped somewhere, but you can't map MI= SO <br> anywhere, but only from one of 5 different pins.<br> <br> This can be done elegantly if you specify all these rules with logical <br> expressions. And that leads to CP (whether the programmer admits that or <b= r> not).<br> <br> >individual pin defined as long as the system will allow me to have the = same<br> >function listed under different pins. As long as the scripting support = is<br> >there to query these things then a sanity check script (or DRC script o= r<br> >something) could be crafted to check that you don't have the same f= unction<br> >assigned to multiple pins in your design, so that's something that = doesn't<br> >really need to be handled in the plugin itself. I have no problem with = that<br> >kind of approach (move things into scripts - you know I love playing wi= th<br> >scripts).<br> <br> Sure, but that only means you are going to code your own CP. Which is <br> fine. That's why I said I was going to keep funcmap simple, and for tho= se <br> who want to solve more complicated tasks and think it's worth investing= <br> more time, there are other means.<br> <br> Funcmap is based on attributes. You can write a script that looks at <br> symbol attributes and terminal attributes and compute new attributes on <br= > the concrete model level. <br> <br> That's a bit differen from funcmap's operation, because funcmap is = <br> operating on the abstract model, during compilation. But later on I want <b= r> to expose the API for scripting such plugins too, plugins that create new <= br> views, hooking into the compilation process. <br> <br> The only thing you won't have with that is the local lib mechanism, so = <br> your sheets will start depending on external map files (or you will need <b= r> to copy those into symbol attributes within the sheet, but then work out <b= r> how to update them, how to keep copies of those attributes in multiple <br> symbols using the same map.) But if your compilation relies on user <br> scripts, your sheet is not portable anyway, so depending on external map <b= r> files is probably not a big deal then.<br> <br> ><br> >So basically my question boils down to: "It's unclear in the d= ocumentation<br> >whether it is possible to have the same function listed as available fo= r<br> >multiple pins" - and what the knockon effects of listing a functio= n in such<br> >a way would be to the rest of the plugin as it stands now.<br> <br> In funcmap you can have the "same functionality" assigned to mult= iple pins <br> but it's not gong to do what you need for your case. The docmentation h= as <br> an example of this for SCK, which is both in SPI and in USI. It's the s= ame <br> function name but 2 different functions one levle up (SPI or USI) but then = <br> one more level up it's again the same thing, the same hardware. Anyway,= <br> SCK is a 'multi' functionality (see the DRC section of the doc). So= the <br> code can still help you enable SPI or USI, it can still verify that if you = <br> wanted SPI you have all SPI enabled, or if you wanted USI you have all USI = <br> enabled.<br> <br> However, there's a limitation: if you enable SCK only, and no other USI= or <br> SPI, it won't figure. And that's already because we don't have = a full CP <br> just very simple heuristics.<br> <br> <br> So all in all: funcmap won't work for your heavily multiplexed case. Fo= r <br> that, you'll need a different solution. Later on I could code a plugin = <br> doing something more generic, but then it has to be really generic, not <br= > just a special case for your use case. Plus it will have to fit all <br> requirements I wrote in my previous reply, I don't want to add code tha= t <br> works only on GUI, only on CLI or that is so complicated to configure that = <br> nobody will ever use. So far I couldn't come up with a plan how to do <= br> that. You could try to work it out, and propose a complete, coherent <br> system.<br> <br> <br> Best regards,<br> <br> Igor2<br> <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> --000000000000d41c3606062fd584--
Reply subtree:
6188 Re: [pcb-rnd] new: sch-rnd funcmap for handling alternate function from Majenko Technologies <ma...@majenko.co.uk>