-
What do you think about this quote from sparkfun.com tutorials.
Application Dont's
As tempting as it may be to use a voltage divider to step down, say, a 12V power supply to 5V, voltage dividers should not be used to supply power to a load.Any current that the load requires is also going to have to run through R1. The current and voltage across R1 produce power, which is dissipated in the form of heat. If that power exceeds the rating of the resistor (usually between ⅛W and 1W), the heat begins to become a major problem, potentially melting the poor resistor.
That doesn't even mention how inefficient a voltage-divider-power-supply would be. Basically, don't use a voltage divider as a voltage supply for anything that requires even a modest amount of power. If you need to drop down a voltage to use it as a power supply, look into voltage regulators or switching supplies.
-
-
-
-
after reading http://forum.espruino.com/conversations/350764/ , i did some digging and have some questions.
The pin used for voltage reading is pin 30. I used :
console.log(analogRead(30))
after it being fully charged and got the value : 0.63110351562
/// get battery percentage JsVarInt jswrap_banglejs_getBattery() { JsVarFloat v = jshPinAnalog(BAT_PIN_VOLTAGE); const JsVarFloat vlo = 0.51; const JsVarFloat vhi = 0.62; int pc = (v-vlo)*100/(vhi-vlo); if (pc>100) pc=100; if (pc<0) pc=0; return pc; }
from jswrap_bangle.c. Notice the upper and lower limits hard coded into the formula.
Was this code aimed for a more weared down battery? average use case?
I'm thinking to use analogRead instead of E.getBattery. Is this a good idea?Edit: I also discovered E.getAnalogVRef() which outputted a number close to 3.3 v
So ... 0.51 * 3.3V = 1.683V
and 0.62 * 3.3V = 2.046VWhy are the battery volt limits for 0-100 between these 2 numbers?
-
Hello espruinoers.
I've skimmed through the espruino firmware source code and noticed that the flash access is abstracted between the internal flash and the external. I am not experienced in hardware but am curious to develop my understanding of how it works.
I read that writing to flash is done by removing 1's from the cells and that to write 1's an entire block must be reset to 1's. My information source(youtube) described a hierarchy of dies->planes->blocks->pages. My question to you is, how much of this regulation is controlled automatically by the flash controller and how much has to be programmed into the firmware by eg. yourselves. My impression from the Espruino source code is that its all automatically handled?
I did some research and came under the assumption that the external flash has 10x more endurance for erase/writes ( 10,000 compared to 100,000 ) although this cannot be confirmed because we don't have access to the exact datasheets. I used the Macronix MX25 as described on this forum for being a close match. If the external can handle more write/erase wear, is it being prioritised on the firmware level or is the internal firmware going to be hit harder because its address space that refers to it is smaller. If one starts small and increments up... Should i be concerned?
If I upload a file with same name that already exists to flash, does the file get moved to new cells?
Please correct me on all accounts, I'm here for learning.
-
FYI: https://github.com/espruino/EspruinoTools/pull/124
BTW I am amazed you still use words like 'compliance', 'fixable' and 'limitation' for such non issue.
Well, it can be a big deal for some users who are not familiar or technical. And want 1:1 behaviour in the ide emulator without having to dig around. It depends on their initial expectation when using the ide. Mine was clearly wrong.
-
-
Some good news :)
After uploading the test code to the device. Expected output is seen!
Thanks for your time.EDIT:
Ye so because its doing it line by line there is a moment of emptiness/silence and the timeout callback is fired. Limitation of this web ide to visualise the output. Even when its emulating in "RAM" via the ide connected via bluetooth this happens too. It should be fixable, if it matters to anyone. But not a big issue if it works as expected on the device and not line by line emulation/debug w/e -
Im thinking the reasoning behind not having this compliance could be related to accuracy of scheduling? If the hardware execution is slow, it will make the timers less accurate and suspended too far into the future?
Or that it never has a break and is endlessly running code, so then the scheduled tasks would never execute , hmm. -
Tested on node.js. Outputs 'as' i expected:
done
nopeyep
yep
yep
yep
yep
nopeCan you point me to 'javascript standard' that would backup your expectations?
https://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf#page=169
A Job is an abstract closure with no parameters that initiates an ECMAScript computation when NO OTHER ECMAScript computation is currently in progress.
Their implementations MUST conform to the following requirements:
At some future point in time, when there is NO running execution context and the execution context stack is EMPTY|
Did you try to save it to flash and reboot?
I will try this later.
-
-
Some more evidence of what i'm talking about.. without console.log..
var ypos = 5; setTimeout( function(){ ypos = ypos + 20; g.drawString("timeout", 5, ypos, 0); },0); var x =0; while ( x < 100000 ) { x++; } ypos = ypos + 20; g.drawString("final", 5, ypos, 0);
timeout should be printed below final because ypos would be larger if the setTimeout callback ran 'after' the code was parsed and in idle state..
however its not the case and final is printed below (lower on screen == higher ypos value)..
So i take back my last response about it being something related to console.. -
@fanoush ye i think you're right.
I think its doing what its meant to, just the output is confusing me. I'm reading the left hand side of the web ide incorrectly. Like i'm not sure if i read top down , or down up, i thought it was like a traditional console, but having doubts. Also why does the output from console.log within the closure/timeout not have '>' before it. If it was output "AFTER" the while loop, then it should be "BELOW" .. if i'm reading top down.. -
-
To my understanding of javascript, asynchronous-like behaviour from timeout is meant to run when execution stack is empty. I expect output with 'nope' at the bottom of the list. Why is this happening? Im running in the 'web ide' with emulator mode. Tested on my bangle watch connected to the ide too, same.
setTimeout( function(){console.log("nope");},0); console.log("yep"); console.log("yep"); console.log("yep"); console.log("yep"); console.log("yep"); var dontgetit = 345;
OUTPUT:
>yep nope >yep >yep >yep >yep
another example :
setTimeout( function(){console.log("nope");},100); var x =0; while ( x < 10000 ) { x++; } var dontgetit = 345; console.log("done");
Does anyone know where this code is called from? I can't see a reference to GB function
Looked in weather app and gbridge app. Hmmm
EDIT: Found an answer : http://forum.espruino.com/conversations/345459/