46
Messages
This section allows you to view all Messages made by this member. Note that you can only see Messages made in areas you currently have access to.
Messages - doub
47
Tools of the trade / Re: 3D Gerber Viewer
I've just uploaded a new version tagged 20140207T0140 fixing that bug.
As for the ZIP opening, it's not straightforward to implement, so I'll keep the feature request in mind and eventually implement it when I find an opportune moment. I have another bug that touch similar code paths that I've been planning to fix for some time, but I can't promise anything right now.
48
Project logs / Re: A development board for Lua programming
I already had the parts, so yesterday evening I soldered a board, but it ended up having lots of solder bridges (a dozen on the MCU alone), so I didn't even bother plugging it (I don't have rework equipment, but I ordered some flux on ebay to try to fix it).
Today I soldered a second one, and it looks much better. Here is a picture:
I just plugged it on my PC while pressing the DFU button and Windows recognized it as a "STM Device in DFU Mode", and properly downloaded the drivers, so I guess it's working alright. Now I have to write some software for it and check if the SDRAM works OK (this is my biggest unknown).
49
Tools of the trade / Re: 3D Gerber Viewer
50
Tools of the trade / Re: 3D Gerber Viewer
The bug is probably in the panelization script. It should re-assign aperture numbers to avoid conflicts. You should report the problem to the Python script author (redirect him here if you're not sure how to explain the problem). For a quick fix, rename the second ADD10 to ADD11 near the bottom of the file, and the D10 just below to D11.
51
Tools of the trade / Re: 3D Gerber Viewer
This error is caused by two appertures using the same name (here D10) in the same file. I'm not sure it's allowed by the Gerber spec. I'll check again.
Edit: The spec actually says: "Once a D-code number is assigned to an aperture it cannot be re-assigned.". So either your file is invalid, or there's a bug in my code. Either way I need the file to check.
52
Hardware biz / Re: Tindie commission increase
53
Tools of the trade / Re: L-Mark LK-320P heat shrink/tube/label printer
Isn't that going to capture moisture or even liquid water between the cable and the tube? This might leak progressively and be problematic for electronic work, no?
54
Tools of the trade / Re: 3D Gerber Viewer
[quote author="matseng"]Oh... Really nice. It got the outer outline of this board right, but failed on the internal cutouts.
It would be incredibly cool if during the compositing of copper, soldermask and silk you could remove silk that is on top of bare substrate or bare copper like the pcb fabs does. It of course won't be true representation of the gerbers, but it would be truer to the actual pcb.
[attachment=1][/quote]
First, the holes in the middle are now properly milled. All zero-width closed lines in the milling/mechanical image (.gml) are interpreted as contours of zones to be removed. This is a bit crude, but it should cover most clear cases.
Second, it is now possible to mask the silkscreen print with the soldermask. This will remove any silkscreen marking not printed on top of the soldermask, which means there won't be silkscreen on top of exposed copper. However, this behaviour is not the default. To enable it, you need to edit your color scheme (the file colors/default.lua in the grbv distribution) and change the value of mask_silkscreen from false to true. This is because some PCB fabs do that mask operation, some don't. And the color file kinda represents how your PCB fab interprets Gerber data to make the PCB (that is, it's more than colours).
Here is an approximate screenshot of the same board as matseng provided as demo, with these two features enabled:
[attachment=0]
As always, comments and suggestions are welcome. I see regular crashes reported to my server, but nobody is complaining either here or to me by email. I fix some, but others require an exchange with the user, and the crash reports are anonymous by default so I can't contact affected people.
PS: I introduced a last minute bug in the version tagged 20140107T0023, so if you downloaded it while it was advertised here, please upgrade to a newer version 20140107T0117.
55
Project logs / Re: A development board for Lua programming
It's all 6mil tracks and 6mil spacing (actually 0.15mm since I'm doing it all in metric). It's the first time I use tracks that small, it's also part of the experiment.
[quote author="kenyee"]why not port to the STM32F429 Discovery?[/quote]
Well, it's an overlook on my part, I think I'll order one and start development with it. It's a bit large though for the first project I had in mind, and it's missing the SD card slot.
56
Project logs / Re: A development board for Lua programming
Thanks for the pointer. This is a little big for the space I have (it would fit but with very small clearance). I've found discrete TVS diodes in 1005 (metric) package that would be more appropriate.
[quote author="jiri"]I'm not expert in EMC, but why do you make pcb on 2 layers. 4 layers would be better for EMC.[/quote]
The main reason I'm using two layers is that the free version of EAGLE only allow for two layers. So I've only ever worked with two layers. If I meet big problems with the SDRAM I'll probably investigate options for more layers.
[quote author="jiri"]There is SDRAM and high speed wires without ground under wires.[/quote]
[quote author="gtz"]Nice board, but it looks like if the traces to the SD-RAM are all of different length.
I've not tried to do such a layout my salve, but have read about more than one project, where they had to do multiple layouts, because the unbalanced lines to RAM causes phantom bugs.[/quote]
I can't find how to measure a signal length with EAGLE (I know it can work with differential pair length matching, but I don't think it can work with a whole bus like that). Unless I find an easy solution rapidly, I'll have a try like that, and then diagnose the problems.
[quote author="gtz"]I like your board, but would like one with ethernet. The chip you've selected already contains an ethernet MAC, so all you need to add it a PHY, but I realize, you're low on space.[/quote]
I could have squeezed another chip (or gone double sided for components). But just like for the USB high speed UTMI PHY, I didn't put an ethernet PHY on-board because of the number of GPIOs it removes from the MCU. I'm already quite disappointed to only have around 60 even though the MCU has 144 pins. Like UTMI PHY I imagine a daughter board could be made for Ethernet. If my board ever gain popularity (which I highly doubt) I'll consult the users to see if many would like Ethernet or high speed USB on the main board.
[quote author="nickjohnson"]I love the board, especially the routing. Did you use a topological router, or do that by hand?[/quote]
All the routing is done manually. I've always been disappointed by the EAGLE autorouting, in good part because I find the results ugly. I feel the need to do beautiful routing, I'm not sure why. Maybe it's to make the little electrons happy when they travel my traces, so that they are less inclined to misbehave :D
And I've only recently discovered it's possible to offload the routing to secondary software and re-import the result in EAGLE. But even though it's time consuming, I'm quite easily losing hours routing my boards. It's like a puzzle I feel the urge to solve.
57
Project logs / Re: A development board for Lua programming
Yes, but the high speed controller in the MCU has a full-speed capable internal PHY. It's labelled HS to distinguish it and to relate to the STM32F4 manual.
An external UTMI high speed PHY consumes a significant amount on pins on the micro-controller, so I've let that for daughter boards. I'll consider it in future revisions if there's a demand, but right now for me GPIO pins are more important than high speed USB, especially given that when programmed in Lua, reaching that high a data throughput might be hard (you'd probably need to complement Lua with C code for such tasks).
58
Project logs / Re: A development board for Lua programming
The board fits on the free version of EAGLE, which is available for Windows, Mac and Linux. But if you can't install it, there's a link to the schematic in PNG format at the bottom of my previous post.
[quote author="mip"]One point that caught my eye from looking at the boards is the traces to the SDRAM: The trace lengths should match.[/quote]
Unfortunately, the STM32F4 has external memory signals on all four sides of the LQFP144, which is 20mm wide (twice the distance between it and the SDRAM). Maybe half of the signals are on the side I placed next to the SDRAM, but the others are scattered around. I don't see how I could fit 20mm of spare length for these 20 or so signals to match the ones further away, especially on a 2 layers board.
That being said it's the first time I work with SDRAM. It is single data rate, 166MHz clock (from the chip spec, I guess I can run it slower). Do you think signal length matching will matter that much?
[quote author="mip"]Check the JTAG pins (PA13,14,15,P_B_3 (not P_D_3), PB4, don't split those signals to different io headers). Or better: provide footprints for a standard JTAG connector.[/quote]
I did check them, they are all available, but on different headers (some on the bottom, some on the left). I exposed all I/O pins of the MCU in almost the same order as the package to simplify routing. I'll see if I can move all the JTAG ones on the same side.
A standard JTAG connector might be more complicated to put. Keep in mind that the board might be smaller than it looks. The external headers pitch is 2mm, not the usual 2.54mm.
And for a little background, I didn't put too much effort into exposing JTAG because the MCU contains a USB bootloader hardcoded in system memory, so reflashing the chip should be easy to do just using the USB port. Basically I expect that very few of the intended users might have a need for JTAG besides me.
[quote author="mip"]USB ports should have transient voltage suppressor (TVS) diodes.[/quote]
My STM32 projects using USB have so far been alright without these, but I must admit that I was much more space constrained. Moving to the SoB format freed 2mm on that side of the board, so I can probably add these.
That being said I designed the USB ports to be optional, so that the 3 pins (D+, D- and ID) of each port can be used as GPIO. I'm a bit concerned that puting TVS diodes on these lines may reduce their usefulness as GPIOs. In particular the same pins I believe are used for the CAN transceivers, and I don't know if these diodes would be a good thing or a bad thing for CAN.
But I never used TVS diodes, so I'll document myself before deciding.
[quote author="mip"]The IO headers should have VCC, GND on the same positions. Maybe GND, VCC, GND starting on pin 1 so that a GND pin could be sacrificed as an index pin when connecting flat ribbon cable connectors (or use double row connectors, which are more common).[/quote]
The two side headers have completely different signals, just what happened to be there on the MCU package. It's not like a generic side port with the same functionality. What would be the added value of having the power pins on the same position in that case?
[quote author="mip"]Provisions should be made for a 32khz xtal.[/quote]
I'll see if I can put the footprints for a crystal, even if I don't populate it. I exposed the VBAT pin, so I guess some might want to use this in very low power scenarios and use a RTC when in sleep mode.
[quote author="mip"]Check the space between board edge and io connectors. At least the connector on the long side should be able to be soldered with a 90° pin array to be able to plug it directly into an experimenter's board.[/quote]
I'll check that, but with a 2mm pitch header, it won't fit on a regular 2.54mm breadboard. I'll see if they make 2mm breadboards, or maybe see if I can make an adapter board.
[quote author="mip"]There's plenty of room left, maybe add some "prototyping area" next to the pin rows.[/quote][/quote]
There is not that much space left. Keep in mind that the headers pitch is only 2mm, and having only 2 PCB layers to play with I don't have lots of flexibility for routing. Also my assembly skills are limited, so if the board gets too dense I won't be able to assemble the prototypes.
Anyway, thank you very much for the feedback. Please have a look at the schematic and tell me if you see something broken. I'm especially not sure about the DFU button handling.
59
Project logs / Re: A development board for Lua programming
A couple of 3D renders:
Also links to an image of the schematic, the schematic and the board files for EAGLE.
60
Hardware biz / Re: Tindie commission increase
However I'm not sure it justifies 45k$ per month in expenses, unless I'm completely under-estimating the amount of transactions happening on the website.