Skip to content
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

Open
gfwilliams opened this issue Oct 2, 2019 · 6 comments

Comments

@fanoush

This comment has been minimized.

Copy link
Contributor

@fanoush fanoush commented Oct 2, 2019

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.
Why not moving jsvInit before jshInit in general? Can this break something else?

@gfwilliams

This comment has been minimized.

Copy link
Member Author

@gfwilliams gfwilliams commented Oct 2, 2019

moving jsvInit before jshInit (variables before hardware) is conceptually wrong?

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.

if jsvInit could also handle some pre-population

That's what jsiInit does - which has to come after jshInit.

@fanoush

This comment has been minimized.

Copy link
Contributor

@fanoush fanoush commented Oct 2, 2019

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

@fanoush

This comment has been minimized.

Copy link
Contributor

@fanoush fanoush commented Oct 2, 2019

The idea is that jshInit should really be low-level hardware. ... you might initialise QSPI RAM, and then put the variables in there.

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.

@gfwilliams

This comment has been minimized.

Copy link
Member Author

@gfwilliams gfwilliams commented Oct 3, 2019

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.

@fanoush

This comment has been minimized.

Copy link
Contributor

@fanoush fanoush commented Oct 4, 2019

Ahh - when I push the smartwatch stuff it'll initialise an external flash chip in there at least,

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.