Smaller Espruino board?

@Gordon, I really like the new design. If the new design is cheap enough I can permintly leave the board in a project :)

@Gordon no, if you solder crystal is need use metalic usb A, then you blend wings on connector and solder to bottom pads. It is wery slim and compact. Do you thing that is possible create espruino for 072 chips? I can send you assembled board.

Cool cool.

I mean - I think the power connections that people will use are the current "VBat" and the 3.3 out - so that's really what matters for the small one, i'd say.

@bobricius I'm afraid I just don't have time to port Espruino for you - I've got to focus on things that are going to help bring in money I'm afraid :( It shouldn't be very difficult though as Espruino uses ST's API and most of jshardware.c should compile as-is. The most difficult part would be getting USB working, but you may be able to copy the code that already exists for the F1 or F4.

@Gordon you have true this is no way. But I'm still have obsession by small PCB. My second attempt.
https://oshpark.com/shared_projects/S6as­tjvz
Edge header: i2c/uart (optional pull up), 2xDac,SD card, UART1 for bluetooth
Left edge only on tespoints signals for cc3000
Right wing nrf24l01
Battery, SWD,SCK, Reset on testpoins
Led on A0 PWM,
I think it should be compatible of espruino without changes.
I need now check for before ordering :)

• adapter board with sdcard, bluetooth and maybe eeprom
  

and I have released this micro board compatible with maple mini https://oshpark.com/shared_projects/J2aO­vbKF
with stm32f103cbt6 this board maybe can run limited version of espruino

Whoa. Just saw this thread. Please take my money as soon as humanly possible.

With regards to the dilemma of extra pins, could a possible compromise be to have them on some sort of breakaway section? I'm not a hardware guy, but could the board be perforated or at least have some sort of safe cutting line over which the traces are just straight lines? I was wondering about doing the same for the USB connector. That way, the board could be programmed and developed full size and then snapped down to minimal size for use in production.

This brings up another related thought... what about constructing a "micro"-Espruino module with no buttons, connectors, etc. and 0.05" pads, of similar size and form to the HC-05.
It would be mounted on a breakout board with all the pins and connectors for development (and for hobbyist use), but could be used on its own in production. I could imagine that would improve the practicality of Espruino hardware beyond simple one-off use. I could also see both the mini- and normal boards being refactored as simple breakout boards for the micro-.

I know it's not what you're planning with this new release, but I for one would be very interested in, say, four micro-Espruino modules and a single Development Kit (ie. the breakout board).

(It goes without saying that I'll also pledge for the mini- on Kickstarter as planned ;) )

Thanks!

could the board be perforated?

I was wondering about that... There's no reason why it couldn't be, but I'm a bit scared of either:

• It snapping off when it's not meant to
  
• The board being damaged when the end is snapped off... it'll be 2mm thick, so the board itself will be harder to snap than a 'normal' 1.6mm PCB - and on top of that the non-leaded chip is more likely to come disconnected if the board is twisted.
  
  

I could very easily re-arrange the wiring such that you could cut the end off if you wanted though. I'd imagine attacking it with a dremel would be far less likely to damage it than snapping the end off.

"micro"-Espruino module

That's a really nice idea. Someone on here was planning a wearables platform that looked a bit like that, but actually having solder-on boards for Espruino/protoboard/etc would be great - especially as I could do a whole series of small specific purpose boards (for example for connecting to a WiFi module). If I ditched the voltage regulator (the chip can run off 2-4v) then the actual module could be tiny.

I think given how far I'm along with this one it's maybe a job for an Espruino v3.0 though ;)

I guess it could come down to what the extra cost of producing two separate boards was, but I guess as one would be almost through-hole I could supply a more expensive assembled board, as well as a kit.

Yeah, I thought perforation might be a step too far. However, if there was a clear line then the instruction could be to cut the tracks with a scalpel first (probably slightly back from the line) and then use whatever means necessary (Dremel; Hacksaw; persevering with a Stanley knife) to separate the board itself.

As far as the micro- is concerned, if refactored as though-hole (or easily surface-mountable) the carrier board could be in kit form, as you say, or a hand-assembled board offered at a higher tier pledge. Other boards could be offered as downloadable designs, one-off orders, or small runs based purely on demand and cost... perhaps even as separate mini-Kickstarters themselves.

If you could get the business aspect just right and find a few good customers, bulk sales of the core module for integration might subsidise the hobbyist and developer boards. I've seen a few successful Kickstarters for IoT modules designed for production use (eg. RFduino, MetaWear... admittedly both BLE + ARM), and none of them are anywhere close to being as easy to develop as Espruino.

For that matter, if anyone produces an ARM package specced to run Espruino well enough and integrate BLE into the package itself, I reckon it'd be worth dropping everything and getting a Kickstarter out there ASAP. The barrier to entry for BLE for unfunded startups (eg. wearables) is too high at the moment: complicated dev tools and environment, bad example code and documentation, and so forth. Javascript would be a perfect host for an integrated (ie. not serial-driven) BLE component.

Anyway, I digress. :)

Yes - providing something more business-friendly would be great. I hope this new board will go some way towards that though - it should be something you can prototype with, and that is easy enough to put in small volume products.

I'd love to do some BLE stuff - the problem for me is really on the PC/Mac/Linux/Android/iOS side. Even if BLE on Espruino is really easy, it seems like you've still got to do app development to use it properly, and with every platform being different that's going to be a nightmare.

Now if there was a standard for BLE->Internet bridges and you could just go out and buy one, I'd suddenly be way more interested :)

Now if there was a standard for BLE->Internet bridges and you could just go out and buy one, I'd suddenly be way more interested :)

I think that's been sidestepped - the ESP8266 is cheaper than the HM-10 and goes direct

True... Power usage isn't great though :(

Different thing altogether... for the kind of thing I'd be using BLE on Espruino for, I wouldn't want "proper" Wifi anyway. The desire for BLE is about having a lightweight connection from a smartphone or tablet to control and query one or more Espruinos. Classic Bluetooth would do the trick, but would drink far too much. The ultra-low-power nature of BLE coupled with Espruino's economical usage through an event-driven model would be a perfect match.

It's a pity BLE included the word "Bluetooth", as it's just not the same thing at all. Rather than internet, serial and all the other things, BLE is mainly used (and apparently intended) for the typical sensor and accessory role, such as heart rate monitors and so forth. Trying to get it to establish a serial connection or any kind of constant stream (eg. audio) is just counter to the design. Additionally, controlling something like an HM-10 via serial and AT commands is a bit nutty, IMHO... it'd almost be more suitable to do it over I2C than serial.

Gordon's right that the app development side is required to use it properly, though: most projects seem to offer this with a fairly weak sample app for iOS and Android. It's a shame because BLE has all the elements to be really great, but the sample code and tools on both sides of the connection are just a bit lame. It'd be very interesting to see a Javascript remote procedure call mechanism from smartphone to Espruino across BLE like the NRF24 implementation.

It always annoys me when I see KickStarters that advertise how easy it'll be to make a smart device with their BLE board and then totally don't mention the app part - especially the bit where you need a pretty modern Mac, $500 iPhone and a $99/year developer subscription if you want to do anything iOS :( You have to wonder how many of their boards actually get used for anything serious.

Executing random JavaScript over BLE (while presumably a massive security issue) would be very cool though, especially with something like PhoneGap (where you program in JavaScript). At least you can say 'hey, if you can develop an app then that's all you need'.

Agreed, but I'd still prefer having to get a modern Mac, iPhone, developer subscription and programming a little Javascript than having to get a modern Mac, iPhone, developer subscription, Nordic Eval Kit, a copy of Windows to be able to run Keil OR lose a good deal of hair trying to get GCC configured, and then have to spend tonnes of time trying to decipher the nrf51 SDK.

Unusually in this case, writing the phone app is probably one of the easier and better-documented parts of the process!

@Gordon You mentioned something about BLE? How secure is BLE? I'm afraid to use BLE because, I have been reading and watching youtube videos about how to crack/hack BLE; surprisingly its rather simple to do.

I don't know anything about BLE security, but I always assumed that like most things now there would be some exploitable holes in it.

I wouldn't be afraid to use it, but just be aware that it isn't secure. If the worst case is someone with specialist hardware sitting 10m away can over-water your plants then it's probably a risk with taking, but I wouldn't put it in your pacemaker or insulin pump unless it was purely for sending status information :)

IMO actually engineering a device to run code transmitted over a wireless link is always going to be a bit iffy. It's cool to do for prototypes with the NRF24 and Bluetooth modules but I wouldn't pretend it's secure.

IIRC, the BLE exploit is to do with a particularly weak pairing procedure: if paired in a secure environment -- you do all have a Faraday cage at home, right? -- I assume it's moderately secure... 128-bit AES, I think.

Security on BLE is designed so the host (a.k.a. client, ie. the smartphone) does the vast majority of the work, and the peripheral (a.k.a. server, ie. the widget) just has to do very basic symmetric ciphering. This is to reduce power consumption, offloading all CPU work to the (presumably) more powerful host.

Saying that, I would agree with Gordon's assessment in terms of risk. Most BLE usage seems to be predominantly read-only with most of the security features ignored. Saying that, many do have a DFU mode for OTA updates, and there's little to stop NSA/GCHQ/[A-Z56]{3,} using that to surreptitiously turn your fitness band into a rudimentary espionage device.

Anyway, I apologise for taking this thread so far off-topic!

NSA/GCHQ/[A-Z56]{3,} ... great!

just read this: No built-in Micro SD I'm afraid - you'd have to solder something on for that.
Will there be any kind of support in Espruino, or need this to be done in a module ?

I'll be modifying the filesystem library so that you can connect it to whatever pins you want. Adaptors are readily available, are a few pounds on eBay, and only need 5 pins to wire up.

It'll also mean you could do some pretty cool stuff like have two SD cards and swap between them with a button-press, so you could keep logging data without losing any.

@Gordon, I'm anxiously awaiting for the "new" designed Espruino to be released on kick starter ;-)

:) Thanks - I am working on it - I've been trying to sort the video out for the last week or two...

No built-in Micro SD I'm afraid - you'd have to solder something on for that.

I'm a little bit excited for the Espruini.

(note - if you do rtclick -> view image, you'll get higher res version which you can zoom)

Just a bit. (keep in mind that I can't test it, since the change to move around pins for FS isn't in)...

(the SOIC8 pads are for an AT25 SPI EEPROM. Will be getting one and adapting the AT24 module to do AT25. Usually less useful than AT24, since it needs 4 pins vs at24's 2, unless you've already got stuff on SPI hanging around the same area - in which case you need only run a CS line to it and connect it to the bus)

...looks just marvelous!