Re: [Kicad-developers] Segmentation Fault when creating a copper zone
Hi Nick, It seems that Seth Hillbrand already commited a fix to it. Augusto. Nick Østergaard writes: > Please submit it directly on gitlab as a merge request. > > https://gitlab.com/kicad/code/kicad > > fre. 21. aug. 2020 14.17 skrev Augusto Fraga Giachero >: > >> Hi, >> >> I've experienced crashes in pcbnew when creating a cooper fill zone when >> no board edges has been defined. Tuns out that BuildBoardPolygonOutlines >> is called with aErrorText set to nullptr an it tries to deference it to >> write an error message when no board edges has been found. >> >> The attached patch checks aErrorText and only deference it if it is not >> nullptr. >> >> Upon further investigation I discovered that the overloaded method >> BOARD::GetBoardPolygonOutlines is called from ZONE_FILLER::Fill with its >> default values of aErrorText and aErrorLocation (both nullptr). Wouldn't >> be better to supply a valid pointer to aErrorText to inform the user >> about the error / warning in this case? >> >> Thanks, >> Augusto. >> ___ >> 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] Segmentation Fault when creating a copper zone
Hi,
I've experienced crashes in pcbnew when creating a cooper fill zone when
no board edges has been defined. Tuns out that BuildBoardPolygonOutlines
is called with aErrorText set to nullptr an it tries to deference it to
write an error message when no board edges has been found.
The attached patch checks aErrorText and only deference it if it is not
nullptr.
Upon further investigation I discovered that the overloaded method
BOARD::GetBoardPolygonOutlines is called from ZONE_FILLER::Fill with its
default values of aErrorText and aErrorLocation (both nullptr). Wouldn't
be better to supply a valid pointer to aErrorText to inform the user
about the error / warning in this case?
Thanks,
Augusto.
>From f14e9a171d3e7e023b7778745c3b29f7119e9603 Mon Sep 17 00:00:00 2001
From: Augusto Fraga Giachero
Date: Fri, 21 Aug 2020 08:36:17 -0300
Subject: [PATCH] Check the aErrortext pointer before deferencing it
BuildBoardPolygonOutlines can be called with aErrorText set to
nullptr (as it is when calling BOARD::GetBoardPolygonOutlines with its
default values).
---
pcbnew/convert_drawsegment_list_to_polygon.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/pcbnew/convert_drawsegment_list_to_polygon.cpp b/pcbnew/convert_drawsegment_list_to_polygon.cpp
index aaf04b211..bd962f74a 100644
--- a/pcbnew/convert_drawsegment_list_to_polygon.cpp
+++ b/pcbnew/convert_drawsegment_list_to_polygon.cpp
@@ -785,7 +785,8 @@ bool BuildBoardPolygonOutlines( BOARD* aBoard, SHAPE_POLY_SET& aOutlines, wxStri
}
else
{
-*aErrorText = _( "No edges found on Edge.Cuts layer." );
+if( aErrorText != nullptr )
+*aErrorText = _( "No edges found on Edge.Cuts layer." );
}
if( !success || !aOutlines.OutlineCount() )
--
2.28.0
___
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] Resistor 2512 footprint [Kicad 4.07]
Rene Pöschl writes: > There are completely new footprints for such devices. (In the v5 lib) > > I think the resistor lib should even be compatible with kicad 4 (it has > no part with complex pads in it). At least the footprint in question is > compatible. > > They are now script generated [1]. The dimensions for the pads are based > on IPC recommendations. I've verified that with the new Kicad library the problem persists (the spacing between the pads is a little close, but far from the IPC recommendations). I'll file a bug on the Github project. > > The dimensions for the resistors come from different datasheets. (The > respective datasheet is always listed in the description of the footprint) > > > [1] > https://github.com/pointhi/kicad-footprint-generator/tree/master/scripts/SMD_chip_package_rlc-etc > > > Thanks, Augusto Fraga Giachero. ___ 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] Resistor 2512 footprint [Kicad 4.07]
Sorry for the noise, I'll try to compile the Kicad 5 rc2 and check if this issue persists in the new library. Thanks, Augusto Fraga Giachero. Nick Østergaard writes: > The kicad-developers list is not really for detailed library discussions > like this. You may have better luck reporting the issue directly on > https://github.com/kicad/kicad-footprints/issues > > I am not sure what the plan is, but I don't think the Librarians will > update the old footprints, all activity are done in the new repos. > > http://kicad-pcb.org/post/kicad-official-libraries/ > > 2018-04-03 23:33 GMT+02:00 Augusto Fraga Giachero <augustof...@gmail.com>: > >> >> Hi! >> >> I've had a an unpleasant surprise with a 2512 (imperial) smd resistor >> footprint (Resistors_SMD:R_2512_HandSoldering) available in the Kicad's >> official library (shame on me for not checking the dimensions before >> sending the gerbers). When our boards arrived we verified that the pads >> of this footprint are too further apart, up to the point that the >> resistor barely touches the pads. >> >> I've looked on some datasheets and other sources and confirmed that this >> footprint is out of the recommended dimensions >> (http://www.resistorguide.com/resistor-sizes-and-packages/). >> >> I've attached an image showing the dimensions from the website >> above. The recommended dimensions for 2512 are a = 3.5mm, b = 1.6mm and >> c = 3.8mm, while in the footprint available on Kicad a = 3.2mm, b = >> 2.7mm (no problems with this been wider as it is a hand soldering >> variant) and c = 5.2mm. >> >> Dim(mm) Average Kicad >> a 3.5 3.2 >> b 1.6 2.7 (ok, hand soldering) >> c 3.8 5.2 (too further apart) >> >> I don't known if it is fixed in the new Kicad 5 libraries, but it would >> be nice to be fixed in the legacy libraries as well. I can make the fix >> if nobody have already made. >> >> Thanks, >> Augusto Fraga Giachero. >> >> >> ___ >> 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] Resistor 2512 footprint [Kicad 4.07]
Hi! I've had a an unpleasant surprise with a 2512 (imperial) smd resistor footprint (Resistors_SMD:R_2512_HandSoldering) available in the Kicad's official library (shame on me for not checking the dimensions before sending the gerbers). When our boards arrived we verified that the pads of this footprint are too further apart, up to the point that the resistor barely touches the pads. I've looked on some datasheets and other sources and confirmed that this footprint is out of the recommended dimensions (http://www.resistorguide.com/resistor-sizes-and-packages/). I've attached an image showing the dimensions from the website above. The recommended dimensions for 2512 are a = 3.5mm, b = 1.6mm and c = 3.8mm, while in the footprint available on Kicad a = 3.2mm, b = 2.7mm (no problems with this been wider as it is a hand soldering variant) and c = 5.2mm. Dim(mm) Average Kicad a 3.5 3.2 b 1.6 2.7 (ok, hand soldering) c 3.8 5.2 (too further apart) I don't known if it is fixed in the new Kicad 5 libraries, but it would be nice to be fixed in the legacy libraries as well. I can make the fix if nobody have already made. Thanks, Augusto Fraga Giachero. ___ 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] Dealing with multifunction pins (Symbol)
Hi Wayne, This means that this will be addressed after the Kicad 5 release? Thanks, Augusto Fraga Giachero. On 30-01-2018 14:15, Wayne Stambaugh wrote: Augusto, Most of this is going to be addressed during the next development cycle when the new symbol library and schematic file format are implemented. At the moment, there is no plan at this time to allow for resizing symbols in schematics. Since symbols will be embedded in the schematic, resizing will be possible. Thank you for your input. Cheers, Wayne On 1/30/2018 10:01 AM, Augusto Fraga Giachero wrote: Hi, I've been designing schematics with some stm32 parts using the standard Kicad libraries, and a lot of these microcontrollers has 10+ functions multiplexed in each I/O pin. In the standard library the symbols displays all possible configurations available to each pin, I understand the motivation of this choice (not having to refer to the datasheet every time you want choose an I/O for some specific functionality), but this results in very large symbols occupying the page. I've come with a idea (which probably isn't new) to deal with this problem: * You can select what functions you will use from a list for each pin and only that will be displayed in the schematic; * You can then resize the symbol accordingly directly in the schematic; * While this wouldn't require any modification to the library symbol file format as the description string of each pin already carries all the necessary information, the .sch file format would probably be changed and would not have backwards compatibility. This may not be easy to implement as with the way eeschema handles symbols today and the issues I've cited above, I would like hear about your suggestions. Thanks, Augusto Fraga Giachero. ___ 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 ___ 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] Dealing with multifunction pins (Symbol)
Hi Clemens, Yes, this idea would only work for small and medium sized ICs, but would be nice to not depend on external tools besides Kicad and its symbol libraries to do it. Anyway, a tabled based entry might be a good solution. I'm glad to see that this issue is a concern among Kicad devs. Thanks, Augusto Fraga Giachero. On 30-01-2018 21:37, Clemens Koller wrote: Hello, Augusto! Your ideas regarding multiplexed I/Os are good, but might only be sufficient for small to medium-complex CPUs/FPGAs/modules/circuits. If you follow the latest developments, you will notice that there are even bigger things coming up and it will get more and more difficult to visually represent the huge amount of varying I/Os and to solve dependencies and restraints. So, in the long term, I suggest to have a look at some even more flexible methods as i.e. (database-) tabled based design entry. This means that a design tool (here KiCad) IMO needs to polish it's interfaces to the outside world to import/export pin lists and netlists on request. Some tools can work with lists/.CSVs, but seem to lack automation (forward/backward annotation). I am working a lot with databases and use my own glue (sql-scripts) to import/export generated pin lists to/from the Pin-Multiplexing software and to/from the design. Version managment is also mandatory. You might have a look at i.e. the Altera Pin Planner, Xilinx IO Planning or the Pins Tool from NXP to get an idea where we are heading to: https://www.nxp.com/pages/pins-tool-for-i.mx-application-processors:PINS-TOOL-IMX Regards, Clemens On 2018-01-30 16:01, Augusto Fraga Giachero wrote: Hi, I've been designing schematics with some stm32 parts using the standard Kicad libraries, and a lot of these microcontrollers has 10+ functions multiplexed in each I/O pin. In the standard library the symbols displays all possible configurations available to each pin, I understand the motivation of this choice (not having to refer to the datasheet every time you want choose an I/O for some specific functionality), but this results in very large symbols occupying the page. I've come with a idea (which probably isn't new) to deal with this problem: * You can select what functions you will use from a list for each pin and only that will be displayed in the schematic; * You can then resize the symbol accordingly directly in the schematic; * While this wouldn't require any modification to the library symbol file format as the description string of each pin already carries all the necessary information, the .sch file format would probably be changed and would not have backwards compatibility. This may not be easy to implement as with the way eeschema handles symbols today and the issues I've cited above, I would like hear about your suggestions. Thanks, Augusto Fraga Giachero. ___ 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 ___ 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] Dealing with multifunction pins (Symbol)
Hi, I've been designing schematics with some stm32 parts using the standard Kicad libraries, and a lot of these microcontrollers has 10+ functions multiplexed in each I/O pin. In the standard library the symbols displays all possible configurations available to each pin, I understand the motivation of this choice (not having to refer to the datasheet every time you want choose an I/O for some specific functionality), but this results in very large symbols occupying the page. I've come with a idea (which probably isn't new) to deal with this problem: * You can select what functions you will use from a list for each pin and only that will be displayed in the schematic; * You can then resize the symbol accordingly directly in the schematic; * While this wouldn't require any modification to the library symbol file format as the description string of each pin already carries all the necessary information, the .sch file format would probably be changed and would not have backwards compatibility. This may not be easy to implement as with the way eeschema handles symbols today and the issues I've cited above, I would like hear about your suggestions. Thanks, Augusto Fraga Giachero. ___ 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
