New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JS variables used before initialised when BLE init #1696
Comments
So moving jsvInit before jshInit (variables before hardware) is conceptually wrong? THe ble code may try to read some default for mac address from variables which may look useful in general. So if jsvInit could also handle some pre-population of default values of some variables from some static data the ble_init code could make sense then. |
The idea is that jshInit should really be low-level hardware. For example in systems that support it (stm32 or nrf52840) you might initialise QSPI RAM, and then put the variables in there. Ideally BLE wouldn't be initialised there, but it's probably needed for other stuff. Maybe not though? Maybe it could be initialised later on.
That's what |
I see. So looks like the HW stuff could be splitted to really low level basic global stuff (ram, stack, cache, cpu) and then the higher level. Because even e.g. the uart initialization and then console setup in jshInit is pretty high level and could setup Serial1 variable properly with speed etc |
When looking at nrf5x jshInit I am really not sure if there is anything at all which is so low level on this platform as there is no such stuff like setting stack, cpu clock or cache, ram timings, enabling FPU etc. |
Ahh - when I push the smartwatch stuff it'll initialise an external flash chip in there at least, which will then be used for loading saved code into RAM. |
What I wanted to say that currently most of the code is in fact high level stuff that belongs after variable (=javascript memory) initialization. So I'd suggest to add jshLowInit and move only stuff that are needed for variable init there and keep rest in current jshInit and move it after jsvInit and use javascript variables in jshInit freely (like e.g. setting Serial1._options properly when initializing it and using serial console). That also looks better to me than moving BLE init elsewhere into some new jshHighInit. |
Just had another look into this - everything I can find called from Have you seen this problem since @fanoush? I get your point about having two initialisation functions, but I'd argue that some of Perhaps the better option is to do the super low level stuff in jshInit (like the clock) but to initialise the BLE stack in |
I'm pretty sure this can be closed now - I had a go through this a while back to make sure all the uses during bluetooth init were safe. |
Looks like this:
Espruino/targets/nrf5x/bluetooth.c
Line 2408 in 6a47581
http://forum.espruino.com/comments/14925743/
The text was updated successfully, but these errors were encountered: