Creating a low-cost pin-compatible Arduino/Due board using an STM32L471

hello, i am a software libre and hardware advocate and engineer of over 20 years experience working with software libre. i'm currently based in Taiwan, and have learned that Mega 2560 clones can be bought in the Huaqiang Road markets for around $USD 5 and RAMPS 1.4 3D printing shields for around $USD 3.50.

this got me thinking, how can i reduce the cost of say the Arduino Due to the same sort of pricing level, and the short answer is: you can't. Atmel (now Micron) do not accept the reality of competitive pricing in Shenzhen / Taiwan: consequently whilst the 2560 is RMB 22 (around $3 US) on the china-equivalent of ebay, the ATSAM3X8E is double that - around $6. with all the extra components on the Due, including the Management Mega, it is no surprise that the Due is still $USD 15 and that's direct from factories in Shenzhen.

however.... if you look instead at the pricing on ST's MCUs, you notice something very very interesting. prices in the markets are sometimes under HALF that of their equivalent US / EU levels. other companies such as Freescale (now NXP) are also known to do this.

so with the help of the stm32duino community http://www.stm32duino.com/viewtopic.php?f=9&t=2630 i've been working on an arduino compatible board which uses the STM32L471. what's very nice is that someone has already done an arduino development environment board variant for the STM32L4 range: GitHub - GrumpyOldPizza/arduino-STM32L4

also i've just replaced the FT232 ($USD 2.50) with the same CH340G ($0.30 or less) that is in the chinese ATMEGA r3 clone sitting here on my desk, thanks to sparkfun's eagle files at SparkFun Serial Basic Breakout - CH340G - DEV-14050 - SparkFun Electronics this took about an hour.

i've yet to get a quote (the whole of china is on holiday this week), and anyone is entirely free to do so as it's entirely libre (Index of /~lkcl/stl47o and you can use git clone Index of /~lkcl/stl47o/.git) however i expect the BOM to come out somewhere around the $6 to $7 mark.

this would be for a fast, modern ultra-low-power 32-bit ARM Cortex M4 processor - 80mhz - with an on-board DSP and hardware floating point single-precision co-processor, and i'm planning on using the 100-pin STM32L471VE variant which has 512K of FLASH and 128k RAM. other variants are possible and are listed here - they go up to 1024K (1Mb) of FLASH and the L451 can do 160k of RAM. http://www.st.com/en/microcontrollers/stm32l4x1.html?querycriteria=productId=LN1464

pin-compatibility with the main published functions of the Due are identical: the L4 series has the same number of ADCs (16) and DACs (2) but the shared multiplexing functionality meant that i had to do the same as the Due: CANTX and CANRX on pins 13 and 14 (which do NOT have ADC multiplexed function) and DAC on analog pins 15 and 16 (which do also have an ADC function on the L4 series).

one variation: the L4 series has four SPI ports, so i was able to put one of those onto ICSP, and the other onto pins 50-53 including the hardware-controlled NSS line.

booting and flashing i am currently investigating whether the RTS as well as the DTR lines can be used, RTS (ready-to-send) for BOOT0 and DTR (as usual) for RESET. the whole of the STM32 series has one extra line, BOOT0, which tells it whether to boot from NAND or from internal ROM bootloader. this would save $1 to $2 on the BOM by not having to have an extra "Management MCU".

the other alternative is to upload dfu-compatible bootloader firmware first developed by the Leaflabs Maple team, which software-emulates DFU and does loading into memory / NAND "manually" so to speak. i much prefer the RTS/DTR method, it's been discussed here before (biig thread on the maple arduino 1.5 port that inspired the creation of the stm32duino forum), however i just also found this:

he uses DTR# only, with the capacitor trick to create the spike needed for reset, and leaving it set to create the BOOT0 signal. the only thing is, BOOT0 needs to go high for it to be operational, and NRST is on a permanent internal pull-up resistor and needs to be pulled LOW. also whilst the CH340G is DRT# (inverted logic) i just checked the MEGA clone's CH340G and both DTR and RTS measure at 5.0V.

so! thoughts and help greatly appreciated. firstly on helping with a circuit to get automatic reset (i found that there's a patch to stm32flash to add a "-t" option), and secondly, would people be interested to buy this board either the first batch of prototypes (or when it's ready - properly QA checked before shipping direct from Shenzhen of course). the full eagle SCH/PCB files are of course available so anyone may download and make them.

  1. I'm a bit hesitant to give up the "native USB" port that is present on Due.
  2. That's a really big MOSFET you've got there! (I guess it's from the MEGA reference design. Newer boards have a little SOT23 Mosfet.)
  3. Full sized USB-B Connector? I guess they're nicely "robust" compared to the SMT Micro-Bs that frequently show up, but they're pretty out-of-style.
  4. Class USBVCC should probably have the same clearance/width spec as "power." Or +5V should be in class "power". And maybe a bit bigger clearance for all the power classes?
  5. The bottom-edge "power" connector is the only one with oval pads; they look overly large. Even when I use ovals, I like to change the elongation factor down to ~50% so that they're not so "greedy."
  6. So... don't you need quite a bit of volume to go from "$6 BOM" to "less than $15 to the end user"? Is that actually likely to happen, especially since you're more-or-less competing with the Tiva and MSP432 LaunchPads, and the various low-cost eval boards from ST themselves. I'm not sure that the difference between a $10 STARMMEGA vs a $20 DueClone is "compelling", especially given "unknown" support status (not that Due support has ever been really "good." :frowning: )

I don't have any ideas on auto-reset. "Modern" trends seem to go toward the "manual" non-ROM bootloader, which doesn't seem like that big a deal given modern memory sizes.

SAMD51 might come along and upset the applecart.

  1. Doesn't have the "R3" extensions (I2C on top, mostly.)
  2. if you're going to route between the pins of the rightmost connector, you might as well let the groundplane go between the pins of top and bottom connectors, too.

hiya westfw, really nice to hear from you, really appreciate you taking the time to take a look at this design, i saw you're a big contributor here (the big maple thread for example), and you clearly actually downloaded the sch and brd file and took a look at them.

first thing, i should have mentioned: i started from the Mega2560 Reference Design, as i wanted to aim for lower-cost yet high-end features at the same time. the Due Reference Design also would have meant a lot of work cutting out and changing much more than i was happy with, also it uses 0402 components where i preferred in this case to use 0603 and preferably 0805. by using the older Mega2560 design i was able to quite literally leave... maybe... 50% of the actual existing board layout completely untouched.

... unfortunately as you've noticed, arduino.cc didn't put the r3 Reference Design online... and i didn't notice that. whoops. ok so i'll update that accordingly... let's go over things.

  1. native USB port: ah, you mean with full USB-OTG functionality native on the MCU? yyeahhhh it surprised the heck out of me to learn that the STML4 series... doesn't have USB at all! i mean... it's just 2 pins, what the heck? maybe something went wrong in the layout, they ran out of time, and decided to ship it anyway, who knows? anyway, i just went with it....

  2. yes it's from the Reference Design :slight_smile: 800mA which i'm more comfortable with than the 0.5W spec of the FDM340P. i guess though that the DPACK version of the MC33269 is a bit overkill... :slight_smile: i'll swap that for the SO223.

  3. yes full-sized. nice and cheap in the Shenzhen Markets. also from the Reference Design. it also says "no confusion about this not supporting OTG or native USB or anything".

  4. power classes... yyeahh again that was from the original... i think i know why they did it: they had to get some of the power lines through some extremely tight gaps, but the USBVCC didn't actually matter as it was far enough away from everything. the board's so densely populated with tracks for a 2-layer board it could turn out to be a heck of a lot of work... i'll do an investigation.

  5. reference design again.... using the standard pinhdr library. it actually stopped flood-fill from completing round the edges, i wasn't so bothered about power... i have to replace that header anyway so will sort that

  6. i'll find out pricing on some quotes next week, bear in mind i have a slightly different attitude to this than you'd normally find: if chinese companies start cloning this GREAT, they'll save me the hassle and i'll buy from them. i have a lot else to get done

6a) ATSAMG51 - looks nice! it'll also likely have that native USB port as well. thing is... it's $5+ in 1k volumes, and it'll stay $5+ in 1k volumes even in the shenzhen markets. the L4 series will be half that (only in the shenzhen markets).

  1. argh! i missed that. ok, 1/2 way through fixing the R3 extensions. AREF pin and I2C are what i can see. i'm going to have to connect I2C to pins 20 and 21, there's really nothing spare (only 2 pins left and i need those!). luckily i already have I2C come out nearby.. this is a really densely tracked board!

7a) those right-most connectors are from the reference design... i don't know why they have them smaller pads than the standard pinhd.lbr ones, but it's a good call. i'll see what size they are then reduce all the other headers to the same size. yes allowing GND through them would be... good.

ok so i've done the r3 mods (i think - AREF at the bottom, I2C at the top), also put the less-beefy SOT223 on... changed the pinheader footprints... did i miss anything?

really appreciated your insights btw.

helping with a circuit to get automatic reset

Hmm. How about replacing the ch340g with a cheap usb-capable micro, ala the 16u2 used on real Uno/Mega2560 (but cheaper.) I don't know what's cheap in China, but the STM32F070 might be a candidate. It would be nice if it were capable of "crystal-less" operation, of course.

native USB port: ah, you mean with full USB-OTG functionality native on the MCU? yyeahhhh it surprised the heck out of me to learn that the STML4 series... doesn't have USB at all!

I'd be happy with just "USB device." Perhaps the USB circuitry doesn't fit into the "low power" regime that that 32L series is supposed to occupy.

  1. [mosfet] 800mA which i'm more comfortable with than the 0.5W spec of the FDM340P. i guess though that the DPACK version of the MC33269 is a bit overkill... :) i'll swap that for the SO223.

The big 5V regulator is ok. Good, even - people tend to plug the external supply jack into 12V wall warts (could be 16+V if "unregulated"), and they need whatever extra power dissipation can fit on the board. The MOSFET is a power switch, so it actally has very low dissipation. The FDN340 says Rdson is down around 0.07 ohm, so even at 1A it's dissipating less than 100mW...

i'm going to have to connect I2C to pins 20 and 21, there's really nothing spare

That's fine. Most of the existing boards parallel them with some other pins; I think they're more to provide a "standard location for I2C" than "extra pins."

I really don't like the part libraries that the Arduino folk used. I don't understand the round SMTs, and the silkscreen layer is very sparse - I tend to like lots of silkscreen. I'm not sure if there's an easy way to do a wholescale change, though...

westfw:
Hmm. How about replacing the ch340g with a cheap usb-capable micro, ala the 16u2 used on real Uno/Mega2560 (but cheaper.) I don't know what's cheap in China, but the STM32F070 might be a candidate. It would be nice if it were capable of "crystal-less" operation, of course.

ahh you had to tempt me with my favourite STM32 MCU, didn't you :slight_smile: i love the STM32F072, i'm using it for a USB-based keyboard and mouse (actually CTP with SPI-driven 320x240 back-lit LCD) and power-management controller in the EOMA68 15.6in Libre Laptop i'm doing.

the CH340G is pretty compelling: bear in mind this is the chinese-equivalent of ebay, but pricing is a good guide: https://s.taobao.com/search?q=CH340G .... so... between 1 and 2 RMB. 1RMB: USD $0.15. not $2 to $2.50 for an FT232 on digikey, fifteen CENT US. and that's a one-off price.

the 072 (which is my favourite "crystal-less" MCU) is like... $1. it's really no comparison cost-wise. that's just too big a hike. i realise you could reprogram the STM32F072 to be an OTG device (i use it to do 2 USB-HID EndPoints for the EOMA68 Libre Laptop, using a fork of libopencm3), it's just.... nngggh :slight_smile:

I'd be happy with just "USB device." Perhaps the USB circuitry doesn't fit into the "low power" regime that that 32L series is supposed to occupy.

being absolutely honest here: i picked the 417 because it seems popular enough to have halved in price in the shenzhen ecosystem! that it's ultra-low-power is like... a huge bonus.

The big 5V regulator is ok. Good, even - people tend to plug the external supply jack into 12V wall warts (could be 16+V if "unregulated"), and they need whatever extra power dissipation can fit on the board.

ok. that makes a lot of sense. i put it back :slight_smile:

The MOSFET is a power switch, so it actally has very low dissipation. The FDN340 says Rdson is down around 0.07 ohm, so even at 1A it's dissipating less than 100mW...That's fine.

ahh very handy, i wondered how to do those calculations. ok i get it. so the power loss due to internal resistance is what you have to watch out for, and you check the rated power capacity against that, not what the MOSFET is handling (passing through it). i thought that was the case, just never had it put into a useful example. thank you for doing that.

Most of the existing boards parallel them with some other pins; I think they're more to provide a "standard location for I2C" than "extra pins."

yehyeh makes sense.

I really don't like the part libraries that the Arduino folk used.

they're a bit... odd :slight_smile: Reference part numbers are on a separate layer (49).

I don't understand the round SMTs,

i didn't really get them either, but i've found that it's possible to cut corners on the tracks, get between them in circumstances which you simply would not be able to do if using rectangular footprint pads. for a 2-layer densely-packed board that turns out to be really really crucial.

not seen it done before, don't know if it's going to mess up when it comes to assembly, putting a component onto a pad where there might be a track on a different NET covered only by the green layer just underneath it... it's not something that would work on the lower-priced Eurocircuits "bare copper prototyping" board, that's for sure.

and the silkscreen layer is very sparse - I tend to like lots of silkscreen. I'm not sure if there's an easy way to do a wholescale change, though...

in eagle? yes there is... you can set "layer". i put a keyboard-macro onto Alt-4: DISPLAY ALL -27 -28 -31 -35 -52

and another one onto Alt-5: DISPLAY NONE +144 +145 +146 +23

that one's for when you want to delete all of the auto-generated drill drawings.

i got reaally fed up of flipping layers on and off by hand... PADS is really sensible, all config / settings dialogs are Modal, and you also have a visibility "toggle" command which doesn't affect the display settings... just overrides them temporarily... Z1 enables layer 1, Z 1 6 layers 1 and 6, Zz flips off all hiding back to what you had before.

anyway you can do something similar to those macros ("DISPLAY NONE +49") to switch on Layer 49 ("Reference") only, then use "CHANGE LAYER {insert silkscreen}" do a group-select or something....

... but i did it a different way: all i did was... add Layer 49 to the silkscreen gerber-generation job. sorted. weird, but sorted.

I'm not sure if there's an easy way to do a wholescale change

yes there is... you can set "layer".

I mean "replace all the 0805RND packages from their RCL library with "My favorite 0805" package from my "myrcl" library, or the equivalent.

the 072 (which is my favourite "crystal-less" MCU) is like... $1

I suppose. But you also eliminate a crystal and a bunch of other components associated with the auto-reset function - those are probably worth another $0.20 or so?

add Layer 49 to the silkscreen

Yeah, I usually finish things off by running "silk-new.ulp", which copies all the relevant objects to a new layer, where they can be shifted around/deleted/added/duplicated at will. But in this case, I'm objecting that the RCL packages don't have any outlines or symbols on them to copy...

If you want some help doing a "final" layout cleanup, let me know. I seem to enjoy that sort of thing :frowning:

westfw:
yes there is... you can set "layer".
I mean "replace all the 0805RND packages from their RCL library with "My favorite 0805" package from my "myrcl" library, or the equivalent.I suppose.

ohh i thought you meant just workaround what they did. yyeahhh i would start to look at editing the XML file by hand and using global search/replace, see how that went.

But you also eliminate a crystal and a bunch of other components associated with the auto-reset function - those are probably worth another $0.20 or so?

there's actually only 6 components in the entire circuit: an SOT23-5 inverter buffer (turns !DTR into BOOT0, whilst !RTS is wired onto the standard capacitor-series-driven RESET)), a 0.1uF cap shared between the CH340G and the inverter, a 12mhz 3225 XTAL and its two 20pF capacitors. that's all.

just looking up an arbitrary quote for 100 of something-or-other the line with the 3225 24mhz XTAL was RMB 0.8 which is... around USD $0.12. the 74-series inverter probably around the same (ish)... ignore the caps (< $0.001...) and it can't be more than $0.50 total, which is under half what the STM32F072 would be.

still, the 072 it is still really compelling because you just know they have a MCU (usually an 8080) in these USB-UART ICs, almost certainly doing bit-banging of the USB lines but nobody notices and it's a black-box anyway.

Yeah, I usually finish things off by running "silk-new.ulp", which copies all the relevant objects to a new layer, where they can be shifted around/deleted/added/duplicated at will. But in this case, I'm objecting that the RCL packages don't have any outlines or symbols on them to copy...

ohh whoops, i get it now. ok, so as a near-first-time eagle user (started 2 weeks ago) i seem to have missed things like what silk-new.ulp does: i'll look it up. i seem to be managing ok with adding layer 49 to the silkscreen...

If you want some help doing a "final" layout cleanup, let me know. I seem to enjoy that sort of thing :frowning:

ha, appreciated. or just a review before sending off would be great. is the layout cleanup automatable? as a software engineer primarily i'm not a fan of repeating things unless i actually need to pay attention... looks like there's a -C {command} option... and a -N (switches off all prompts).... looks like that's primarily for CAM processing but that's what we have in mind anyway.

darn it i really really want to use the 072 as, being fully programmable, it's a lot less risk. if there was any other tiny processor with USB that was $0.50 i'd use it, definitely. i'm actually having to think, here, make sure i get the BOOT0 handling right: an 072 i could just wire up a GPIO to it and be done, because errors in design could be taken care of with firmware. sigh...

if there was any other tiny processor with USB that was $0.50 i'd use it, definitely.

I'd be shocked if there isn't some Chinese product that would work. STC, perhaps?

is the layout cleanup automatable?

Not that I know of. It's a lot of pushing tracks around "a little bit", ripping up and re-routing a small subset of them at a time, and stuff like that, trying to make things look "even" and pretty without changing the electrical at all. Some people hate it...

westfw:
I'd be shocked if there isn't some Chinese product that would work. STC, perhaps?

nom, nom, nom... GitHub - grigorig/stcgal: Open Source STC MCU ISP flash tool hmmm never heard of STC before... oh look! they're used in those ubiquitous PL2303-based things, ha, funny. doh, an app note for an STC15 actually uses... an SOP-8 PL2303 to do USB-to-UART, doh!

Not that I know of. It's a lot of pushing tracks around "a little bit", ripping up and re-routing a small subset of them at a time, and stuff like that, trying to make things look "even" and pretty without changing the electrical at all. Some people hate it...

oh that! yeah i love doing little minor track-thingies. means i get to do a careful thorough review at the same time.

yeah knock yourself out, let me just do a make upload, i have about 2 other boards i should be focussing on (and a prototype to assemble). one thing, if you look closely at the ADC tracks some of them come in on BOTTOM, some on TOP, all into the same area (very very tight). they were parallel to each other in a big group. what i've done is deliberately pushed them 45, then 90, then 45, in opposite directions so as to get as much of the sets of tracks at right-angles to each other.

i'm keeping "Stop" layer switched on, it shows a keepout area around the octagonal VIAs, which i've found very handy for all this manual checking of clearances.

I2C is along the top between pins 20/21 to the r3 equivalents, it's hard against the board edge (no GND plane), if you think of a better way to do that, feel free.

if you want a challenge tidying up the right-hand connector area to get some GND in between the pins, i discovered that you can actually fit a signal VIA or a GND via and still juuuust about get a track round it on two sides, by putting the VIA near-hard up symmetrically against two of the 2.54mm pins. you can only get 1 track in between any 2 given 2.54mm pins (tried getting 2... even when setting grid to 0.625mil.. doesn't work) but you can have one track come in East, go out North whilst another track comes in West and goes out South... you just can't get a VIA in the middle as well if you do that. but, TOP coming in North going out West, and BOTTOM coming in South going out West you can get a VIA in, jammed up against the East side. never used octagonal pin shapes before: quite like them now.

the other area that's a little dicey is just above the 32.768kHz XTAL, running from the top-left corner of the MCU to round where the words TX, RX and 1.0 are. there are tracks running horizontally parallel to each other, not too happy about them.

looking at it now, i think the set of VIAs just above C1 and C2 could all move to the left of C1 and C2, above the MicroSD card, then the tracks PE1, PE0 and PD7 currently running through the words "V1.0 TX RX" could all also be shifted down, running 45 degrees below the word "RX", which would make them at 90 degrees to the BOTTOM tracks on the other layer.

i figured also get an extra couple of VIAs in round the 32.768khz XTAL whilst at it... anyway do you want to tackle that? you're more than welcome. i'm not going to be sending this off for prototyping for at least... a week (or until i'm happy with it).

This looks great! Especially as the Otto will probably be delayed forever. Put me down for two boards. :slight_smile:

I've been frustrated with the cost of 32 bit boards as well, there are the STM32 "pills", some Uno sized boards, but nothing suitable in the Mega format. I would really like something that is a drop-in replacement for Due so it can be used with shields for 3D printers.

I don't have a lot of time (moving house), but if you have a prototype design I can convert it to KiCad.

bobcousins:
This looks great! Especially as the Otto will probably be delayed forever. Put me down for two boards. :slight_smile:

cool! i can do that :slight_smile: GrumpyOldPizza's repo would be one place to start if you want an arduino-compatible interface, but also libopencm3 supports the STM32L4 libopencm3: libopencm3 Core CM3

I've been frustrated with the cost of 32 bit boards as well, there are the STM32 "pills", some Uno sized boards, but nothing suitable in the Mega format. I would really like something that is a drop-in replacement for Due so it can be used with shields for 3D printers.

funny you should mention that.... RAMPS 1.4.2 fork: RD3D v1.0 (6 steppers, 24v, Due)

I don't have a lot of time (moving house), but if you have a prototype design I can convert it to KiCad.

yeah sure, knock yourself out, git clone Index of /~lkcl/stl47o/.git and use wget on the directory below to grab all the datasheets etc. i tend to just... drop all the PDFs into the main directory, all a bit messy i know but it means they're there when i need then, no need to think too hard :slight_smile:

Wow - A lot changed since the first time I looked at this! There was less to clean up, too.

Updated versions in [/url]https://drive.google.com/drive/u/0/folders/0B6dMB5dovDUZYzhjY2M1NmEtZmI2NC00MDZkLTliODMtOWYzNjQyZmViNWEy[/url]

A couple design comments:

  • Using an SMT reset switch might be advantageous, and cheaper to assemble.
  • Does your micro-SD socket allow traces underneath the socket? Some don't...

"Review" comments:

  • A lot of what I did was "centering" traces leaving the ARM SMTs. There are "issues" with routing grid vs IC grid, and a lot of them had little tiny diagonal trace segments causing the traces to be off-center. Most were barely noticeable, and I don't know if any were "dangerous", but they're all centered now.
  • I increased the power trace clearance to 10mil and did a DRC check to ensure that all the traces/vias conformed EXCEPT for the ARM itself (whose pins are not 10mil apart!)
  • This was mostly accomplished by shifting GND vias a tiny bit toward the center of their flood areas. I eliminated a couple gnd vias for not having any relevant flood on one side or the other, and being otherwise difficult to get to conform.
  • You probably want most of the Vias tented. Do this by modifying the "limit" parameter of the "masks" DRC panel. In my version I set it to 0.5mm (so all vias 0.5mm or less will not have solder mask holes.)

I'd say ditch the Arduino "dog ear styling" and go with plain rounded corners, like we did for "Freeduino", but that's just me being style-less :slight_smile:

westfw:
Wow - A lot changed since the first time I looked at this! There was less to clean up, too.

yehyeh, it's quite common that i'll do one layout then learn from that, chuck the lot and do it again, better.

Updated versions in [/url]https://drive.google.com/drive/u/0/folders/0B6dMB5dovDUZYzhjY2M1NmEtZmI2NC00MDZkLTliODMtOWYzNjQyZmViNWEy[/url]

whoops, schematic's there, but the brd file is a zero-length file!

A couple design comments:

  • Using an SMT reset switch might be advantageous, and cheaper to assemble.
  • Does your micro-SD socket allow traces underneath the socket? Some don't...

hm good idea on the reset switch, i'll look one up. i'll not make any changes yet though, don't want to lose sync with what you've done. sd: yeah it does, it's a very common cheap chinese one that has plastic underneath not metal. i still put a ton of VIAs under it, even though it will only be running at SPI speeds.

review comments look good... i'll be able to respond to when the brd file isn't zero-length any more... :slight_smile:

I'd say ditch the Arduino "dog ear styling" and go with plain rounded corners, like we did for "Freeduino", but that's just me being style-less :slight_smile:

:slight_smile: Me and Mr Eagle CAD are not Best Mates, i would have to learn how to do that and also get over the "workman blaming the tools" syndrome... :slight_smile: i know how it's done in PADS: select two edges, right-mouse, select "stretch arc". easy.... sigh...

whoops, schematic's there, but the brd file is a zero-length file!

Grr. Google Drive apparently doesn't like firefox very much. Things went better with Chrome, and I've uploaded a combined .zip file...

i would have to learn how to [reshape board outline] ... select two edges, right-mouse, select "stretch arc".

Draw new edge in "dimension" layer, use "miter" tool on corners. Delete old edge... (uploaded a "-rounded" version as well.")

westfw:
Grr. Google Drive apparently doesn't like firefox very much. Things went better with Chrome, and I've uploaded a combined .zip file...Draw new edge in "dimension" layer, use "miter" tool on corners. Delete old edge... (uploaded a "-rounded" version as well.")

awesome. ok will take a look!

westfw:
Grr. Google Drive apparently doesn't like firefox very much. Things went better with Chrome, and I've uploaded a combined .zip file...Draw new edge in "dimension" layer, use "miter" tool on corners. Delete old edge... (uploaded a "-rounded" version as well.")

ok so that's committed and uploaded, went over it - really appreciated what you've done.

i did that re-routing around C19 (top left of MCU), i feel happier with the tracks top and bottom crossing at right-angles or 45. also the GND connectivity to C19 was a bit... tenuous: moving the tracks around allowed me to put some better GND connectivity in, jumping several times between the planes.

put in the SMT switch (thanks for the suggestion!). also i am a bit... funny about adding in GND VIAs, i think in 3D, so added some as a 3D barrier around the ADC traces where they come in to the MCU. also there's some areas where i add them to join pieces of GND flood-fill together. on one layer it's GND then track and on the other it's track then GND, and there's this little bit in between where you could fit VIAs in between and get a contiguous GND connection.

it's all the little bits that add up, y'know?

i also really appreciated that you managed to get some GND in between that right-hand connector pins, i was able to add some more in.

btw westfw, i put the GND/Power clearance back to 8mil not because i disagree that it should be (i haven't moved tracks closer) but because when tStop is enabled there's over i think it was 180 DRC violations (!) all on the MCU...

aaaa the flood-fill changes if you alter the POW net class clearance!!! aaaa must remember to put them back to 10mil when doing the gerbers.

i reaaally don't want to have to hit "Approve" on over 180 DRC errors, i might miss one or two of them. or ten. westfw is there a way to do component level DRC like you can in PADS, Altium etc., do you know?

i put the GND/Power clearance back to 8mil

I meant to do that, but I got tied up when I forgot which one(s) had always been 10mil, and forgot to look it up.
I also didn't look at the DRC before changing things...
Hmm. Ok, thanks to the backup files.... ALL the signal clearances were at 8mil, and when we return to that the only DRC warnings are for the mounting holes (on both original and modified versions.)

the flood-fill changes if you alter the POW net class clearance!!!

You can change the clearance of the flood separately from the signal clearance using the "change isolate x" command on the polygons. I like the way it looks with a 14mil "isolation" parameter - that's nicely separate, but still floods between the connector pins.

is there a way to do component level DRC

not that I know of.