-
• #2
Ahh, those instructions are old. There are some at https://github.com/espruino/Espruino/blob/master/README_Building.md
Basically you need
BOARD=NRF51822DK RELEASE=1 make
(notNRF51822DK=1
), then you should be ok.and:
- It's hex
- You can't flash wirelessly if that's what you were asking... There's not space on the NRF51822 for a bootloader and Espruino, and even if there was the bootloaders are usually locked on the devcies. You need an nRF52832DK or NRF51822DK board, but then it's as easy as just copying the hex file to the new drive that appears when you plug the DK in
- It's hex
-
• #3
Basically you need BOARD=NRF51822DK RELEASE=1 make (not NRF51822DK=1), then you should be ok.
That worked! Thanks. This evening I'll try to drive the OLED display thanks to the documentation provided by [rbaron] : https://rbaron.net/blog/2018/05/27/Hacking-a-cheap-fitness-tracker-bracelet.html
-
• #4
Have you seen this? http://forum.espruino.com/conversations/280747/ I thought that's what you linked originally but it seems not.
I hacked an nRF51 watch that appears to be from the same manufacturer (it's just an older version), so chances are the code I used will work if you change the pin names.
There's even a branch where I added a compiled OLED driver (I'm not 100% sure if that ever worked): https://github.com/espruino/Espruino/compare/DO003-oled
You'll find that the chip in there is the AA variant (so only 16k of RAM). With Bluetooth that leaves 6k for all your program code, so things are getting a bit tight. With recent changes and the ability to execute out of flash (save on send) life will be better, but it's still not much.
It'll be fun, but if you wanted something really usable I'd maybe try one of the manufacturer's later NRF52-based watches as they've got bags of memory :) It's been on my to-do list if I ever get any free time.
-
• #5
I will have a look at the code you wrote on the DO003.
I have desoldered the nrf51 (it was a OTP version) and soldered the nRF51822-QFAC which has got 32k of RAM. -
• #6
I have desoldered the nrf51 (it was a OTP version) and soldered the nRF51822-QFAC which has got 32k of RAM.
Wow, nice. I didn't think of that - that should give you a lot more to work with!
-
• #7
I managed to build Espruino for the ID115, flash the nrf51822 and drive the LCD, that's super awesome :-)
I first thought that my OLED display was broken , but I figured out that I did not adjust the SSD1306 configuration, and the matrix dimensions were such that, well, I printed "hello world" outside of the visible matrix. The display is 32 x 128 pixels. Just changed the config and the graphic handling was done.Now I would like to add the
setFontVector
to the binary, even if it is restricted because of low flash memory. How could I achieve that? It seems that it is not just a matter of removing the line"ifndef" : "SAVE_ON_FLASH"
in/libs/graphics/jswrap_graphics.c
. . . -
• #8
Now I would like to add the setFontVector to the binary, even if it is restricted because of low flash memory. How could I achieve that? It seems that it is not just a matter of removing the line "ifndef" : "SAVE_ON_FLASH" in /libs/graphics/jswrap_graphics.c. . .
OK actually this seems to be the way to go.... By removing this instruction, I had to remove here and there some
#ifdef SAVE_ON_FLASH
in order to compile without errors. But now the linker tells that the linked binary is too big to fit in flash... Hmm, that's whySAVE_ON_FLASH
makes sense ^^. Anyway, with or withoutsetFontVector
, having Espruino on the wrist is very cool! Even if I have still no idea what to build with that... hum.... -
• #9
I managed to build Espruino for the ID115, flash the nrf51822 and drive the LCD, that's super awesome :-)
Just discovered that when doing a
save()
with a very short script, everything is fine, but with a longer script the same instructionsave()
fails. Espruino seems to freeze, and the console does not respond anymore. Do you think this issue is related to a misalignment between the linker script and the flash memory map? However my board.py file (/Espruino/boards) is inherited from the NRF51822DK.py configuration, which is for a nrf51422, having the same memory map as the nrf51822.
Does anyone encountered problems saving the script to flash on NRF51 devices? -
• #10
Honestly, I'm not sure. It could be misalignment...Perhaps try 'save on send' in the IDE and see if that is any different?
Hi there,
Yesterday I was trying to compile Espruino for a low-cost wristband (ID115) based on the NRF51822. I read the topic http://forum.espruino.com/conversations/280007/ and I tried to run
NRF51822DK=1 RELEASE=1 make
. The CC and LD processes did their job, apart from generating the output binary. I expected to see something like aespruino_1v99_nrf51822.bin
file in the root path. Instead, the binary is calledespruino
, with no extension.1) Is it normal?
2) If so, what is the binary format? .bin, .hex, other?
3) Can I use the nRFgo Studio tool to flash the NRF51822?