Espruino makes IoT as easy as 123!
Most recent activity
@user111953 ...take a look at this https://devzone.nordicsemi.com/f/nordic-q-a/17668/gpio-high-drive-on-nrf52-any-limitations - points to the page with the attached graph. The higher the load in [mA], the higher the electromotive force compared to the ground in [volts]. The device is not strong enough to pull it to 'real' ground on sinking. Similar to sourcing: The higher the current in [mA] the lower the electromotive force on the pin. Therefore, the GPIO max current is usually specified so that the output voltage is still safely in the 0 and 1 logic ranges (incl with some noise). So much with 'static' load - switching frequency and thus also capacitance and other ...ances do not matter (yet). You can then calculate the dissipation yourself and know when you get into the zone of frying things that don't even show smoke when turning 'crispy'.
Multiple factors play in to the limit, last but not least what is the voltage level you expect at the pad. Total dissipation is for sure defining the absolute cap and high average load has other impacts on the device.
In an exercise - GPS powered by Espruino pin(s)- I successfully powered a now pretty outdated and power hungry GPS by Espruino pins. I used the PICO which is for sure quite a different device, but experienced principles there apply here as well. Somethin not to forget is that the PICO has no RF, and RF adds a lot to dissipation challenges.
When you look at bangleJS hardware, pins do not directly drive loads. They either
drive a (FE)Transistor or the enable pin of LDOs, which is a superb way to control power...
@Julian1, glad you got it working great for you. Initially, I wanted to point out the path @hungryforcodes pointed out. It is a great option when you ran out of memory for the the code. For development though, I don't like it much. When I ran out memory, I developed the components with plain upload and used 'save-on-send' for the whole with all the components together. Using the Storage module, or - as @Robin mentioned - use serially connected, external flash. Doing so, you can easily chane the data on the flash. You can even just put a loader into Espruino and have all the code (and data) on the external flash. On startup, the loader reads the code as modules dynamically / on demand and operates on the data. (Of course, you do not get the support from the upload regarding dependencies, but you get great flexibility (cross devleopincluding practically unlimited storage.
I did not intend to propose base64, I just wanted to point out the approach.
More is to say: Reading strings form
require("Storage").... has the advantage of being mapped until pulled and is perfect for streaming; see transferring files using special setup for Transferring large amounts of data on https://www.espruino.com/Internet. With that the application can control how big the memory chunk is to be. At best, it could be that no RAM - or just for control - is used because some DMA was in discussion, and that could move data directly from flash to http transmit buffer. I do not know the internals, but streaming is for sure the way to go.
Next thing is, @Julian1, do you really need to serve everything from Espruino? UI infrastructure stuff can be pulled from anywhere and when you are on the www, only essentials have to be delivered from Espruino device and all the other stuff comes from a regular server, even from Google or so... For an example take a look at poast about Shiny Web UIs - you can check out the whole conversation and conversation related to this.
A different approach is to just ship the data to a mid tier Web and App server stack using mqtt. A flavor of that can be boot the app from that Web and App server and the connect only for the data directly (triangle) using pull / push-pull / long-polling...
I don't know about your hardware configuration, but there is a way to stream data from flash... take. look at this conversation about Best way to stream base64 encoded string to a web client. This is not the only conversation about how to handle large amounts of data. You find more, also in the way how to upload and save it right away in flash which also gives you more options of managing your resources. But as said, it depends on your hardware because not all of Espruino runs or is supported in some hardware. Best is to use an Espruino genuine board, because the Espruino firmware works there the best.
What's discussed so far is static stuff that happens once on upload...
Espruino can though also use unused space in the flash for non-volatile storage, populated with write and then read back with read. Works perfect when way more read than writes... but I would not exactly call this as RAM, even though rewriteable at runtime.
Rewrite has its issues. Inherent to the technology used, a rewrite can only happen after an erase, and the number of erase and rewrite cycles are limited. Espruino components to write to and read from "Storage" - as it is called - makes it very acceptable and super easy to use: it takes care of the erase as well as applies wear leveling to get maximum life time out of flash uses as r/w Storage.
require("Storage").xyz()` - the Storage 'class' at https://www.espruino.com/Reference#Storage ( and as well https://www.espruino.com/Reference#StorageFile )...
I hope this helps you to conceive the app you have in mind to fit...
what if the pad on the PCB is a via with the small hole, does the capillary force suck in the solder from the back side of the PCB?
@HughB / @user126378, you may have authenticated differently and that created this new account... Happened before to others. I do not exactly know why and how, nor how to detect and avoid.
@DanTheMan827, I see where you are going... I resolved this issue with having dedicated processors just for the time critical things... That was one of the reason ESP8266-ESP1 connected serially was such a success. Even the 8-Bit Arduino could do things and have great connectivity. ESP-32 was the integrated answer: two processors, on for time critical things in low level implementation and one for high-level, where times of a different magnitude matter. Having a single processor is always a challenge.
...to keep things a little easier, have the firmware call a loop method.
...is the defeat of an event driven, on lowest power operated system.
@DanTheMan827, just as you say in next paragraph: Arduino. I agree absolutely that this is 'simpler' for to start with because one has not to deal with events: logic is only status / flags (variable) comparison whether to do something or not... (reminds me of key concept of conditions in RPG, 1959..., and the birth of PLC, 1968). Limitations though hit very quickly...
...pub to .../modules has to happen to get modules updated.
Furthermore: the connect sets stuff in the SX127X... (writes to registers of XS127X) which has to rerun on every power cycle... This is in addition to the fact that that setting of stuff is done in an asynchronous matter... and that is the actual - compound - issue.
@gendor, for the SX127X init reason, it is a good practice to always have an onInit() construct in the code to ensure consistent behavior no matter what upload approach is used and power cycle.
@Gordon, what's the reason to not do simple callback to follow the prevailing pattern of
.connect() (with undefined/err arg)? I'm aware of the callback hell... but at this point it is not hell yet and but I'm not sure if it is worth to complicated it that much with a Promise, even though it is more sophisticated.