Pre-installed symbols faulty?

Hi there,

i just created a pull request for my Z32F06423AKE MCU.
Travis says it’s okay, but the other two symbols in the Zilog Library (Z80CPU and Z8530 i believe) are faulty and therefore, Travis exits with return code 1.
Are there any other libs that are faulty by default?
I will repair this as i find some time for this.

Best regards,
Fabian

According to https://github.com/KiCad/kicad-library/wiki/Status-of-the-libraries only 17.5% of the libraries are fully compliant. The KLC tends to change frequently, so previously compliant libs become non-compliant… so yeah, most of the libs are “faulty” in that sense.

If you run the Python check-libs scripts, they can sometimes autofix errors, might be worth looking into.

1 Like

Okay, i found it.
For symbols with both an inverted pin and inverted pin description i would change the pin type to a normal line, because i think that the inverted text is more recognizable.

Regards,
Fabian

If you click on Details it shows the Travis log, if that helps

I assume this is your pull request: https://github.com/KiCad/kicad-library/pull/1366

Your pull request changed the two other symbols. (see tab: changed files.)
I think it changed the order of some lines.
This is why travis does check these other symbols. (Travis is configured to only look at changed symbols.)

To answer your original question (What should you do if you find an error in the lib?)
From the FAQ: https://github.com/KiCad/kicad-library/wiki/Frequently-asked-questions

I’ve found an error in a symbol/footprint/model - what now?

The answer, as often happens, is it depends.

Search outstanding Issues and Pull Requests

If there are outstanding issues and/or pull requests for the repository, search those to see if anyone else has found the same issue - maybe they have addressed it previously.

Find the original author

It may be possible to ascertain the original author of the file(s). Perhaps there is a particular (and valid) reason they have submitted the file in a particular way.

Find the source of the file

Many files in the KiCad library are generated from script sources. If this is the case, you should alter the original script, and not the output files themselves.

Run KLC scripts with the --fix option

Some errors can be automatically* fixed with the KLC python scripts, by using the --fix command line option. If you fix a file with this, ensure that the file is thoroughly checked before resubmitting

Manually edit the file

The KiCad library is community driven. Show some community spirit :slight_smile:

2 Likes

But I didn’t touch the Z80CPU and Z8530 at all.:open_mouth:
Well, nevermind… i’ve corrected the double inversion and set the datasheet field of the Z8530 to “none” (There is none in fact…) and now Travis is happy…

There is a datasheet here http://www.zilog.com/docs/serial/ps0117.pdf. Z8530 is obsolete but Z85C30 is an active part.

git diff disagrees.
(as i said above the order of some lines did change. Originally the lines starting with S where behind all the lines starting with x, after your first change these lines moved to the front of the lines starting with x.)

KiCad doesn’t guarantee to read/write data in the same order, quite probably differs between versions. Why don’t the checking scripts ignore the order of lines, since it’s not important?

1 Like

Because nobody implemented this feature.
@SchrodingersGat would this be possible?

The checksum is done by concatenating all the lines then doing an md5 hash, so it’s sensitive to line order. Possibly, sorting the data before running through md5 would remove sensitivity to line order and not break update detection, but I haven’t thought through all the scenarios where line order might matter. I can’t think of any right now.

I have definitely seen datasheets with both the active low bubble and the line over the text

Seen does not mean complying with any standard. (I’m not even sure that having a bar over a signal name does comply with any standard. But i don’t really have access to a good standards book.)

I’ve always found the use of bubble or overbar (or “#”, “/” “n”, “*” etc) quite variable.

An advantage with NOT using the bubble in KiCad is that it allows shorter pins and maintain legibilty. KiCad centres the text in the pin regardless of the bubble. At 150 mil, the pin number starts to overlap the bubble.

In order to comply with KLC and also keep symbols compact and legible, I am using overbar in preference to bubbles in the new 74xx lib. I am not sure this is the best way, but “legibility” is quite hard for a script to determine, so I have adopted a simple and consistent rule.

1 Like