Search results for:

is build_jswrapper and build_jswrapper_efficient. Doing the same thing just one is build for speed?

So i found a few instances where there are jswrap functions without having any javascript definitions above it. Example

Just checking to see if this is a bug or on purpose.

This is kind of a nit pick, but if i do end up pushing a commit to move some code out of jswrap_bangle.c i could change this when i see it.

I don't know how hard this would be, but if the bangle devices name define was visible from a file. This would help me out a lot. Right now my ide doesn't know what device its working with. So the device specific code will be darkened out in my IDE. If it could go in the platform_config.h that would be very handy.

Bangle device name

Thanks for the feedback :)

Making a bunch of small PRs makes a lot of sense to me. It avoids doing a really hard complete test at the end and avoids the problem of having to bring up my branch to the current espruino branch. I removed most of the code in my build because i thought it would be easier to understand the flow of the code. I wasn't all that worried about merging it into the main repo because i just wanted to properly convey what i was thinking. Then we could figure out what to do from there if it was worth the effort.

I think it should be "fairly easy" to do this in smallish PRs. Since i didn't change how things worked. The only things that changed would be the functions that your moving out. So each PRs should be fairly self contained.

I got a small video showing the current state.
https://youtu.be/GTdgfV9q_DU?si=oRSj-GhJiGByzBRH

Thanks for the info. I think i understand everything now.

Ok, got it. Thanks so much for clearing this up for me! I've never used any of these watches. I just assumed that all smart watches used a full touch screen.

One last thing. There seems to be a touchscreen device. Which is different then the touch device. This seems to use SPI.

Do you know how these are handled? I see there's a STROKE lib for handling gestures. But i don't see a place to handle getting the position of the touch events when your not using bangleJS.

So when i do a search for -DBANGLEJS in the board files i see these watches.

• Bangle - (F18)
  
• Bangle2
  
• ID205
  
• Dickens
  
• DTN01_F5
  

That is helpful, but what i'm looking for is a little lower level.

So here's where the underlining code gets called to handle touch events

It gets called here. But this can only be reached by the bangle2 watch.

Here is where the bangle 1 gets its touch events from

So i know there's a few other watches that are supported with bangleJS and they have touch screens. So i'm curious how do they get there touch events. Since both of these touch event handlers are covered in defines that only work for the bangle watches.

So this is what i understand

• Bangle 1 - 2 touch zones
  
• bangle 2 - i2c for gestures and position of touch
  
  

There are two defines TOUCH_DEVICE and TOUCH_I2C.

• Touch_I2C - seems to only be enabled on Bangle 2

• Bangle 1 - bt4 and bt5 are used as "touch handlers"

So i know there are a few other watches. I just don't know how they get there touch positions from bangleJS? Most of the touch code is wrapped around either F18 or BQ3 defines.

This conversation can continue here

So i'm working on making BangleJS work with my Pinetime and to do that I'm trying to migrate some code outside of the main jswrap_bangle.c file. So it will be easier to add the PineTime specific code.

So the code here

Notes

• I don't have either a bangle 1 or 2. I plan to buy one just currently it would be a pain to ship it to were I'm at.
  
• this code isn't cleaned up at all. Just something I'm playing with.
  
  

My primary goal is to move out to its own folder. Then have function that can be overwritten based on what piece of hardware you using. There's probably a more advance way of doing this, but it seemed to clean it up enough that i could follow the logic of what bangle was doing and how the hardware did it.

Currently i only have Backlight and display. But it shouldn't be too hard to continue this pattern for the rest of hardware. There even might be a nice way to wrap things like GPS,HRM,Compass since they follow a similar pattern of ("is ON", set power, rd,wr). So then you should have a array of hardware to iterate through.

So this is a continue from this post. I'm posting this to see if this is something that should be continued or if its making some compromise that makes the the situation worse.

Once again i appreciate the amount of time people take to actual respond to this. So I'll try not to waste to much more of your time, since i think it will probably be more meaningful discussion once i have at least a working display.

But hopeful these responses will make you slightly less worried. Granted your still rightful to be skeptical of it working. I'll probably find some big bugs once i get into this more.

But I'm very worried about copying stuff out in such a way that you then end up duplicating loads of code, because then it makes maintenance a nightmare. What if I want to change how buzz works but now there are 10 identical jswrap_banglejs_buzz implementations spread across the Espruino and alt_watch repos?

My "goal" is that it wouldn't really matter all that much how bangleJS worked. I'm trying to encapsulate hardware. So if you imagined jswrap_bangle.c without most of the defines. That's what i would like. Granted defines will still probably be used just in a slightly different way. I just want to separate the larger state machine of bangleJS from the unique features of each device.

So for you example about buzzer, i haven't tried to make it but from the states it might look like this.

• buzzer_beep()
  
• buzzer_buzz()
  
• buzzer_vibrate()
  
  

These functions would be overridable if they needed to be. Granted a thing like a IMU will probably need a more advance abstraction because it's more complicated.

So yes i also wouldn't accept the idea of if you changed the Buzzer, backlight or other hardware that it would cause a huge backlog of devices to not be useable. I understand that nobody would ever want that level of burden. Especially a open source project.

while yes it'll probably get compiled out, it just makes everything harder for developers who then have to try and follow a series of stubs to get to the actual code. This has been done in the ESP32 port and it just makes trying to work on it a nightmare

Your probably right on this. How would you feel about moving the true pure javascript stuff out.
Ex.
here to here

hereto here

First i just want to say, it think @Gordon approach is the best open source watch platform by a long shot. These thoughts are just my attempt at making it more universal.

2 repo's worse then a single one

So this is true that there would be some copying from the main repo to the generic.

But to help mitigate this what i would do is move all the JS wrapper functions calls to separate file and they would just call a single c function. If you remove all the code and just leave the JS wrapper calls its around like 1800 lines of code that would be shared. Since it's a single call it will be optimized away.

Also there's a good amount of device specific code that wouldn't need to be migrated over. So its only code thats completely generic.

Code placement

So in a perfect world. Where i would like this is.

Espruino/libs/banglejs/alt_banglejs

This folder would be a separate github repo. So it wouldn't mess with the main code. But it could benefit from all the changes from the general espruino improvements.

In this folder you could also put the pythonBoard files

Hard problem of devices working differently and being efficient

So the approach i'm thinking of is going to 100% reduce some efficiency's. But all abstractions will cause this. But the lack of abstraction is probably part of the reason why not many watches have been ported to banglejs. Know i don't know if its worth it, But i think its worth a look into how it might be done. That's why i'm trying to make a little test bed and play around with it.

But now i can actually bluetooth to the board. So i call that a huge win.

Good news

I was able to get this build to actual work.
So I'm using the bootloader : 0 for now. I'll deal with that problem at another time.

So know i'm sorry i don't understand why this work but it seems to work. I was getting random crashes at place and i wasn't allowed to use any of the bluetooth function and these problems seemed to all go away when i did this.

@echo "load bin/espruino_2v19.88_p8_SDK12_SD30_SPIFLASH.hex" >> gdbinit
@echo "load bin/espruino_2v19.88_p8_SDK12_SD30_SPIFLASH.elf" >> gdbinit

If i used just one there would be problems in different spots.

When you flash it to the board you get mostly different things flashed?

hex

Loading section .sec1, size 0x964 lma 0x0
Loading section .sec2, size 0xf000 lma 0x1000
Loading section .sec3, size 0xebf0 lma 0x10000
Loading section .sec4, size 0x1000 lma 0x1f000
Loading section .sec5, size 0x10000 lma 0x20000
Loading section .sec6, size 0x10000 lma 0x30000
Loading section .sec7, size 0x10000 lma 0x40000
Loading section .sec8, size 0x10000 lma 0x50000
Loading section .sec9, size 0x77d4 lma 0x60000
Start address 0x1f7bc, load size 421160

Elf

Transfer rate: 19 KB/sec, 13161 bytes/write.
Loading section .text, size 0x4871c lma 0x1f000
Loading section .ARM.exidx, size 0x8 lma 0x6771c
Loading section .data, size 0xa0 lma 0x67724
Loading section .fs_data, size 0x10 lma 0x677c4
Start address 0x1f7bc, load size 296916

Sorry for being very vague and just asking single ended questions. My plan was to get something working then make a formal right up about what I'm trying to do, to see if it worth the effort. But like everything its always harder then it seems

Primary Goal

I'm trying to use @fanoush pinetime python build file and make it a "real" fake bangleOS watch.

Bigger picture

Make a way to port watches easier to bangleOS

Why

Related this topic. My thought would be if all the watches used the same bangleOS then it would be easier to make apps works across devices. There seems to be many devices that can use Espruino but are not using Bangle primarily because its hyper optimized to work with the watches being sold to actual fund this project. Which it completely fine.

How

So my thought is to have 2 builds that are function compatible with bangleOS. So the official one and the secondary one that is more like a "c compiled time driver version" that's unofficial. So there would be a layer of abstraction on each type of hardware device and at compile time you would selected the types of hardware from the configuration file. What this looks like now is just a copy of jswrap_bangle.c just stripped to the function calls and I've started to make a few stubs for the display driver.

Problem

I'm having a hard time getting to the point were i start actual trying to my idea's. Currently i can't seem to even build it. This leads the above problem i had were if i had the "BOOTLOADER=1" for some reason i get a error saying the I'm overflowing the RAM. I tried to remove just about everything and even faking the ram size in the python file, but that didn't help. So I'm thinking of starting from the top and trying it again and see what i did wrong.

So i tried to set the bootloader to stop the merging hex files.
make BOARD=P8-SDK12-SPIFLASH -j8 BOOTLOADER=1

But then i get a overflow issue region RAM overflowed with stack
:/

Ok so i don't think i'm running into a "error" --overlap. It seems like it part of the build script?

So there seems to be two types of defines

• BOOTLOADER
  
• USE_BOOTLOADER
  
  

And in my python board file i have 'bootloader' : 1. This one is sets USE_BOOTLOADER to true.

As for BOOTLOADER

• BOOTLOADER=1 make the bootloader (not Espruino)
  
  

link to code

$(PROJ_NAME).hex: $(PROJ_NAME).app_hex
 ifdef USE_BOOTLOADER
  ifdef BOOTLOADER
	@echo Bootloader - leaving hex file as-is
	@mv $(PROJ_NAME).app_hex $(PROJ_NAME).hex
	# for testing:
	[#python](https://forum.espruino.com/search/?q=%23python) scripts/hexmerge.py --overlap=replace $(SOFTDEVICE) $(PROJ_NAME).app_hex -o $(PROJ_NAME).hex
  else
	@echo Merging SoftDevice and Bootloader
	@# build a DFU settings file we can merge in... family can be NRF52840 or NRF52
	nrfutil settings generate --family $(BOOTLOADER_SETTINGS_FAMILY) --application $(PROJ_NAME).app_hex --app-boot-validation VALIDATE_GENERATED_CRC --application-version 0xff --bootloader-version 0xff --bl-settings-version 2 $(OBJDIR)/dfu_settings.hex
	@echo FIXME - had to set --overlap=replace
	python scripts/hexmerge.py --overlap=replace $(SOFTDEVICE) $(NRF_BOOTLOADER) $(PROJ_NAME).app_hex $(OBJDIR)/dfu_settings.hex -o $(PROJ_NAME).hex
  endif
 else
	@echo Merging SoftDevice
	python scripts/hexmerge.py $(SOFTDEVICE) $(PROJ_NAME).app_hex -o $(PROJ_NAME).hex
 endif # USE_BOOTLOADER

```

So commenting out a few parts i managed to get to jsiInit in the main.c file.

I'm still trying to figure this out, but this isn't were it laod the banglejs_storage is it?

Currently i'm working on modifying the bangle code project.

I'm surprised you hit issues with --overlap=replace

overlap=METHOD
What to do when data in files overlapped.
replace -- use data from last file that contains data at overlapped address

That does sound very bad :/

I should probably look into that.

I can agree with that. I'm currently using my pico as a program because i found it easy to set up and more reliable then my fake JTAG programmer.

A normal console being a serial console? Do you remember what command you used to reset it?

Yes so i need to debug the initialization of all the hardware. But whats interesting is that it seems to fail just because its in GDB. without hitting any breakpoints and restarting?

For example. i startup GDB and hit continue and it breaks? But if i just flash the software normally it works fine?

A lot more hurtles then i was expecting to step through the software :/

I think i'm just going to try and comment that line out and see it will work just without bluetooth. Just so i can make some forward progress. Then i'll try and figuring out the above link you sent me. Right now thats slightly more in the weeds then i want to be at.

current stack trace

(gdb) bt
#0  0x000008c8 in ?? ()
=1  <signal handler called>
=2  0x0000092e in ?? ()
=3  <signal handler called>
=4  0x00053c02 in sd_softdevice_enable (p_clock_lf_cfg=0x2000fe28, fault_handler=0x53bb1 <softdevice_fault_handler>)
    at targetlibs/nrf5x_12/components/softdevice/s132/headers/nrf_sdm.h:286
=5  0x00038dc2 in softdevice_handler_init (p_ble_evt_buffer=0x2000b8c8 <BLE_EVT_BUFFER.2>, ble_evt_buffer_size=80, evt_schedule_func=0x0,
    p_clock_lf_cfg=0x2000fe28) at targetlibs/nrf5x_12/components/softdevice/common/softdevice_handler/softdevice_handler.c:277
=6  softdevice_handler_init (p_ble_evt_buffer=0x2000b8c8 <BLE_EVT_BUFFER.2>, ble_evt_buffer_size=80, evt_schedule_func=0x0,
    p_clock_lf_cfg=0x2000fe28) at targetlibs/nrf5x_12/components/softdevice/common/softdevice_handler/softdevice_handler.c:277
+7  ble_stack_init () at targets/nrf5x/bluetooth.c:2539
+8  jsble_init () at targets/nrf5x/bluetooth.c:2862
+9  0x0003a27c in jshInit () at targets/nrf5x/jshardware.c:961
+10 main () at targets/nrf5x/main.c:27