Minimal design thoughts

[korttoma]

@Anticimex said:

Just put the pin header in and press it against the side when programming

This is what I do with the Pro Mini, have not had any problems yet.

[sharath krishna]

@tbowmo what might be the cost we are talking of here for the complete assembled board ?

[hek]

@sharath-krishna

http://forum.mysensors.org/topic/510/minimal-design-thoughts/140

[tbowmo]

@Anticimex

I don't solder any pinheaders for the serial port, just putting the pins from the ftdi module in the holes on the micro board, and then holding it in place. Done the same thing for the ISP port, but it's a bit more problematic. The last two boards that I have assembled, is with pins in the ISP port.

I expect to have a "standard" bootloader in the boards (Together with a standard sketch for reading / reporting sensor values), when we receive them from China, so the ISP port is not necessary for the average user. only serial port for reprogramming (if not going for OTA).

But it might be an option for a future module, to have better access to the headers. Also might go with the nrf24 smd modules. But that's another project at the moment :)

[tbowmo]

@Anticimex

btw. the only painfull thing about the current layout, is handsoldering it :) it's a nightmare.. Almost regret that I used the new footprints for resistors / capacitors, as it makes things a lot more difficult.

[Anticimex]

@tbowmo Sure. But after a chat with @hek I believe you have dabbled with a bootloader that can flash in new FW from the external SPI flash. This is to me very interesting because that means we can deploy FW updates OTA using the MySensor library to flash the external flash, write some EEPROM byte to inform bootloader that new firmware is available, reboot to have the FW transferred by the bootloader and then boot the new FW. And this in turn means that we can transfer the new firmware signed, therefore support signed FOTA and THAT is very much interesting to me :)
So for me, the ideal would be that the board was preflashed with that bootloader (patched to be triggered by MySensors logic if necessary). Then there would be no requirement to have any extra headers, as you can push whatever you want, and signing can be implemented without actually changing the bootloader (headers will probably be needed during development, but that could just as well be done on breadboard).

[hek]

@Anticimex

But you would still need to set the keys...

[Anticimex]

@hek Well, not really. If you like, you can FOTA down the personalizer with your PSK and execute it by remote on a "virgin" unit Then FOTA down your application FW. It is only when your application tells the GW that it require signing, signing actually kicks in.

[tbowmo]

@Anticimex

Yes, I have a bootloader, that copies external flash, to internal. It's also verified as working, with a local firmware update where I downloaded a sketch to the micro, which put another sketch into the external flash, so no OTA in the verification phase. I used DualOptiboot from lowpowerlabs (There is a copy on my github account.)

The bootloader looks for a signature in the first couple of bytes of the external flash, if present it copies data and erases the external flash.

I just don't know what direction things are going at the moment, as there also exists the standard MySensors bootloader. If we use dualoptiboot, we need to have FOTA code in the default application that is loaded into the device, before shipment from china.

[tbowmo]

@hek, @Anticimex

if we are going to use the external flash for OTA, then it should be included in the library? So the libraray handles the OTA packets, putting data into the external flash etc.

[hek]

@tbowmo
Yes, that would be the most reliable option to allow updates un normal running mode.

I discussed this with @Anticimex earlier today and how to combine it with signing without totally flood the network with nonce requests etc.

Neither of us have the flash memory though ;)

[Anticimex]

@tbowmo Yep. The way I understand how things work, I suggest the following:
Library initiates OTA transfer stream and transmit all FW for storage in external flash. Both sender and transmitter calculates some checksum of the FW and the checksum is sent finally, as a separate command.
The stream data is sent with a special command that bypasses signature. The checksum is sent with a type that is included with other signed types (currently only the singing handshake commands are excluded from signing).
That way, if receiver require it, FOTA will also be signed since the checksum packet is signed.
If the receiver accepts the signature (and the checksum is valid) receiver writes the bootloader specific indicators and restarts, so bootloader can transfer the received firmware to PROGMEM, and "Bob's your uncle". Secure FOTA to your difficult-to-reach node somewhere in the house :)

[tbowmo]

@hek said:

Neither of us have the flash memory though ;)

Hmm we should do something about that at som point in time ;)

I could send you a couple of bare boards, you could practice your soldering skils on ? ;)

[tbowmo]

@hek said:

Neither of us have the flash memory though ;)

Maybe we could figure something out.. I could send a couple of empty rev. 2 boards, and you could practice your soldering skills and assemble one yourself ;)

[hek]

That might be a good idea. Just hope I won't mess it up too much. Which components do I have to order in the meantime.

[tbowmo]

@hek

I have a BOM at mouser, but need to double check it.. (Also, might have some of the capacitors/resistors in my "private" stock, so you don't need to order them)

[blacey]

@tbowmo you can sign me up too however I can handle the component side of it if you share the mouser BOM.

[tbowmo]

@blacey said:

@tbowmo you can sign me up too however I can handle the component side of it if you share the mouser BOM.

The BOM should be available at
http://www.mouser.com/ProjectManager/ProjectDetail.aspx?AccessID=a509f9ca59

It should match the current PCB layout for the major number of parts. I haven't looked at the crystal yet, to see if that fits, as I have changed the footprint to the one provided by the manufacturer in china when going with rev. 2.

At the moment I'm considering if the crystal should be dropped from the BOM, kind of missing a real purpose for it at the moment, as I don't think that "precise timing" is necessary for a node that repports in at a regular interval.. I (for one) don't care if it reports temperature / humidity "exactly" every 60 seconds, or if it's every 55 or 65 seconds.. But others might have another priority?

Schematics / PCB layout is available on github : https://github.com/tbowmo/MySensorMicro (please double check BOM from mouser, and the eagle files. I might have missed something :))

[blacey]

@tbowmo Awesome! I'm on it :+1:

[tbowmo]

So, a small update on the rev.2 board status.

I am verifying the rest of the board now, before we kick of an initial testrun of 5 boards at the manufacturer. Everything seems to be working, electrically..

Unfortunately something has happened in the SPI library in arduino, so the external flash, is now crashing the arduino sketch, while initializing. Someone else has already reported it to lowpowerlabs github repo https://github.com/LowPowerLab/SPIFlash/issues/8

Having had the above issues, I have already build, and disassembled two nodes, trying to debug things :s

Oh the fun of debugging embedded things...

update

I found a solution, someone else had made the necessary changes to lowpowerlabs spiflash library (check the issue comments in the link above)

I also read in the release notes for arduino 1.6.0, that they have changed the SPI library to support transactions. Will this have any effect on MySensors? (@hek, any comments?)