Search results for:

That looks great! So the keyboard itself has a digital interface rather than needing scanning?

Yes, it comes with its own 2040 that does does the USB HID and a I2C node that provides config, keystroke (down/held/up), touchpad delta-since-last-poll, backlight control and several raw access registers, including managing an interupt pin (which I'm not using right now).

Pretty neat for using with a mini-Linux machine or in a embedded setup.

The i2C interface can provide ascii with direct modification (shift/alt) or provide just the keycodes. Might also be a good candidate for an espruino module.

I also implemented a nice dimming effect, which unfortunately makes the little power bank shut down due to low power consumption :) Mapped the dim-down onto a key combo now and use it as an off switch until I might replace the battery with something simpler.

Works great for now with that singe-file Espruino solution.

The vertical opportunity would have been doing everthing with just the keyboard module and a 1.8V nRF. But that would have meant a new board, casing, flow soldering instead of just soldering four cables. But it might run well on a 3V coin cell instead of the "bone".

and is that one of those special buttons at the top where you can rub your thumb over it and scroll around?

Yes. Great addition to the keyboard.

The closure minifier was inlining a function and had added a label/break-to-label

Cool. That explains the "jump" I spotted in the minification. Didn't think of a label in js.

Best bet is https://www.espruino.com/BLE+Security#di­sable-the-ble-uart

Ah. nice. The perfect page for my all questions above (that I could have found myself :)) Thanks.

BTW, interest in this port is not really overwhelming ;-)

Just got a few Pico Ws and got burned by MicroPython right away. So... very interested in a port. Given the wireless support of the new chip, there might be quite some potential.

Everything without an event model/loop will have to rely on archaic multi/dual core distribution approach and the RasPico's GPIO features. Not really a replacement for a neatly generalized run loop.

Hey Gordon,

Thanks. I'll try these settings and will report (I guess I should drill a hole for the (reset)button as the first measure).

For the combo.js (yes, the one you linked) I got errors with a simple require (that the IDE would fetch) but things would work fine if I used the full URL to the unminified version and let the IDE do the minification. Great that this works that easy.
So I suspected the minified version to have a problem, and looking at a few points inside the minified code it looks like there were some jumps or repetitions that make the code invalid. Though you never know what magical obfuscation might be at work.

What's the current recommended way to disable the UART? Since I still need to update the code now and then: To get it back I would have to implement my own switch, or would flashing new code still work and just the interactive console would be disabled? If so, can I disable reflashing-without-DFU in the end?

Nice to just pick up Espruino after a few years and it just works. An important point for the whole concept of Espruino. I know other frameworks that would need you to either keep up with their development the whole time (which is the opposite of tinkering) or relive the whole toolchain learning curve every time.

-Stev

Hey,

I recently bought a few of these

https://www.tindie.com/products/arturo182/bb-q20-keyboard-with-trackpad-usbi2cpmod/

which is a light blackberry keyboard with touchpad, that connects via usb c to a host or can be used as a i2c device via multiple connectors.

I added a MDBT breakout module that fits pretty neatly into the free space inside the enclosure.

Used the Web IDE to connect wirelessly to the breakout board, which works seamlessly, if you remember or implement a few tricks to switch pairing once you start the BLE HID mode. The Espruino module connects to the great I2C interface of the original keyboard and does its own keyboard mapping etc.

There is enough IO left to actually connect the keyboard matrix directly to the MDBT breakout, but you would need to provide your own level converters etc., so this is a neat compromise for now.

I'll try to polish the pairing and security functions, but for general use, it's working quite well already.

Pretty happy with Espruino's incremental tinkering experience that lead to a viable solution for the problem.

I'll promise to re-do the ugly soldering next time I need to open the case...

Hi,

I'm working on making an existing keyboard mouse combo (https://www.tindie.com/products/arturo182/bb-q20-keyboard-with-trackpad-usbi2cpmod/) available via bluetooth using the MDBT breakout board. It's working quite well so far, and it was easy and fun to implement right inside the IDE, which always keeps me coming back to Espruino. It's the original promise well served.

(the combo minified module might be broken, not sure though, I now use the non-minified one)

Now, I wonder though, what security setting I should use to have a professional and secure solution.
I saw the encryption settings, mitm etc, but the default seems to be "off" and I wonder why that is and what I should use. Bit lost here.

Also I found that the device is not recognised as a potential keyboard when it comes to the icon displayed by the host (generic BT icon instead of a keyboard). Anything I can do about that?

Thanks in advance
Stev

Long way well travelled. Congrats.

Hooray, indeed, @Gordon

Though we got a new dog and I will never have time for anything again, I‘m afraid...

Had a look at the sources, though, last week after not having looked at it for a few years now, and am pretty happy with what Espruino has become and that it‘s well and alive. Great work.

Better not count on an early. Got the native blinky example running..
Not sure, how much time I'll have on my hands in August. Intensely waiting for a rainy day for looking at the Espruino code :)

15’s release notes say something about production quality, also for USB, so lets hope they mean it.

For the HID part, I totally forgot about the STM specific implementation. Still, the 52840’s integrated USB is a pretty cool thing and makes that dongle so interesting.

I had a look at the HID examples yesterday but had troubles with flashing existing example hex’ and getting some if the tools to work. Seems I have to recompile using the full tool chain.

The dongle is brand new and the desktop integration might still need minor work/updating.

I‘ll post an update if I got something going Espruino-wise.

but realistically to work properly it needs to be running with SDK15

From the SDK downloads page it seems that the SDK from 12.2.0 up support the nRF52840.

So the keyword were "realistically" and "properly"?

They look like great little devices though, and extremely cheap too.

Well, I guess all the Nordic chips ask for this kind of cheap generic board designs, this one from Nordic themselves, so that will not go away. Still enough market for specific power/battery designs and special form factors as well as sensor/display combos.

Now that the 52s with this chip got USB support, too, I hoped to get Espruino's USB HID support running, though I haven't verified that they will support that via the dongle's USB contact pads...

Hey,

just received a few of those "original" nRF Dongles today. Is there already support for those?

-Stev

Will have a look at the current src/build set and see how it looks today (I guess i did this a few years ago, last time).

There's that Rebble site's projects page that also mentions an initial FreeRTOS implementation for Pebble, don't know if one could combine some of the ESP parts with that.

According to iFixit's teardown there's an STM32F439ZG inside the Pebble Time (the "current" Model).

Plus Texas Instruments CC2564B Bluetooth, Lattice LP1K FPGA, Bosch Sensortec BMI160 accelerometer, as well as a Freescale Xtrinsic MAG3110 magnetometer. More on the bottom of said page...

Actually a device I'd love to see Espruino run on. Well-built, used and loved by quite a community, abandoned by their original creators, and/but with a few more discrete parts in contrast to the nRF51-based devices.

Hey Gordon,

Take your time. I'll collect some more meanwhile:

While the compass() function now returns sensible values, it happens to fail with a i2c write error after a while (though no clear criteria on when/why).

Also, when I use a non-rounded int resulting from Math.pow as a parameter for show(), I sometimes end up with the result for one less (that "one less" thing. again.):

show(Math.pow(2,15))

should only light up a single LED,

show(Math.round(Math.pow(2,15)))

does.

-Stev

save() is broken for the micro:bit in the 1.86.xx travis builds...

(and I get a debounce value stored for setWatch that is one less then entered...)

No micro:bit build for 1.86 in the release Downloads folder...
Compass works steadily, though :)

-Stev

Cool.
Nice little BLE toy/tool.

Hey,

@luwar
good hint. I'll try that.

@Gordon
Just unpacked the thing and tested the few functions. And saw the compass call converging towards 0,0,2. Doesn't crash or block, just ends up there after a few calls. Just wanted to check whether a broken device or the code was the culprit.

@DrAzzy: Nice tinkering board. I'll have a closer look at the possible components. Though I somehow want everything "smaller!" these days. Not sure how to get there though without doing a new board every time...

I thought there might not be support for all IO pins or the 8266ex' serial memory. If that's the case though, I'll happily go and buy some (tiny ;) board.

Thanks
Stev

Hey,

just received my microbit and while typing along (really easy espruino install, btw) I found that repetitively calling compass() creates nonsense result and soon gets stuck at

{ "x": 0, "y": 0, "z": 2 }

like so:

>compass()
={ "x": 29688, "y": -1537, "z": 32514 }
>compass()
={ "x": -4214, "y": 24832, "z": 24834 }
>compass()
={ "x": 24878, "y": -253, "z": 2 }

Saw that too? Not sure if its some device data underflow or a missing reset, as I haven't looked at any internals so far.

Cheers
Stev

While I was away a bit and you're luckily still at it, will there be some support for any 8266ex board like Olimex' MOD-WIFI-ESP8266-DEV or anything cheap with more GPIO than the 2 of set standard -01 boards? Not sure if these questions help, though :)

Edit: If the 32 should really be available that soon, the question might be useless. If not, and a usable board is six months away, I would still pose it that way.

Hey, great news. I killed a few Esp with an overly compact shim already...

Will this Espruino have some kind of certification? FCC/IC/CE?

Not sure what's necessary in what country to resell a solution by just adding the software, or if that's possible at all in this setup.

Nice start into the year
Stev

@Kolban
I am not sure if I understand your "knowledge and skills" comment. It's probably true that there are an increasing amount of people knowing the ESP8266, as it's even got support by the Arduino IDE and more IO-oriented boards with it coming out every day (with relays or other components already onboard). Still, having Espruino running on it is a totally different quality.

I just saw Olimex' new board with SPI flash added and wondered, especially after a comment you made about the memory partitioning of the board, if more flash might be helpful or not. After all it does not seem to make that much of a difference in price.