Search results for:

Thoughts on just jswrap_bangle_hardware.c

So i think that would be a huge step forward. My biggest complaint was not knowing where to edit the code if i wanted to add something. So if you split out the each piece of hardware out then it make it easy to know where to go if you want to add a IMU or something. Which is huge!

So if you don't like the idea of WEAK functions, but do like the idea of splitting the files out. We could just have a bangle_HARDWARE_impl.h file and no *.c file. So then every HARDWARE_impl.c file has to include every function. That would accomplish the same thing. I think i remember us talking about something like this before.

So i personally like the idea of splitting out the drivers into there own files because then it's easy to find all the code thats specific to that given driver, but also because it hides some of the weird parts of other drivers. For me one of the weird things is seeing all the things special to just the BANGLE 1. From a hardware perspective it kind of just does things different then most of the other watches. So moving all there hardware specific stuff to a separate file makes the rest of the code easier to read.

Final thoughts
So i think moving all the code into specific JSwrap files is a great step forward. Its exactly what i did when making all my changes.

I2C calls
I2C array calls. I don't know how much flash it saves if any, but i do think it reads better.

Ex:

• Write(IMU, IntI2cCallsAccel); //pseudocode code example
  
  

It's kind of self documenting code.
@Gordon

Comment/Question

_impl stuff quite odd
so I don't get why there is _impl everywhere

I can see that. I don't think this is a standard way of doing things. This is kind of my hack to get the code moved out of the main bangle file without adding any runtime abstraction. Most abstractions like how linux kernel would add a lot of overhead but this should produce basically the same or close to the same binary.

How it works

So the impl name scheme is like this

• Bangle_hardware_impl.h/c - "Impl" short for implementation
  
  

So if you think of this as like OOP. This file is your base class. Then i label most of the functions weak to make them "virtual" functions.

• Bangle_ hardware_device_impl.c
  
  

Then you can make as many device files as you want. Any function in these files will override the functions in the base_impl.c file. In these files you can override all or just some of the functions. Many pieces of hardware don't need a completely setup. So when it builds what ever functions it doesn't override will you the base_impl.c implementation. Which in many cases is just nothing. Also these files are added at compile time and are chosen based on the hardware defines in your device.py file.

example

• bangle _accel_KX023.c
  
  

This is the file for the KX023 accelerometer driver.

answer

So basically there's a lot of .c files because i use a different c file for each configuration needed for each piece of hardware or feature.

@fanoush

So i did break out the barometer. I also broke out the accel,compass and touch. I did this fairly quick, so there might be parts that need to be moved over. I plan to do a second/third pass through it when moved the easy parts over. I put it on a new branch called quick_rewrite

So moving the barometer took me a little bit because i got confused on how the SPL0 worked across versions. So you can see the barometer code here

• barometer libs - supporting libs
  
• SPL0 driver
  
• barometer jswrap file
  
• barometer impl - Holds all the functions that can be overwritten and hold many of the states. So idle,init,on,off
  
• Bangle 2 device defines
  
  

Another consideration is it's not just Bangle.js that has sensors (Puck.js/Microbit/etc have them too) and in an ideal world we'd be able to reduce duplication there too - but I think possibly that one's just a step too far for the moment.

I think this would be awesome! I didn't dare go down that route because i know i would break something. Sounds like a fun thing to experiment with a new piece of hardware and then maybe back port some of the idea back to it.

There's probably a good middle ground between all-out abstraction and the current insanity that is jswrap_bangle.c though.

So i just found that there's all these "middle ground file" in the misc. For things like heartrate and gps. I just started to look at these things next. So they might be a middle ground somewhere there.

@Gordon

Personal Reason
So you asked this I don't really understand why we're doing this, we could support the P8 with just another few IFDEFs.
So this isn't really about the P8 watch per say. This is actually about a different project in mind.

Project idea
I'm one of those weird people who loved the pebble watch, but the device is just so old it's hard to use now. So what i started looking into was how to replace the motherboard and what software should it run. Out of all open source watch "operating system" i found that yours seemed to make the most sense. Mostly because it allowed apps to be loaded from a web browser, which no other watch OS can do.

The problem is I'm planning on using hardware that is very different then what most people are using. I'm using a Nrf52480 and the memory LCD, but everything else is fairly different. So here comes the problem, i didn't want to pollute the main project with a lot of #ifdefs that were specific to my small project. So i was hoping I could break the code into modules then i could easily have my own repo with my own drivers that i could easily update down the line.

So that's where the P8 comes in. I thought trying to add the P8 into the code base would be a good test project to see how hard of a task it would be. Its also a watch i had lying around and stopped using it because it was very hard to develop apps for compared to the bangle watch.

As to why i didn't say all this stuff in the beginning. It mostly comes down to not knowing how serious i was about this project. This kind of project is a lot larger then any other project I've ever tried to do. So my thought was to see how hard it was to do the P8 watch and then see if i want to continue and try to make my own PCB for the pebble watch. My hope was either way i thought it could potentially help the project out.

So i hope this makes more sense and I'm sorry if i pressed to hard.

Goal
So just to make sure the goal of my intentions are clear. I never tried to merge this code into the repo because i knew it wasn't good enough to go into the main project. The goal was just to see if this was something worth doing.

LCD_BL
So that's a bug from my lack of knowledge on the "LPM013M126". There's a lcdMemLCD_extcominBacklight and it has a BL pin. So in theory the BL pin should just be in the bangle_backlight_impl.c for hardware that is generic across devices.

LPM013M126
Yes this is for the bangle device. I wanted all the files to mostly be hardware and not device specific. I figured anybody going to try and work on the bangle.js c code, will figure out what hardware is in it.

7 files for backlight
So i can break down the numbers

• 2 files for jswrap_bangle_hardware.c/h - these hold the JavaScript functions and no hardware specific stuff.
  
• 2 files for bangle_hardware.c/h - holds generic functions that can be overwritten by device specific calls.
  
• X files- X being the number unique pieces of hardware that need functions being overwritten
  
  

So for some of these the override files are extremely small and look like a waste of time, but even for just lighting the F18 and the fade implementation both use more then 60 lines each and the code for them was not just in one place but all spread through the project. So for me i can navigate this structure a little better. But i do agree this add a lot of files, but the complexity of the device won't make the number of files go up you'll just have more functions in the file. You can see this in the display vs backlight driver. Same amount of files, but the display driver has way more in it.

finding all the function github is a nightmare
Yes, i would 100% agree. Nightmare is probably underselling that issue. My software style is to have code very spread out. I like my code to fit under that 100 line limit so i don't need to scroll to much. This is probably do to my setup. I personally use like 2 large monitors or up to 4 small monitors at any given time. So i use multiple instances of visual studio code. So i me its completely normal to trace through functions calls.

Code Flow
My goal would be such that jswrap_bangle.c would only hold basic states of the watch. So a startup,events,shutdown. Then the rest would be in the hardware folder.

Final Note
So these are just my thoughts to hopefully clear up some of the topics above. This specific post doesn't need a response if you don't want too. I think i understand were your coming from. Well at the minimum trying my best to.

This took me a while to wright up. So I'll post the WHY I'm doing this in a little bit.

So I'll answer the questions below on how it works and why. But i don't think that's whats actually the matter here. So I'm just going to talk about what I'm thinking about doing.

What I'm thinking of doing is to continue to work causally on this on the side, but I'm going to stop messaging you and this forum about this because its out of scope of this project. I understand that this is something that is kind of a pet project of mine and will in almost no way make the product you make any better.

In the very, very unlikely scenario that many people end up finding my changes helpful. Then we can talk about the potential nightmare of merging it to the main repo. But at the moment theirs no need or huge interest in these specific changes. So at the moment at don't think we need to talk about this any more.

Hopefully this is a no hard feeling on both ends. I still love this project and will try to merge any general Espruino bug fix i find.

@Gordon

So i'll send a larger post after i'm done work .

First i just want to always stress that i don't want to do anything that would add a lot of long term stress for you. The thought was that if it was slightly more module it might make it easier to manage. But like you said your the person who wrights 90% of the code so if you find it harder then it will slow down the majority of the work being done. Which will hurt the project at large.

As for the idea of the time put into this. Don't worry to much about that. I've learned a lot and i'm fine working on my repo. This is just my test bed at the moment, so it's fairly ruff now so maybe someday it will look better and make more sense.

Like i said i'll make a larger post after work. I just figured you were gracious to give a very well thought out response so i thought it deserved a quick response.

yes the buttons have changed. The original bangle watch had buttons on a flex cable. Also the Bangle JS 2 only has 1 button soldiered to the board.

I think you can flash a f18 with banglejs

Build changes

Small change. I thought in the boards file BANGLEJS should be in the libraries section. Then in the Makefile you can easily do a IF USE_BANGLEJS you can add all the needed WRAPPERSOURCES and SOURCES files. change in makefile

The alternative

The alternative to this would be to look for the define -DBANGLEJS_DEVICENAME. If there then you add add all the supporting bangleJS files. My original thought was to look for -DBANGLEJS, but for some reason the original bangle watch doesn't have that.

Potential thoughts forward

We had previously talked just moving one hardware driver at a time to slowly migrate the code base. So i first did the backlight and display driver because i thought they would move the most code out of the main file. Which it did, but I'm thinking maybe the best route forward would be to choice the least critical and used device. So for the first device take the barometer. Something that's only used on a subsection of devices and in most cases just a nice to have. If its not received well, then its easy to migrate back.

@Gordon

One of the coolest things i've seen posted on this forum. Look forward to see what it looks like when it finished!

Yep, i merged up with the current build and it fixed all my problem. So It currently has backlight and display code moved to separate drivers.

Ok, so I've checkout a version from February that had no modifications and it also doesn't work. So I'm guessing it has to do something with "DESPR_PACKED_SYMPTR".

I'm guessing something I've flashed onto it is not compatible to the newer stuff.

So i got the BangleJS2 watch working just like the normal build. Now trying to get the bangleJS1 working properly. It draws properly until it reads from the flash and then it just draws wrong. Then when you connect it to the Web ide it still draws weird. Even when you tell it do draw direct.

But I'll figure that all out soon. Its just been a few month since I've updated this. Mostly been working on other hardware and my job's been taking up too much time lately. haha

This is directly from github

So my bangle 1 watch seems to be acting wear when i program it. I see the booting part fine. So i know the screen is ok. Just when it loads after that the screen just produces garbage. I cab load a program on it fine just the screen doesn't seem to want to display data correctly.

So I've reset the flash

• require("Storage").eraseAll();
  
• installed "installed default apps"
  
  
  

Fairly easy to get the display working

• display
  
• official espruino module
  
• my gist with the pins changed
  

@dandelany
Did you ever post the code for this. I'm hooking up the exact display.

I'm able to flash the bangle1 and get bangle one there. I just commands @Gordon runs before sending a watch out. What the setup to make a watch function as if its getting send to a customer. The way I'm doing is doesn't include all the launchers and apps. So i can go to esperuino IDE and upload stuff. I just don't see any of the apps.

To flash i run this

echo "load bin/espruino_2v21.84_banglejs.hex" >> gdbinit
echo "load bin/espruino_2v21.84_banglejs.elf" >> gdbinit
echo "load bin/bootloader_espruino_2v21.84_banglejs.hex" >> gdbinit
echo "load bin/bootloader_espruino_2v21.84_banglejs.elf" >> gdbinit
echo "load bin/espruino_2v21.84_banglejs.app_hex" >> gdbinit

I remember from this post you do a make .... flash then do a gdb file load. But the flash command only works with segger tools because it uses "nrfjprog"

I figured that what embedded developers do for fun ;)

Ok, i'll give it a go. Thats a tight build if the compiler changed the size enough to make it not fit!

Sorry i must be doing something really dumb but this is what i'm doing.

source scripts/provision.sh BANGLEJS

• Expected 13.2.1
  
• Got 10.3.1
  
  

make -j BOARDNAME=BANGLEJS BOARD=BANGLEJS RELEASE=1

LD bin/espruino_2v21.84_banglejs.elf
BANGLEJS bin/espruino_2v21.84_banglejs.elf
python scripts/check_elf_size.py BANGLEJS bin/espruino_2v21.84_banglejs.elf
Testing bin/espruino_2v21.84_banglejs.elf for BANGLEJS
STORAGE: 0x60000000 -> 0x60400000
FS DATA: 0x76db8 -> 0x76dc8 (16 bytes)
FLASH_AVAILABLE: 0x76000
CODE: 0x1f000 -> 0x76dc8 (359676 bytes)

==========================
CODE AND STORAGE OVERLAP
by 3528 bytes
==========================

So what i'm tying to do seems very simple, i just want to flash bangle.js on a bangle 1 watch. Other then having a wrong gcc version, it should build?

So I'm connected to Vbus and ground on the power input. Also connected to the programmer pins connected to my pi Pico

That work great!

Steps to reset NR52 Device

• grab software here
  
• The apps built in Rust so you'll need that plus Rust package manager cargo
  
• also need "sudo apt-get install libusb-1.0-0-dev librust-pkg-config-dev"
  
• Then run nrf-recover
  
  

Error i saw

Error No supported probe was found - unplugged programmer device or not configured correctly

Error Didn't receive any answer during batch processing: - most likely you have your i2c lines mixed up

So i wasn't even able to program it without the battery using my raspberry pi pico board. Don't know why? pico should be able to produce up to 300mA?

But it doesn't really matter anyway because when reattached the battery and try and program it i get "Device has AP lock engaged". So i'll have to use a real segger programmer anyway and completely erase the chip.

Will i be able to recharge the battery if i attach VDD?