You are reading a single comment by @Gordon and its replies.
Click here to read the full conversation.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
@Gordon
Yes, all those tests are hardware independent I'm afraid. All the hardware stuff is hand-tested, which is less than ideal.
Travis builds are uploaded to http://www.espruino.com/binaries/travis/?C=M;O=D but as they're not padded for the bootloader the ones for the Original Espruino and Pico aren't that useful.
... but also, I have builds running here (which were set up before Travis), which run code on an Espruino board itself (I have one set up that puts it into bootloader mode, and then it's flashed with new firmware). Currently it's only a series of benchmarks, which actually aren't that reliable because the 32k crystal is way off when Espruino starts :) I need to fix it and measure timings using the second board.
Builds and stats: http://www.espruino.com/binaries/git/
But yeah, some actual hardware tests could be good - Maybe an I2C IO expander wired to an SPI IO expander? I'm not sure how much use they'd be though... The other option is to just wire one board straight to another, and to run things like SPI and I2C slow enough that 'setWatch' can be used for testing.
Problem is, the regressions I've hit have all been really odd things that the tests wouldn't have picked up - for instance SPI on strange pin combinations. Things like GPIO or SPI on basic pins have never broken as far as I'm aware.
Another thing - perhaps more likely to be scalable - is to have something set up whereby anyone can set up a test with a Pi + board, and can then contribute back the test results for each build? Then if someone makes a module to control some hardware, they can add a test specifically for that hardware.