Re: [Kicad-developers] Dealing with multifunction pins (Symbol)

[Clemens Koller]

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

Re: [Kicad-developers] Issues for features?

[Nick Østergaard]

There is no specified policy about this as far as I see it.

Generally we only use the bug tracker for bugs and stuff where people just
don't have time to start coding. So in conclusion, you should be good if
you just send patches to the dev list.

If you want to create some bugs to relate to 6.0 features, we can probably
set that up too. Maybe it will make us able to get a better overview later
on about what we expect people to work on for 6.0.

Den 30. jan. 2018 10.25 <20%2018%2010%2025> PM skrev "Jeff Young" <
j...@rokeby.ie>:

> If we implement a feature or an improvement to a feature, does it need an
> issue, or do we just send patches to the dev-list?
>
> (Obviously this is for 6.0, so I’m just trying to understand the process.)
>
> Thanks,
> Jeff.
> ___
> 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] wxwidgets fork progress

[Adam Wolf]

You can remove the boost patches.  They are only of historical
concern, and they'll live in Git for any future archaeologist who
cares.

Adam

On Tue, Jan 30, 2018 at 3:20 PM, Jeff Young  wrote:
> Yeah, I didn’t patch my boost either.  (I can’t remember if I MacPorts’d it
> or Homebrew’d it, but I didn’t do anything beyond that.)
>
>
> On 30 Jan 2018, at 21:13, Bernhard Stegmaier 
> wrote:
>
> Wayne,
>
> I don’t think so.
>
> I use a stock MacPorts boost since long before you removed boost from KiCad
> build.
> This might not be representative, but I didn’t see any problems.
>
> I had a quick look into Adams build scripts and I didn’t see that he is
> building his own boost (with the patches) somewhere.
>
>
> Regards,
> Bernhard
>
> On 30. Jan 2018, at 21:58, Wayne Stambaugh  wrote:
>
> Bernhard,
>
> What about the macos boost and context patches?  Do we still need to
> keep them?
>
> Thanks,
>
> Wayne
>
> On 1/29/2018 1:23 PM, Bernhard Stegmaier wrote:
>
> Wayne,
>
> yes, from my side you can delete them.
> Even if deleted they are in git anyway, so we can restore them if really
> needed.
> I’ll try to change documentation ASAP.
>
>
> Regards,
> Bernhard
>
> On 29. Jan 2018, at 19:15, Wayne Stambaugh  > wrote:
>
> Bernhard,
>
> Am I safe deleting the macos patches from the source repo or do I need
> to hold off until the dust has settle on the new wx repo?
>
> Thanks,
>
> Wayne
>
> On 1/29/2018 1:11 PM, Bernhard Stegmaier wrote:
>
> The full original soname patch seems to fix the issue in my builds (I
> did apply only half of it to our fork because of the comments in
> wxWidgets trac).
> I pushed it to the fork.
> The next build should pick it up automatically and be good again… sorry
> for not having checked this before.
>
> I also did set the bug to “Fix Committed”.
>
>
> BTW @Adam:
> There are still 2 wxPython macOS patches:
> (1) The "wxpython-3.0.0_macosx.patch” is not needed as it is the overlay
> stuff for wxWidgets.
> (2) I don’t know about the “…_multiarch.patch”. You don’t apply it as
> far as I can see and it seems to be fine without?
>   => Still needed?
>
>
> Regards,
> Bernhard
>
>
> On 29. Jan 2018, at 13:47, Bernhard Stegmaier
> 
> > wrote:
>
> Just a short status…
> I just tried the compile_wx.sh script and it generally seems to be fine.
>
> But, I can see that obviously the wxPython installer duplicates libs
> instead of symlinking them.
> Maybe the original soname patch we had is needed for that one to work
> correctly.
> I’ll check…
>
>
> Regards,
> Bernhard
>
>
> On 29. Jan 2018, at 00:32, Adam Wolf  
> > wrote:
>
> I think I see it now.  I can probably fix this tonight.  Thanks!
>
> Adam
>
> On Jan 28, 2018 5:30 PM, "Bernhard Stegmaier"
>   >
> wrote:
>
>Quick look into the build… seems to pull in wrong wxWidgets libs.
>The build in question includes some 3.0.0 wxWidgets libraries
>which I guess come from wxPython download.
>The fork should create 3.0.4 libraries...
>
>On 29. Jan 2018, at 00:05, Bernhard Stegmaier
>  >
> wrote:
>
>I just had a quick look and it looks fine.
>
>Also my first guess is that maybe something got messed up in the
>folder hierarchy when copying wxPython/wxWidgets together, so
>that e.g. here
>  WXPYTHON_BUILD_OPTS="WX_CONFIG=`pwd`/../../wx-bin/bin/wx-config \
>some wrong wxWidgets (not the one of the fork) gets pulled in.
>
>Too late here already to check just by review, will try
> tomorrow… :)
>
>On 29. Jan 2018, at 00:00, Adam Wolf
> 
>> wrote:
>
>Yeah.  The previous build script downloaded a wxpython tarball,
>which included wxwidgets.
>
>All my update did was move the wxpython subdirectory into a git
>checkout of the wxwidgets tree, and build that way.
>
>One quick thing would be to just do a diff between the
>wxwidgets included with wxpython 3.0.2.0, and the tree.  At
>this point, nothing would surprise me :)
>
>Adam
>
>
>
>On Jan 28, 2018 4:54 PM, "Bernhard Stegmaier"
>  > wrote:
>
>Sure.
>I’ll have a look tomorrow and try to build
>wxWidgets/wxPython the same way the script does.
>
>On 28. Jan 2018, at 23:44, Nick Østergaard
>  > wrote:
>
>You don't need 

[Kicad-developers] Issues for features?

[Jeff Young]

If we implement a feature or an improvement to a feature, does it need an 
issue, or do we just send patches to the dev-list?

(Obviously this is for 6.0, so I’m just trying to understand the process.)

Thanks,
Jeff.
___
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] wxwidgets fork progress

[Jeff Young]

Yeah, I didn’t patch my boost either.  (I can’t remember if I MacPorts’d it or 
Homebrew’d it, but I didn’t do anything beyond that.)


> On 30 Jan 2018, at 21:13, Bernhard Stegmaier  wrote:
> 
> Wayne,
> 
> I don’t think so.
> 
> I use a stock MacPorts boost since long before you removed boost from KiCad 
> build.
> This might not be representative, but I didn’t see any problems.
> 
> I had a quick look into Adams build scripts and I didn’t see that he is 
> building his own boost (with the patches) somewhere.
> 
> 
> Regards,
> Bernhard
> 
>> On 30. Jan 2018, at 21:58, Wayne Stambaugh > > wrote:
>> 
>> Bernhard,
>> 
>> What about the macos boost and context patches?  Do we still need to
>> keep them?
>> 
>> Thanks,
>> 
>> Wayne
>> 
>> On 1/29/2018 1:23 PM, Bernhard Stegmaier wrote:
>>> Wayne,
>>> 
>>> yes, from my side you can delete them.
>>> Even if deleted they are in git anyway, so we can restore them if really
>>> needed.
>>> I’ll try to change documentation ASAP.
>>> 
>>> 
>>> Regards,
>>> Bernhard
>>> 
 On 29. Jan 2018, at 19:15, Wayne Stambaugh 
 >> wrote:
 
 Bernhard,
 
 Am I safe deleting the macos patches from the source repo or do I need
 to hold off until the dust has settle on the new wx repo?
 
 Thanks,
 
 Wayne
 
 On 1/29/2018 1:11 PM, Bernhard Stegmaier wrote:
> The full original soname patch seems to fix the issue in my builds (I
> did apply only half of it to our fork because of the comments in
> wxWidgets trac).
> I pushed it to the fork.
> The next build should pick it up automatically and be good again… sorry
> for not having checked this before.
> 
> I also did set the bug to “Fix Committed”.
> 
> 
> BTW @Adam:
> There are still 2 wxPython macOS patches:
> (1) The "wxpython-3.0.0_macosx.patch” is not needed as it is the overlay
> stuff for wxWidgets.
> (2) I don’t know about the “…_multiarch.patch”. You don’t apply it as
> far as I can see and it seems to be fine without?
>   => Still needed?
> 
> 
> Regards,
> Bernhard
> 
> 
>> On 29. Jan 2018, at 13:47, Bernhard Stegmaier
>>  
>> >
>> >> wrote:
>> 
>> Just a short status…
>> I just tried the compile_wx.sh script and it generally seems to be fine.
>> 
>> But, I can see that obviously the wxPython installer duplicates libs
>> instead of symlinking them.
>> Maybe the original soname patch we had is needed for that one to work
>> correctly.
>> I’ll check…
>> 
>> 
>> Regards,
>> Bernhard
>> 
>> 
>>> On 29. Jan 2018, at 00:32, Adam Wolf >> 
>>> >> >
>>> >> >> wrote:
>>> 
>>> I think I see it now.  I can probably fix this tonight.  Thanks!
>>> 
>>> Adam
>>> 
>>> On Jan 28, 2018 5:30 PM, "Bernhard Stegmaier"
>>> 
>>> > 
>>> >>
>>> wrote:
>>> 
>>>Quick look into the build… seems to pull in wrong wxWidgets libs.
>>>The build in question includes some 3.0.0 wxWidgets libraries
>>>which I guess come from wxPython download.
>>>The fork should create 3.0.4 libraries...
>>> 
On 29. Jan 2018, at 00:05, Bernhard Stegmaier

 > 
 >>
 wrote:
 
I just had a quick look and it looks fine.
 
Also my first guess is that maybe something got messed up in the
folder hierarchy when copying wxPython/wxWidgets together, so
that e.g. here
  WXPYTHON_BUILD_OPTS="WX_CONFIG=`pwd`/../../wx-bin/bin/wx-config \
some wrong wxWidgets (not the one of the fork) gets pulled in.
 
Too late here already to check just by review, will try
 tomorrow… :)
 
>On 29. Jan 2018, at 00:00, Adam Wolf
> 
> 

Re: [Kicad-developers] wxwidgets fork progress

[Bernhard Stegmaier]

Wayne,

I don’t think so.

I use a stock MacPorts boost since long before you removed boost from KiCad 
build.
This might not be representative, but I didn’t see any problems.

I had a quick look into Adams build scripts and I didn’t see that he is 
building his own boost (with the patches) somewhere.


Regards,
Bernhard

> On 30. Jan 2018, at 21:58, Wayne Stambaugh  wrote:
> 
> Bernhard,
> 
> What about the macos boost and context patches?  Do we still need to
> keep them?
> 
> Thanks,
> 
> Wayne
> 
> On 1/29/2018 1:23 PM, Bernhard Stegmaier wrote:
>> Wayne,
>> 
>> yes, from my side you can delete them.
>> Even if deleted they are in git anyway, so we can restore them if really
>> needed.
>> I’ll try to change documentation ASAP.
>> 
>> 
>> Regards,
>> Bernhard
>> 
>>> On 29. Jan 2018, at 19:15, Wayne Stambaugh >> 
>>> >> wrote:
>>> 
>>> Bernhard,
>>> 
>>> Am I safe deleting the macos patches from the source repo or do I need
>>> to hold off until the dust has settle on the new wx repo?
>>> 
>>> Thanks,
>>> 
>>> Wayne
>>> 
>>> On 1/29/2018 1:11 PM, Bernhard Stegmaier wrote:
 The full original soname patch seems to fix the issue in my builds (I
 did apply only half of it to our fork because of the comments in
 wxWidgets trac).
 I pushed it to the fork.
 The next build should pick it up automatically and be good again… sorry
 for not having checked this before.
 
 I also did set the bug to “Fix Committed”.
 
 
 BTW @Adam:
 There are still 2 wxPython macOS patches:
 (1) The "wxpython-3.0.0_macosx.patch” is not needed as it is the overlay
 stuff for wxWidgets.
 (2) I don’t know about the “…_multiarch.patch”. You don’t apply it as
 far as I can see and it seems to be fine without?
   => Still needed?
 
 
 Regards,
 Bernhard
 
 
> On 29. Jan 2018, at 13:47, Bernhard Stegmaier
>  
> >
> >> wrote:
> 
> Just a short status…
> I just tried the compile_wx.sh script and it generally seems to be fine.
> 
> But, I can see that obviously the wxPython installer duplicates libs
> instead of symlinking them.
> Maybe the original soname patch we had is needed for that one to work
> correctly.
> I’ll check…
> 
> 
> Regards,
> Bernhard
> 
> 
>> On 29. Jan 2018, at 00:32, Adam Wolf > 
>> > >
>> > >> wrote:
>> 
>> I think I see it now.  I can probably fix this tonight.  Thanks!
>> 
>> Adam
>> 
>> On Jan 28, 2018 5:30 PM, "Bernhard Stegmaier"
>> 
>> > 
>> >>
>> wrote:
>> 
>>Quick look into the build… seems to pull in wrong wxWidgets libs.
>>The build in question includes some 3.0.0 wxWidgets libraries
>>which I guess come from wxPython download.
>>The fork should create 3.0.4 libraries...
>> 
>>>On 29. Jan 2018, at 00:05, Bernhard Stegmaier
>>>
>>> > 
>>> >>
>>> wrote:
>>> 
>>>I just had a quick look and it looks fine.
>>> 
>>>Also my first guess is that maybe something got messed up in the
>>>folder hierarchy when copying wxPython/wxWidgets together, so
>>>that e.g. here
>>>  WXPYTHON_BUILD_OPTS="WX_CONFIG=`pwd`/../../wx-bin/bin/wx-config \
>>>some wrong wxWidgets (not the one of the fork) gets pulled in.
>>> 
>>>Too late here already to check just by review, will try
>>> tomorrow… :)
>>> 
On 29. Jan 2018, at 00:00, Adam Wolf

 >
>> wrote:
 
Yeah.  The previous build script downloaded a wxpython tarball,
which included wxwidgets.
 
All my update did was move the wxpython subdirectory into a git
checkout of 

Re: [Kicad-developers] [PATCH] Allow OpenCASCADE standard edition

[Nick Østergaard]

I get the same issue with OCCT 7.2.0.

2018-01-29 23:30 GMT+01:00 Nick Østergaard :

> Hi Seth,
>
> I just took the patch for a testrun and will state some comments below.
>
> This looks a bit strange:
>
> -- Boost version: 1.66.0
> -- -- OpenCASCADE Community Edition has been found.
> -- -- Found OCE/OpenCASCADE version: 6.8.0
> -- -- OCE/OpenCASCADE include directory: /opt/oce/lib/oce-0.17/../../
> include/oce
> -- -- OCE/OpenCASCADE shared libraries directory:
> -- Check for installed Python Interpreter -- found
>
> The messages are with double -- and the shared libs.
>
> But an improvement with your patch over what is currently in kicad is that
> it found OCE on my system without explicitly specifind OCE_DIR. But how do
> I make it use OCCT when I also have OCE installed?
>
> What does CADx mean in that header?
>
> What is this about?
> -- Looking for /home/amazingdude/kicad-source-mirror/build_seths_
> occt_patch_occt/CMakeFiles/CMakeTmp/CheckSymbolExists.cxx
> -- Looking for /home/amazingdude/kicad-source-mirror/build_seths_
> occt_patch_occt/CMakeFiles/CMakeTmp/CheckSymbolExists.cxx - not found
>
> I tried to test it with removing oce and just have occt installed and got
> something like this:
> -- Found OCC: /opt/opencascade/inc (found version "6.9.1")
> -- -- Found OCE/OpenCASCADE version: 6.9.1
> -- -- OCE/OpenCASCADE include directory: /opt/opencascade/inc
> -- -- OCE/OpenCASCADE shared libraries directory: /opt/opencascade/lib
>
> It did not build against community/opencascade 6.9.1-7. I got the
> following error in a clean build dir.
>
> $ make kicad2step -j1
> [  0%] Linking CXX executable kicad2step
> /usr/bin/ld: cannot find -lTKMesh
> /usr/bin/ld: cannot find -lTKernel
> /usr/bin/ld: cannot find -lTKG2d
> /usr/bin/ld: cannot find -lTKG3d
> /usr/bin/ld: cannot find -lTKMath
> /usr/bin/ld: cannot find -lTKIGES
> /usr/bin/ld: cannot find -lTKSTL
> /usr/bin/ld: cannot find -lTKXSBase
> /usr/bin/ld: cannot find -lTKBin
> /usr/bin/ld: cannot find -lTKBO
> /usr/bin/ld: cannot find -lTKCDF
> /usr/bin/ld: cannot find -lTKBRep
> /usr/bin/ld: cannot find -lTKTopAlgo
> /usr/bin/ld: cannot find -lTKGeomAlgo
> /usr/bin/ld: cannot find -lTKGeomBase
> /usr/bin/ld: cannot find -lTKPrim
> /usr/bin/ld: cannot find -lTKSTEP
> /usr/bin/ld: cannot find -lTKSTEPBase
> /usr/bin/ld: cannot find -lTKSTEPAttr
> /usr/bin/ld: cannot find -lTKFeat
> /usr/bin/ld: cannot find -lTKCAF
> /usr/bin/ld: cannot find -lTKXCAF
> /usr/bin/ld: cannot find -lTKLCAF
> /usr/bin/ld: cannot find -lTKXDESTEP
> /usr/bin/ld: cannot find -lTKXDEIGES
> collect2: error: ld returned 1 exit status
> make[3]: *** [utils/kicad2step/CMakeFiles/kicad2step.dir/build.make:355:
> utils/kicad2step/kicad2step] Error 1
> make[2]: *** [CMakeFiles/Makefile2:3007: 
> utils/kicad2step/CMakeFiles/kicad2step.dir/all]
> Error 2
> make[1]: *** [CMakeFiles/Makefile2:3019: 
> utils/kicad2step/CMakeFiles/kicad2step.dir/rule]
> Error 2
> make: *** [Makefile:979: kicad2step] Error 2
>
> But those libs do existm, searched for the last one;
> $ yaourt  -Ql opencascade | grep TKXDEIGES
> opencascade /opt/opencascade/lib/libTKXDEIGES.so
> opencascade /opt/opencascade/lib/libTKXDEIGES.so.0
> opencascade /opt/opencascade/lib/libTKXDEIGES.so.0.0.0
>
> I got these variables set in the CMakeCache
>
> cat CMakeCache.txt  | grep "OCE\|OCC"
> KICAD_USE_OCE:BOOL=ON
> OCC_INCLUDE_DIR:PATH=/opt/opencascade/inc
> OCC_LIBRARY:FILEPATH=/opt/opencascade/lib/libTKernel.so
> //The directory containing a CMake configuration file for OCE.
> OCE_DIR:PATH=OCE_DIR-NOTFOUND
> //Details about finding OCC
> FIND_PACKAGE_MESSAGE_DETAILS_OCC:INTERNAL=[/opt/opencascade/inc][v6.9.1()]
>
> This is tested on archlinux.
>
> 2018-01-29 19:54 GMT+01:00 Seth Hillbrand :
>
>> ​Hi All-
>>
>> Currently, the build requires the opencascade community edition.  For
>> various reasons, I need to have the current non-community edition of
>> OpenCASCADE installed on my work machine.
>>
>> The attached patch allows compiling KiCad with either the OpenCASCADE
>> community edition or standard edition.
>>
>> I've tested on a homebrew-based Mac install as well as Linux but haven't
>> verified MSW, if someone would be willing to test it there, that would be
>> great!  The basic search routines are lightly modified from FreeCAD's logic
>> and keep their LGPL copyright on the CMake file.
>>
>> -Seth​
>>
>>
>> ___
>> 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)

[Wayne Stambaugh]

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

[Kicad-developers] Dealing with multifunction pins (Symbol)

[Augusto Fraga Giachero]

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

Re: [Kicad-developers] [PATCH] Allow OpenCASCADE standard edition

[Cirilo Bernardo]

OCCT is usually quite a few commits ahead of OCE; in fact OCE is
usually based on the earlier release of OCCT. In addition to that,
since we build in MSYS on MSWin, a patch (which is an ugly hack) is
required to support non-ASCII characters in file names.

- Cirilo

On Mon, Jan 29, 2018 at 8:08 PM, Simon Wells  wrote:
> please see https://lists.launchpad.net/kicad-developers/msg31544.html
>
> There are different minimum versions required of OCCT and nick also had
> issues with occt working iirc
>
> i think i would still prefer being able to set whether to allow occ in place
> of oce as was my initial thoughts but i have not worked on this due to the
> issues experienced by nick
>
>
> btw as oce is just a fork of occt would that not have the same issues?
>
> On 30/01/2018, at 9:04 AM, Wayne Stambaugh  wrote:
>
> Hey Seth,
>
> One of us missed something.  Here is my interpretation:
>
> The opencascade website license states:
>
> "Open CASCADE Technology version 6.7.0 and later are governed by GNU
> Lesser General Public License (LGPL) version 2.1 with additional exception."
>
> It makes no mention of later versions of the LGPL (including the
> exception) so I am interpreting this as v2.1 only.  I do not have a copy
> (and I'm not going to sign up to get a copy so please check the
> copyright in the source to see if it matches the website) of the
> opencascade source archive to see if the license in the source
> specifically states "v2.1 or (at your option) any later version" which
> is typically how the GPL and LGPL are used.  If it does, than I can
> safely add this patch because I can make the claim that I am using
> opencascade under at later version of the LGPL which is compatible with
> the GPL 3 used by kicad.
>
> According to the folks at the FSF:
>
> "Please note that GPLv2 is, by itself, not compatible with GPLv3.
> However, most software released under GPLv2 allows you to use the terms
> of later versions of the GPL as well. When this is the case, you can use
> the code under GPLv3 to make the desired combination. To learn more
> about compatibility between GNU licenses, please see our FAQ."
>
> I hope this clarifies why I am hesitant to merge this patch and what
> needs to clarified.  Isn't licensing fun! ;)
>
> Thanks,
>
> Wayne
>
> On 1/29/2018 2:47 PM, Seth Hillbrand wrote:
>
> Hi Wayne-
>
> My reading of your links is different.  Here's the relevant quote:
>
> "GNU Lesser General Public License (LGPL) version 2.1 (#LGPLv2.1) This
> is the previous version of the LGPL: a free software license, but not a
> strong copyleft license, because it permits linking with nonfree
> modules. It is compatible with GPLv2 and GPLv3."
>
> Did I miss something?
>
> -Seth
>
> 2018-01-29 11:18 GMT-08:00 Wayne Stambaugh  >:
>
>Seth,
>
>There maybe licensing issues involved with this.  OpenCascade is
>licensed using LGPL v2.1 not v2.1[1] or later.  LGPL v2.1 is not
>compatible with GPL 3[2].  If OpenCascade is willing to change their
>license LPGL 2.1 or later or if this is just an oversight on their part,
>than I can include this patch.  Please verify the OpenCascade license
>with something that I can verify to ensure we are not violating and
>licensing terms.
>
>Cheers,
>
>Wayne
>
>[1]: https://www.opencascade.com/content/licensing
>
>[2]:
>https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses
>
>
>On 1/29/2018 1:54 PM, Seth Hillbrand wrote:
>
> Hi All-
>
> Currently, the build requires the opencascade community edition.  For
> various reasons, I need to have the current non-community edition of
> OpenCASCADE installed on my work machine.
>
> The attached patch allows compiling KiCad with either the OpenCASCADE
> community edition or standard edition.
>
> I've tested on a homebrew-based Mac install as well as Linux but
>
>haven't
>
> verified MSW, if someone would be willing to test it there, that would
> be great!  The basic search routines are lightly modified from
>
>FreeCAD's
>
> logic and keep their LGPL copyright on the CMake file.
>
> -Seth
>
>
>
> ___
> 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 :