Our New KickStarter! Espruino Pico

Yes, the 3 internal pins are GND/3.3v/VCC - they are already on the 0.1" pin strip so are already on castellated pins. The only reason they exist is if someone wanted to make a shield.

Good point about the overlap of pins. It seems insane that you can't stack two sets of 0.05" next to each other. I'll have a think about what can be done, but as @allObjects says the routing is very difficult (I've just had a quick look at it again). The connector only just fits in as it is.

Personally though I think most people will use 0.01" pins, or 'shims' that solder on using the board's castellations. If you're soldering a tiny daughter board onto just the 0.05" pins then you're probably able to snip a tiny bit off time side of pin strip with a pair of pliers.

I looked at the routing (with assumptions for the 3 0.05" pins) and it would need fitting two paths between the 0.05" pin row and the 0.10" pin row. I had routing alternatives which made more room, but because of not knowing the current routing for the 3 0.05" pins, I stopped 'guessing' and trying to find options.

...here some routing thoughts. 1st is with the double paths, 2nd is with a path between the corner pads. Both are not taking the routing of the 3 0.05" pins into account (yet). I do not have manufacturing experience, but it is worth a thought...

2 Attachments

I'm afraid I doubt those will work. For #1 there's no way to get two tracks in there side by side, and for #2 you can't get A4 out inbetween the ground pad and A4's pad.

I have given this a pretty good go - it took me a very long time even to get that many pads in there.

I guess the other (more simple) option is just to swap the position of GND and VDD, such that VDD was the one nearest the end of the board. That would mean that for any device with its own regulator you had no need to fit the pin at the end (see picture for what it's like at the moment).

1 Attachment

One other thing I could do is swap as follows:

So then you had GND available right on the end - might be preferable, but it then means that A4 won't be available by the castellations.

Any thoughts on this as a different layout?

I didn't really want to change the board much after my last set of protos, but I guess this might be worth it. It's pretty much a given that someone, somewhere will complain about A4 though.

It'd be good to get this sorted soon - ideally I would have sent it to Jaltek yesterday, but I'm still waiting to hear back from Abracon about the suggested load capacitance to use for their 32k crystal.

Just did a test and the board really does manage power draw down to 42uA in standby though. Espruino doesn't hit that quite yet (I have to figure out what needs turning off first!) but over time it'll get there.

1 Attachment

What about repurposing the X-via and X-Y route for A4 to bring it to the castellations (disconnect X-via from GND), add a new Z-though connected to GND and rout it to new GND which was VCC (X and Z vias could not work...). Or is there a no-no in regard of VCC/GND/3.3 sequence? I was anyway wondering why for the 3.3 0.05" not a more direct route has been taken (still can by flipping new GND with 3.3 and and create a fork North-East of Z-via.

Power-wise, everything is available for a 0.05" pins only shield and A4 not taken away from castellations... (because for using castellations, the 0.10" castellations provide VCC, GND, and 3.3 - correct?). And for a 0.05" and 0.10" mixed pins shield, VCC, GND, and 3.3 are available from 0.10" pins and no need to use the power and GND 0.05"" pins.

2 Attachments

I don't really get what you're suggesting...

That big blue rectangle is the ground pad under the STM32 - you can't put a gap in it so you can put A4 through it like you've drawn it.

So you are saying that from an electrical (shielding), thermal (runtime and soldering),... point of view - the ground plate has to extend all the way to the corner. Without the full extension, there will be an issue? Is the die at the bottom exposed? What about moving the X-via even closer to the corner to take away just the edge / less ? Looks to me there is some space left to the pads, is there?

1 Attachment

The bottom of the chip is bare metal, so if I put a via on the inside of those pads I'm basically relying on the solder resist to stop a short - not a good idea at all.

Also (at least when I'm hand soldering) that pad is absolutely vital for the correct soldering of the IC. The solder on it melts, and 'sucks' the IC into the correct position so that everything lines up. If I changed its shape it might alter the way the chip sits.

Anyone else? Do you think the new pin configuration is better that the old one, that would have required trimming down one of the 0.05" pin strips?

Thanks for letting me know. Creating a production issue is the worst to pick.

It's unfortunate that we had to shove A4 all the way over there, but I think it's okay - considering the constraints we're working within, that's definitely acceptable, especially considering that it's A4.

This will still require trimming the edge of the 0.1" header if they're on the same side of the board (to get it right next to the 0.1"), but that's a very easy trim. If they're not on same side, it should be fine - but Gordon, can you check that one one of your protos? Put 0.1" pin header facing down, and see if you can fit the 0.05" header in facing the other direction without the soldered ends of the 0.1" pins from getting in the way.

It is for sure better because any trimming is a challenge. Trimming on 0.10" pin strips is already a challenge (especially the machined ones I use on my current board). Some strips are symmetrical and exactly 0.10" wide, and some they are a bit wider on one side. To arrange them in a right angle in 0.10" space, I had to remove some of the strip material.

Would it not be better to stick with the kickstarter layout, or at least listen to all other from kickstarter also?
It is maybe only a few, there wishes this change.

@Gordon added the 3 extra 0.05" pin options in good faith. Because it created mechanically some challenges, looking out for a resolution is worth to try.

U and V vias are new. U gives the opportunity to get A4 still routed to the castellations. The spaces between existing T via and new U and the exiting M and G may be a bit tight. About T and U not much can be done, but I hope that M can be moved by about .7 trace grid (1/sqrt(2)) to the North-West. This provides a bit more room for the extra SW to NW trace, and for the existing SW to NW traces to be move a bit to West.

1 Attachment

Would it not be better to stick with the kickstarter layout, or at least listen to all other from kickstarter also? It is maybe only a few, there wishes this change.

If you mean the original version, with the rectangular pads*, see Kickstarter update 11 where this layout was introduced, and favored by backers in vote (as you can see there and in update 5, there was some debate as to how to maximize the number of available io pins, while minimizing the size of the board).
Adding the three pins for vin/3.3/gnd is an obvious enhancement, because it allows something that connects to the 0.05" headers to get power, without having to reach over to one of the 0.1" headers to grab power and ground.

If you mean the exact position of those pins that we're haggling over now, we're trying to solve an unforseen issue with the width of the header blocking installation of the 0.05" pins without shaving down the header, which nobody likes doing.

*which I think were my bad idea

I'll look at @allObjects idea next week, although I'll need to be careful. There is a ground plane right under the high speed oscillator to cut down on interference, so I don't want to move that too much.

However as @Frida suggests we're really close to the point where the boards are ready to be made. The old L arrangement is really not a huge problem. It's extremely unlikely that anyone will use it, especially as there are now castellations so most people will just use them.

On top of that I have prototypes of the old design that are tested and that work, and there's no way I have time to prototype the new one, meaning I'll have to make 4000 UNTESTED boards in order to save 2 people from filling down a connector a little bit. If it delays everyone else getting their board, I doubt they'll appreciate the extra 0.05" gap.

Honestly the more I think about it I'm not convinced it's a good idea at all. In the interests of getting everyone their boards on time I think we should probably just drop this and go back to the original L design.

@Gordon
Will you be releasing the finalized eagle cad foot print files for the pico before the Pico is shipped?

I need to get a PCB designed and was hoping to get one designed and receive my PCB right about the same time I receive my kickstarter pledge reward.

Yes, I will be. I'll do it after the PCB has been okayed by the manufacturer (in case they need any changes made so they can tile it properly) - but hopefully that'll happen in the next week or so.

Great! Thanks.

Dumb question alert!
I've been re-considering the IO boards (digital/analog etc) I use for projects.
And particular in terms of using USB-PICO with Raspberry PI (RPI).
Have got a number of PICOs on order.

How does the PICO present it's self to a RPI?
As a serial USB?
if so, could I write my own serial to IO control protocol?
Or would I have to utilise one of the other PICO's UARTS?

Thanks
Lawrence

Hi Lawrence,

Yes, The Pico appears as a USB Serial port - usually /dev/ttyACM0. If you want to control Espruino's IO from the Pi it's actually really easy. As it runs JavaScript, that's the protocol you use.

For example, to turn the LED on from the shell, just write:

echo -e "digitalWrite(LED1,1);\n" > /dev/ttyACM0

But you can actually program in more advanced behaviour. If you want to 'shift' data out in some format, just write a JavaScript function to do it and send it over the same way. You can then just call that function when you want to do things:

echo -e "function a(arr) { arr.forEach(function(d) {for (var i=0;i<32;i++) { A0.write(d&1); d=d>>1; }});}\n" > /dev/ttyACM0
echo -e "a([1,2,3,4,5,6,7])\n" > /dev/ttyACM0
echo -e "a([8,9,10])\n" > /dev/ttyACM0

There's some more info on sending commands from another computer here: http://www.espruino.com/Interfacing

You could write your own protocol too - by moving the console away from USB (using LoopbackA.setConsole()) you can then use USB.on('data', ...) to make your own handler for data that's been sent over.

But personally I'd just use JS as it's actually pretty efficient, and easy to understand/debug.

Gordon, that's great news thanks.
I use nodered.org on RPI so I'll write a node to do just that.
I hadn't properly engaged with the fact that JS on espruino is interpreted, obvious and very neat.
I've got one of the current espruino will try on that.

A lot folk use an arduino for IO handling with RPI.
Any others out there using espruino in the same way?

Ahh, great - I've had a play at using node red to control an Espruino, and it works really nicely with the serial module. The new versions (in GitHub, not sure if they're released yet) allow submodules, so you can do everything you need in node red.

Having said that, if you wanted to actually make a module it'd be amazing. Getting data back from Espruino via Node Red nodes is a bit of a faff at the moment (if you send data down the serial port then it's hard to make sure that the value that's returned goes to the right input node).

I think there are one or two people using Espruino that way - especially because you get Analog IO, but not that many. I think a lot of people haven't realised that it really is that easy.

It's mostly my mistake for not saying much about it, but I'm hoping that the Pico (that's more plug-sized) will get people's attention a bit more as an IO board.