Most recent activity
-
- 19 comments
- 1,328 views
-
- 39 comments
- 2,520 views
-
Comment/Question
_impl stuff quite odd
so I don't get why there is _impl everywhereI 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
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.
- Bangle_hardware_impl.h/c - "Impl" short for implementation
-
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.
- barometer libs - supporting libs
-
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.
- 2 files for jswrap_bangle_hardware.c/h - these hold the JavaScript functions and no hardware specific stuff.
-
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.
-
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.
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:
It's kind of self documenting code.
@Gordon