Most recent activity
-
I use a (TI) DRV8833 - family member of DRV8847 - on a breakout board in combination with the Espruino MDBT42Q breakout board. - 'New' (Pixl.js), in deed, because I came across the (TI) DRV chips on a different path.
Combining something like the super tiny nRF52832 - but in ...40 capacity would be cool, as used in the recently pub'd Espruino-Ring example by @gmurphy - see Espruino Ring, ...and making it a (size-) successor of the Espruino Pico : Espruino Nano-C,.. -C for communicative / communicating / chatting /... ;-)
-
@Gordon, see your point about getting a chip vs. a module, where latter is almost a complete system. That both chip and module are ARM4 based does not really make them differently from an coding point of view. 'Weak' outputs can be complemented with drivers that are now widely available. Therefore, including multiple components - module(s) w/ complementing chips - will bring a good solution.
Regarding complementing drivers, I'm thinking along the lines of a driver with two to four full H bridges that also can be powered from an extra rail with different voltage than what is needed to run the logic (from simple TI DRV8847, MPS MP6550,.. to more complex Allegro A4987, for example).
-
@Gordon, good to hear that the new Espruino board - typically based on an ST chip, I assume - with communication will include combined communication: Wifi and BLE.
-
Neat... something I was looking for a while ago but did not have the times so far... What is the chip on the board? Could you pub a pic of the board?
-
@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.
Checkout out
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?
Espruino makes IoT as easy as 123!