STM32F407G-DISC1- Discovery kit with STM32F407VG MCU

[vanepp]

@microMerlin

FritzingCheckPart has a lot of complaints about this part file.

None very serious. Most of them are about terminalId in breadboard in the fzp file but not breadboard svg which is likely a parts factory issue.

@microMerlin

When I try to save the breadboard as optimized svg, Inkscape (actually output_scour.py) crashes on the save. Something about an element not in a list. It works on other files.

I expect this is an Inkscape bug. On Inkscape 0.9.4 using this as the output format, saving as optimized svg works:

it saves fine (but doesn’t collapse the groups) and the error message sounds like python looking for an element that isn’t in the list.

@Old_Grey

I could stack all the GND pins on top of each other, and it’s probably more correct, but it makes it hard for a beginner to do.

I used to be of the same opinion (still am somewhat ) but the problem in schematic with multiple pins all in the same group is that only one connection can be made to the entire group. The result of that is that sometimes a wire won’t connect because there is already a connection elsewhere in schematic, so Fritzing won’t make another. Unfortunately overlaying the pins fixes that (even though I don’t like it.) The converse is (as in the Atmega2560 IC in core parts) if you don’t bus the pins that you overlay then routing breaks because not all the pins get connected to (and this one affects pcb as well!)

@Old_Grey

The 0.1" pins in SCH is not what is being done in FZ, ie, that is an out of date stipulation. 0.1" works with small parts, but are wildly disproportionate with large SCH parts, ie, it just looks weird. FZ it’self uses 0.2" for ICs.

I don’t know if this is correct or not. I think the parts factory code is old and wasn’t updated. It is true that generic IC uses 0.2in pins, but that doesn’t match the graphics standard document (which I think came later.) The practical reason that I at least favor 0.1in pins in schematic is that it makes the parts smaller and thus more will fit on one page, although I agree they look a little odd on larger parts, my view is that the space saving is worth it. I’m hoping to eventually fix up the parts factory to emit parts that match the graphics standards, but it is going to be complicated because there is already version dependent code in there (for compatibility with older Fritzing versions.)

@Old_Grey

I’m not interested in making debug pins active.

If it’s junk I can just delete my tutorials

I wouldn’t say it is junk, it looks to be serviceable as it stands. As far as I can see the buses are correct and the non debug pins all seem to be active so it should work fine. If someone wants the debug pins for something, they can add them later. The lack of logos (which are hard to make!) doesn’t affect the Fritzing functionality, nor do the missing terminalIds in breadboard, Fritzing defaults to using the center of the pin, which is correct in this case.

@Old_Grey

INK is so bad at drawing, and FZ is so bad at interpreting INK

This is more a case of Inkscape aiming for its primary market (CSS compliance ) and Fritizng having a different goal (and/or not being CSS compliant because it doesn’t need CSS.) That is a lot of the purpose of FritzingCheckPart.py to adjust the xml that Inkscape produces to match what Fritzing is expecting (and/or will tolerate.)

Peter