Re: [Kicad-developers] Assumptions about EDA_DRAW_FRAME in pcbnew

[Seth Hillbrand]

On 2020-07-03 16:31, Reece R. Pollack wrote:

> My submission last year was intended to allow any or all of the KiCad 
> subsystems (eeschema, pcbnew, gerbview, etc.) make use of origin transforms. 
> Gerbview could benefit, because if you set the place and drill origin to the 
> lower left of you design when you generate Gerbers, Gerbview displays the 
> page border below the displayed board. I'd thought about how to do this in 
> eeschema, considering an origin at any of the four corners or at the aux 
> origin (which is defined in eeschema but is not settable). But I did a full 
> implementation on pcbnew because that was what I felt really needed it.That  
> implementation added a parameter to the functions I mentioned above, which 
> resulted in the eeschema functions also having that parameter even though 
> they didn't use it. 
> 
> When Wayne sent out his last call for comments before he merged the changes, 
> Seth complained that since I didn't implement support in eeschema then these 
> changes should not affect any code in the eeschema directory. His suggestion 
> was to use function overloading, but that would result in having two 
> interfaces visible in the both eeschema and pcbnew, one that worked in that 
> context and one that didn't. You wouldn't know that the code called the wrong 
> function until you noticed broken behavior. I don't consider that an 
> acceptable situation just to avoid a trivial parameter list change.

Hi Reece- 

I think I mentioned back then that I'm happy to help with the
implementation.  The offer remains if you are interested. 

It is easy enough to overload with a pure virtual function in the base
class.  The derived classes can override (not overload) the virtual
functions that apply to each.  So pcbnew gets one viable function
signature and eeschema gets the other.  Misusing this gets an error in
compiling, which keeps errors from creeping down to the user. 

One aspect of dynamic_cast that is sometimes overlooked is that casts to
the base class are optimized out by the compiler.  I think that might
save your implementation (if I understand your intention correctly) 

Best-
Seth

Seth Hillbrand
KiCad Services Corporation
https://www.kipro-pcb.com
+1 530 302 5483 | +1 212 603 9372___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Assumptions about EDA_DRAW_FRAME in pcbnew

[Jeff Young]

> On 4 Jul 2020, at 00:31, Reece R. Pollack  wrote:
> 
> On 7/3/20 5:42 PM, Jeff Young wrote:
>> Hi Reece,
>> 
>>> On 3 Jul 2020, at 21:32, Reece R. Pollack >> > wrote:
>>> 
>>> Noting that the PCB_BASE_FRAME class is derived from the EDA_DRAW_FRAME 
>>> class, is it acceptable to assume that the EDA_DRAW_FRAME pointer 
>>> parameters passed to functions in Pcbnew classes are actually pointers to a 
>>> PCB_BASE_FRAME?
>> 
>> Yes, but it would be considered bad practice.
> 
> I would argue that it could easily be defined that code in the pcbnew 
> directory is dealing with a PCB_BASE_FRAME rather than an EDA_DRAW_FRAME. 
> Common code should not make that assumption, of course, and would not use 
> anything beyond the base class.

The problem is not when the code is written, but rather years later when 
someone changes one of the assumptions you were depending on and doesn’t even 
remember that your code exists.  dynamic_cast will then protect you, while a 
C-style or static_cast is likely going to do something ugly.

> 
>>> 
>>> Specifically:
>>> The UNIT_BINDER class constructor
>>> The classes implementing the GetMsgPanelInfo function
>>> The classes implementing the GetSelectMenuText function
>>> The reason I'm asking is that to implement origin transforms these 
>>> functions need access to the user's display option that chooses the display 
>>> origin. This needs access to a function defined in the PCB_BASE_FRAME 
>>> class. I can make that a common function defined in EDU_DRAW_FRAME and 
>>> overridden in PCB_BASE_FRAME, or the code needs to know that parameter is 
>>> really a pointer to a PCB_BASE_FRAME object.
>>> 
>> Ask yourself this: is there anything PCB-specific about a settable origin?  
>> Is there any reason a settable origin wouldn’t also be useful, say, a 
>> schematic?  If the answer is “no”, then you should push the origin (along 
>> with its getters and setters) down in to EDA_DRAW_FRAME.
> 
> My submission last year was intended to allow any or all of the KiCad 
> subsystems (eeschema, pcbnew, gerbview, etc.) make use of origin transforms. 
> Gerbview could benefit, because if you set the place and drill origin to the 
> lower left of you design when you generate Gerbers, Gerbview displays the 
> page border below the displayed board. I'd thought about how to do this in 
> eeschema, considering an origin at any of the four corners or at the aux 
> origin (which is defined in eeschema but is not settable). But I did a full 
> implementation on pcbnew because that was what I felt really needed it.That  
> implementation added a parameter to the functions I mentioned above, which 
> resulted in the eeschema functions also having that parameter even though 
> they didn't use it. 
> 
> When Wayne sent out his last call for comments before he merged the changes, 
> Seth complained that since I didn't implement support in eeschema then these 
> changes should not affect any code in the eeschema directory. His suggestion 
> was to use function overloading, but that would result in having two 
> interfaces visible in the both eeschema and pcbnew, one that worked in that 
> context and one that didn't. You wouldn't know that the code called the wrong 
> function until you noticed broken behavior. I don't consider that an 
> acceptable situation just to avoid a trivial parameter list change.
> 
> My approach this year is that code in the pcbnew directory knows it's dealing 
> with a PCB_BASE_FRAME because it's PCB-specific code in the first place. Then 
> it's easy to access the PCB-specific interfaces and data. Rather than 
> changing the UNIT_BINDER class I've implemented a PCB_UNIT_BINDER class 
> derived from UNIT_BINDER. It knows that it's getting a PCB_BASE_FRAME rather 
> than an EDA_DRAW_FRAME, and passes that to the base class constructor. It's 
> more tricky with the functions that are called indirectly through the 
> EDA_DRAW_FRAME, such as GetMsgPanelInfo and GetSelectMenuText. The 
> implementations are specific to pcbnew and live in the pcbnew directory.
> 
> I can do it with dynamic casts, but I'm an embedded systems guy and I hate to 
> waste CPU cycles checking things that are defined to be true. And 
> dynamic_cast is slow: my tests of the Icarus Verilog simulator appear to show 
> VVP spends about 20% of its CPU cycles just resolving dynamic casts. 
> 
>> If this really is PCB-specific, then you can either push just the origin 
>> getters/setters down into EDA_DRAW_FRAME and override them in 
>> PCB_BASE_FRAME, or do a dynamic_cast to PCB_BASE_FRAME and if non-null call 
>> the getters/setters.
> 
> I believe there will need to be subsystem-specific implementations of 
> portions of the origin transform code, based on what display options we offer 
> to the user. However, I think a lot of the interfaces can be common. I'm 
> willing to do either a PCB-only version or one that has support for pcbnew 
> and latent support for the other subsystems. What 

Re: [Kicad-developers] Assumptions about EDA_DRAW_FRAME in pcbnew

[Reece R. Pollack]

On 7/3/20 5:42 PM, Jeff Young wrote:

Hi Reece,

On 3 Jul 2020, at 21:32, Reece R. Pollack > wrote:


Noting that the PCB_BASE_FRAME class is derived from the 
EDA_DRAW_FRAME class, is it acceptable to assume that the 
EDA_DRAW_FRAME pointer parameters passed to functions in Pcbnew 
classes are actually pointers to a PCB_BASE_FRAME?


Yes, but it would be considered bad practice.


I would argue that it could easily be defined that code in the pcbnew 
directory is dealing with a PCB_BASE_FRAME rather than an 
EDA_DRAW_FRAME. Common code should not make that assumption, of course, 
and would not use anything beyond the base class.




Specifically:

  * The UNIT_BINDER class constructor
  * The classes implementing the GetMsgPanelInfo function
  * The classes implementing the GetSelectMenuText function

The reason I'm asking is that to implement origin transforms these 
functions need access to the user's display option that chooses the 
display origin. This needs access to a function defined in the 
PCB_BASE_FRAME class. I can make that a common function defined in 
EDU_DRAW_FRAME and overridden in PCB_BASE_FRAME, or the code needs to 
know that parameter is really a pointer to a PCB_BASE_FRAME object.


Ask yourself this: is there anything PCB-specific about a settable 
origin?  Is there any reason a settable origin wouldn’t also be 
useful, say, a schematic?  If the answer is “no”, then you should push 
the origin (along with its getters and setters) down in to EDA_DRAW_FRAME.


My submission last year was intended to allow any or all of the KiCad 
subsystems (eeschema, pcbnew, gerbview, etc.) make use of origin 
transforms. Gerbview could benefit, because if you set the place and 
drill origin to the lower left of you design when you generate Gerbers, 
Gerbview displays the page border below the displayed board. I'd thought 
about how to do this in eeschema, considering an origin at any of the 
four corners or at the aux origin (which is defined in eeschema but is 
not settable). But I did a full implementation on pcbnew because that 
was what I felt really needed it.That  implementation added a parameter 
to the functions I mentioned above, which resulted in the eeschema 
functions also having that parameter even though they didn't use it.


When Wayne sent out his last call for comments before he merged the 
changes, Seth complained that since I didn't implement support in 
eeschema then these changes should not affect any code in the eeschema 
directory. His suggestion was to use function overloading, but that 
would result in having two interfaces visible in the both eeschema and 
pcbnew, one that worked in that context and one that didn't. You 
wouldn't know that the code called the wrong function until you noticed 
broken behavior. I don't consider that an acceptable situation just to 
avoid a trivial parameter list change.


My approach this year is that code in the pcbnew directory knows it's 
dealing with a PCB_BASE_FRAME because it's PCB-specific code in the 
first place. Then it's easy to access the PCB-specific interfaces and 
data. Rather than changing the UNIT_BINDER class I've implemented a 
PCB_UNIT_BINDER class derived from UNIT_BINDER. It knows that it's 
getting a PCB_BASE_FRAME rather than an EDA_DRAW_FRAME, and passes that 
to the base class constructor. It's more tricky with the functions that 
are called indirectly through the EDA_DRAW_FRAME, such as 
GetMsgPanelInfo and GetSelectMenuText. The implementations are specific 
to pcbnew and live in the pcbnew directory.


I can do it with dynamic casts, but I'm an embedded systems guy and I 
hate to waste CPU cycles checking things that are defined to be true. 
And dynamic_cast is slow: my tests of the Icarus Verilog simulator 
appear to show VVP spends about 20% of its CPU cycles just resolving 
dynamic casts.


If this really is PCB-specific, then you can either push just the 
origin getters/setters down into EDA_DRAW_FRAME and override them in 
PCB_BASE_FRAME, or do a dynamic_cast to PCB_BASE_FRAME and if non-null 
call the getters/setters.


I believe there will need to be subsystem-specific implementations of 
portions of the origin transform code, based on what display options we 
offer to the user. However, I think a lot of the interfaces can be 
common. I'm willing to do either a PCB-only version or one that has 
support for pcbnew and latent support for the other subsystems. What I'm 
not willing to do is invest a lot of effort, only for someone to veto it 
at the last minute over a stylistic difference of opinion again. We, 
meaning myself and the core developers collectively, need to come to a 
consensus on how this should be implemented.


-Reece
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Assumptions about EDA_DRAW_FRAME in pcbnew

[Jeff Young]

Hi Reece,

> On 3 Jul 2020, at 21:32, Reece R. Pollack  wrote:
> 
> Noting that the PCB_BASE_FRAME class is derived from the EDA_DRAW_FRAME 
> class, is it acceptable to assume that the EDA_DRAW_FRAME pointer parameters 
> passed to functions in Pcbnew classes are actually pointers to a 
> PCB_BASE_FRAME?

Yes, but it would be considered bad practice.

> 
> Specifically:
> The UNIT_BINDER class constructor
> The classes implementing the GetMsgPanelInfo function
> The classes implementing the GetSelectMenuText function
> The reason I'm asking is that to implement origin transforms these functions 
> need access to the user's display option that chooses the display origin. 
> This needs access to a function defined in the PCB_BASE_FRAME class. I can 
> make that a common function defined in EDU_DRAW_FRAME and overridden in 
> PCB_BASE_FRAME, or the code needs to know that parameter is really a pointer 
> to a PCB_BASE_FRAME object.
> 
Ask yourself this: is there anything PCB-specific about a settable origin?  Is 
there any reason a settable origin wouldn’t also be useful, say, a schematic?  
If the answer is “no”, then you should push the origin (along with its getters 
and setters) down in to EDA_DRAW_FRAME.

If this really is PCB-specific, then you can either push just the origin 
getters/setters down into EDA_DRAW_FRAME and override them in PCB_BASE_FRAME, 
or do a dynamic_cast to PCB_BASE_FRAME and if non-null call the getters/setters.

Cheers,
Jeff.

> If the functions defined in PCB-specific classes are defined to be getting 
> pointers to PCB_BASE_FRAME classes, I can just change the parameter type and 
> avoid the need to play games with dynamic casts.
> 
> Thanks!
> 
> -Reece
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Derived class naming questions

[Jeff Young]

PCB_UNIT_BINDER.

No rule, so go with the prevailing practice.

Cheers,
Jeff.


> On 3 Jul 2020, at 21:49, Reece R. Pollack  wrote:
> 
> Here's a coding standards question:
> 
> Let's say I create a PCB-specific class derived from UNIT_BINDER. Should it 
> be called PCB_UNIT_BINDER or UNIT_BINDER_PCB?
> 
> -Reece
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Derived class naming questions

[Reece R. Pollack]

Here's a coding standards question:

Let's say I create a PCB-specific class derived from UNIT_BINDER. Should 
it be called PCB_UNIT_BINDER or UNIT_BINDER_PCB?


-Reece

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Assumptions about EDA_DRAW_FRAME in pcbnew

[Reece R. Pollack]

Noting that the PCB_BASE_FRAME class is derived from the EDA_DRAW_FRAME 
class, is it acceptable to assume that the EDA_DRAW_FRAME pointer 
parameters passed to functions in Pcbnew classes are actually pointers 
to a PCB_BASE_FRAME?


Specifically:

 * The UNIT_BINDER class constructor
 * The classes implementing the GetMsgPanelInfo function
 * The classes implementing the GetSelectMenuText function

The reason I'm asking is that to implement origin transforms these 
functions need access to the user's display option that chooses the 
display origin. This needs access to a function defined in the 
PCB_BASE_FRAME class. I can make that a common function defined in 
EDU_DRAW_FRAME and overridden in PCB_BASE_FRAME, or the code needs to 
know that parameter is really a pointer to a PCB_BASE_FRAME object.


If the functions defined in PCB-specific classes are defined to be 
getting pointers to PCB_BASE_FRAME classes, I can just change the 
parameter type and avoid the need to play games with dynamic casts.


Thanks!

-Reece

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Some troubles with busses

[BERTRAND Joël]

Jon Evans a écrit :
> Hi Joël,
> 
> As Dino mentioned, buses in KiCad work just like net labels:  Another
> bus with the same name on the same schematic sheet will be connected,
> the same way that two pins will be connected if you place the same net
> label on them (even if you don't draw a wire between the pins).
> 
> If you send me your whole schematic instead of just the PDF I can take
> a look to see if there is any bad behavior going on, since bus
> behavior did have lots of changes in the nightlies.
> 
Thanks for your answer. In my case, bus is connected to another bus on
the same schematic, but NOT on the same sheet. I will send to you whole
schematic and netlist as soon as possible.

Best regards,

JB

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Some troubles with busses

[Jon Evans]

Hi Joël,

As Dino mentioned, buses in KiCad work just like net labels:  Another
bus with the same name on the same schematic sheet will be connected,
the same way that two pins will be connected if you place the same net
label on them (even if you don't draw a wire between the pins).

If you send me your whole schematic instead of just the PDF I can take
a look to see if there is any bad behavior going on, since bus
behavior did have lots of changes in the nightlies.

Best,
Jon

On Thu, Jul 2, 2020 at 5:36 PM BERTRAND Joël  wrote:
>
> Hello,
>
> I'm trying to interconnect some sub-sheets on a simple bus. Faulty
> schematic is in attachement.
>
> First remark : bus labels seem to be global by default (!) and, if I
> use S[0..63] instead of SA[0.63], KiCAD connects this bus with another
> one with the same name in another sheet ! I suppose that bus labels
> should always be local.
>
> On schematic I have sent, each sub-sheet has 32 input lines and 4
> output signals. I want to connect all output signals to a bus.
>
> I have tried several combinaisons without any success. How can I
> connect these busses to a largest bus ?
>
> My KiCAD is built from sources :
>
> Application: KiCad
> Version: (5.99.0-2096-g441dfa30f), release build
> Libraries:
> wxWidgets 3.0.5
> libcurl/7.68.0 GnuTLS/3.6.14 zlib/1.2.11 brotli/1.0.7 libidn2/2.3.0
> libpsl/0.21.0 (+libidn2/2.3.0) libssh2/1.8.0 nghttp2/1.41.0 librtmp/2.3
> Platform: Linux 5.6.0-1-amd64 x86_64, 64 bit, Little endian, wxGTK
> Build Info:
> Build date: Jul 2 2020 21:57:23
> wxWidgets: 3.0.5 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24
> Boost: 1.71.0
> OCC: 7.4.0
> Curl: 7.68.0
> Compiler: GCC 9.3.0 with C++ ABI 1013
> Build settings:
> KICAD_SCRIPTING=ON
> KICAD_SCRIPTING_MODULES=ON
> KICAD_SCRIPTING_PYTHON3=ON
> KICAD_SCRIPTING_WXPYTHON=ON
> KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
> KICAD_SCRIPTING_ACTION_MENU=ON
> BUILD_GITHUB_PLUGIN=ON
> KICAD_USE_OCC=ON
> KICAD_SPICE=ON
>
> Best regards,
>
> JKB
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Some troubles with busses

[Dino Ghilardi]

On 02/07/20 23:36, BERTRAND Joël wrote:

Hello,

I'm trying to interconnect some sub-sheets on a simple bus. Faulty
schematic is in attachement.

First remark : bus labels seem to be global by default (!) and, if I
use S[0..63] instead of SA[0.63], KiCAD connects this bus with another
one with the same name in another sheet ! I suppose that bus labels
should always be local.


Hello Bertrand,

It seams the same as:

https://gitlab.com/kicad/code/kicad/-/issues/3460
"bus members with the same name are merged (lp:#1830233)"

the answer was:
" This is expected behavior.  Group buses are not namespaced unless you 
add a

name to the group.

If you want to have two different nets, you need to add a name to the bus
definition, like `BUS1{ASDF}` to get nets like `BUS1.A`
"




On schematic I have sent, each sub-sheet has 32 input lines and 4
output signals. I want to connect all output signals to a bus.

I have tried several combinaisons without any success. How can I
connect these busses to a largest bus ?



Did you use the tools->bus definition to define the bus type?

Cheers,
Dino Ghilardi.



My KiCAD is built from sources :

Application: KiCad
Version: (5.99.0-2096-g441dfa30f), release build
Libraries:
 wxWidgets 3.0.5
 libcurl/7.68.0 GnuTLS/3.6.14 zlib/1.2.11 brotli/1.0.7 libidn2/2.3.0
libpsl/0.21.0 (+libidn2/2.3.0) libssh2/1.8.0 nghttp2/1.41.0 librtmp/2.3
Platform: Linux 5.6.0-1-amd64 x86_64, 64 bit, Little endian, wxGTK
Build Info:
 Build date: Jul 2 2020 21:57:23
 wxWidgets: 3.0.5 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24
 Boost: 1.71.0
 OCC: 7.4.0
 Curl: 7.68.0
 Compiler: GCC 9.3.0 with C++ ABI 1013
Build settings:
 KICAD_SCRIPTING=ON
 KICAD_SCRIPTING_MODULES=ON
 KICAD_SCRIPTING_PYTHON3=ON
 KICAD_SCRIPTING_WXPYTHON=ON
 KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
 KICAD_SCRIPTING_ACTION_MENU=ON
 BUILD_GITHUB_PLUGIN=ON
 KICAD_USE_OCC=ON
 KICAD_SPICE=ON

Best regards,

JKB


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp