Yes, it's all quite separate too. If you're doing work on SPI you tend to test that work before a commit - so the only stuff that gets broken accidentally is really when there are complex interactions between bits of hardware (timers/etc).
... of course for STM32 it's trying to support F1, F3 and F4 with the same source, so you could conceivably alter it for one processor and break another - although not many people tend to fiddle with jshardware.c so it's not such an issue :)
It'd be great if you could get it running as a Travis build - and then you could just upload the result of the build. It's scary how much processing power gets wasted doing the setup for a Travis build as-is, but it seems to be ok :)
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.
Yes, it's all quite separate too. If you're doing work on SPI you tend to test that work before a commit - so the only stuff that gets broken accidentally is really when there are complex interactions between bits of hardware (timers/etc).
... of course for STM32 it's trying to support F1, F3 and F4 with the same source, so you could conceivably alter it for one processor and break another - although not many people tend to fiddle with jshardware.c so it's not such an issue :)
It'd be great if you could get it running as a Travis build - and then you could just upload the result of the build. It's scary how much processing power gets wasted doing the setup for a Travis build as-is, but it seems to be ok :)