Search results for:

Are you planning to operate on battery, and if so which type, and how long do you expect them to last, i.e. how often are you willing to go around changing/charging batteries? That will really determine your options...

I tried to post the Espruino signs of life text above to the emw3165 forum, but my initial message first sat there for 3 days and now got rejected because of "links to illegal or pirated software", so I think I'm done with that forum.

Signs of life on an EMW3165:

Unfortunately, the looks of the above are a tad misleading because console input doesn't work :-D However, this is better than staring at a non-functional device on my desk! I used a WifiMCU and the st-link-2-1 of a nucleo-F411 for flashing. My fork is at https://github.com/tve/Espruino/tree/emw3165 and instructions for building are at https://github.com/tve/Espruino/blob/emw3165/README_Building.md#for-emw3165

Just to be clear: at this stage you can't do anything with it, except for helping to move the port forward! The Wifi isn't even hooked up yet either.

I've written a bit about the overall port strategy in the README_Building and it would be nice to discuss this further here. I did some Espruino console hacks (use the WICED stdio for putc) to get to the prompt shown above, but I think it's the wrong direction. Rather than use the WICED platform abstraction I think it's better to reduce the use of WICED to the minimum and make it use Espruino's platform where that's necessary and completely remove the management of non-wifi hardware from WICED. I'm pretty sure this can be accomplished for stuff like usart, i2c, spi, etc., but I don't know what it's gonna take for core processor stuff like clocks, timers, interrupts, etc. At some point this also affects the boot process and thus flash layout. The next step would be to dive into the WICED configuration process and the sources (there's basically no useful documentation) and determine how to strip it back and insert hooks into the Espruino platform stuff where that's necessary.

[Ewwww, the formatting in this forum site sucks. I had pasted the text of the screen shot using the code formatting and it looked great in the preview mode but whenever I saved it the results ended up being illegible. Had to resort to the screen shot.]

So you don't have to read through that issue: flash blank.bin to 0x7C000.

Ah, interesting constraints.
I've also been reading similar issues as you point out. The whole ST-Link thing is really a complete disaster, IMHO.

Some more progress: I now have Espruino compiling against the WICED platform stuff and I can link the whole shebang into an executable, download it and call to the Espruino main from a WICED application_start() function. When it boots it gets to the Espruino main_loop() but then evidently dies thereafter.

The whole set-up is quite hokey: I'm producing an espruino_lib.o and I have a WICED "app" that I'm linking Espruino as a library into. Dunno what to do longer term...

Not sure when I'll have more time to see where it's failing...

Github repo: https://github.com/tve/Espruino/tree/emw3165

Yup, I have. This is what I get in the mounted drive's DETAILS.TXT file:

$ cat /mnt/DETAILS.TXT
Version: 0221
Build:   Apr 29 2015 13:11:12

Well, if it works for everyone but me, then that's OK.

My f411 nighties work for me.

You are dragging the .bin to the mass storage drive? Which OS are you using?

NB: I don't have an f401, I was just trying those binaries to see whether any flashing activity would occur.

I did a few more experiments: no espruino_1v*_nucleof411re.bin that I've found or built works when dragging on top of the mass storage drive, whether on windows 7 or on linux. No espruino_1v*_nucleof401re.bin works either. The above Nucleo_display_time_NUCLEO_F401RE.bin works great when dragged onto the mass storage drive on windows (didn't try linux), so the hook-up of the board works. Also, I built a espruino_1v81.68_nucleof411re.bin and that works great when flashed using texane st-flash, so the binary is OK, and the board hook-up works, but copying it to the mass storage drive without making any change to the set-up is a no-go.
The bottom line is that the mass storage drive just doesn't like espruino.

Hi @tve, the bin you flashed has nothing to do with espruino. It is a c code compiled from the mbed online environment!

Yeah, I know, the point was to determine that the board, its hook-up, and the mass storage driver all work when presented with a bin file they like.

I just got a Nucleo F411 board and I can't get any of the Espruino bins to work. I've tried espruino_1v81.37_nucleof411re.bin, espruino_1v81.55_nucleof411re.bin, espruino_1v81.70_nucleof411re.bin, and espruino_1v81_nucleof411re.bin
When I drag the bin onto the Nucleo drive nothing happens. When I try the Nucleo_display_time_NUCLEO_F401RE.bin posted by asez73 a few posts above I see the flashing activity and then the firmware runs great and I can see the output in a terminal window. Are the Espruino builds all broken? Is there some secret sauce? How can I troubleshoot this?
I'm using Windows 7 and have updated the ST-LINKv2_1 firmware as well as the nucleo firmware.

I created docs and took a photo of an esp-12 module. The result is a PR for the Espruino repo and one for the EspruinoDocs repo. There's some work for Gordon to make it all integrate correctly (I think I did 90% of the work).

Gordon, I'd also appreciate some help for how to improve the pins stuff:

• I'd like to make the analog pin be 'A0' but when I comment out

  [#pinutils](https://forum.espruino.com/search/?q=%23pinutils).findpin(pins, "PA0", False)["functions"]["ADC"]=0
  

  at the end of the ESP8266_16.py boards file I get compilation errors that I don't know what to do with.

• similar issue for the PB16 line in the same file (it's intended to be the GPIO16 on the RTC clock)

• how can I add more labels to the various pins to indicate 3.3v, where the SPI pins are, etc?

Oh: someone else gets the privilege to shoot a photo of an esp-01 and copy the pin stuff to the ESP8266_BOARD.py (maybe rename to ESP8266_01.py?)

First connect and then upload. Didn't know one can hit the upload button when disconnected...

I'm looking for a place for user docs. For example to state that GPIO pins do not support an internal pull-down. Or that there's really only one analog pin. Or that I2C is in software, only runs at 100Khz, and doesn't support clock stretching.

When I hit the IDE "Send to Espruino" button I see an echo(0) line and then it pauses for several seconds. Looking at what happens on a scope it's evident that somehow the IDE makes a lot of pauses, why is that? If I take exactly the same code and paste it into a terminal window connected to Espruino it gets uploaded in 200ms. The time taken by the IDE seems independent of the "throttle send" config switch.

Is there a place for board-specific docs in the EspruinoDocs repo, or somewhere else? What I mean is a place for the information we've been capturing here: https://github.com/espruino/Espruino/wiki/ESP8266-Design-Notes

Ah, thanks!

Do the 12-byte JSvars not support the extendable string format?

There's probably a trivial trick I'm not seeing, but I save()'d some stuff in flash and I'd like to erase it so Esprunio comes up "empty" at boot. How do I do that? (I know how to erase the relevant sector in flash on an esp8266, but I think there needs to be a Javascript way to do that.)

Would it make sense to create a forum for porting Espruino? Or do you want these discussions in the 'general' forum? I never know where to post questions and info about the esp8266 port and I hope an emw3165 port will spin up real soon..

It gets minified. After loading it "only" uses ~420 JSvars, but during loading the string itself makes it all blow up.
The upload is:

Modules.addCached("BMP085","function c(b,a){this.i2c=b;this.oss=\"undefined\"!==typeof a?a:3;if(3<this.oss||0>this.oss)this.oss=3;var d=this.read8(208);if(85!=d)return console.log(\"Bad ID of: \"+d),null;this.readCoefficients()}c.prototype.read16=function(b){this.i2c.writeTo(119,b);b=this.i2c.readFrom(119,2);return b[0]<<8|b[1]};c.prototype.readS16=function(b){this.i2c.writeTo(119,b);b=this.i2c.readFrom(119,2);b=b[0]<<8|b[1];return 32767<=b?b-65536:b};c.prototype.read8=function(b){this.i2c.writeTo(119,b);return this.i2c.readFrom(119,\n1)[0]};c.prototype.readCoefficients=function(){this.ac1=this.readS16(170);this.ac2=this.readS16(172);this.ac3=this.readS16(174);this.ac4=this.read16(176);this.ac5=this.read16(178);this.ac6=this.read16(180);this.b1=this.readS16(182);this.b2=this.readS16(184);this.mb=this.readS16(186);this.mc=this.readS16(188);this.md=this.readS16(190)};c.prototype.readRawTemperature=function(b){this.i2c.writeTo(119,[244,46]);var a=this;setTimeout(function(){b(a.read16(246))},5)};c.prototype.readRawPressure=function(b){this.i2c.writeTo(119,\n[244,52+(this.oss<<6)]);var a,d=this;switch(this.oss){case 0:a=5;break;case 1:a=8;break;case 2:a=14;break;case 3:a=26}setTimeout(function(){var a=d.read8(246),c=d.read8(247),e=d.read8(248);b((a<<16)+(c<<8)+e>>8-d.oss)},a)};c.prototype.getTemperature=function(b){var a=this;this.readRawTemperature(function(d){d=Math.round((d-a.ac6)*a.ac5/32768);var c=Math.round(2048*a.mc/(d+a.md));b((d+c+8)/160)})};c.prototype.getPressure=function(b){var a=this;this.readRawTemperature(function(c){a.readRawPressure(function(f){var g=\nMath.round((c-a.ac6)*a.ac5/32768),g=g+Math.round(2048*a.mc/(g+a.md)),e=g-4E3;f=Math.round((f-((4*a.ac1+(a.b2*(e*e>>12)>>11)+(a.ac2*e>>11)<<a.oss)+2>>2))/(a.ac4*(((a.ac3*e>>13)+(a.b1*(e*e>>12)>>16)+2>>2)+32768)>>15)*(5E4>>a.oss))<<1;b({pressure:f+(((f>>8)*(f>>8)*3038>>16)+(-7357*f>>16)+3791>>4),temperature:(g+8)/160})})})};c.prototype.getAltitude=function(b,a){return 44330*(1-Math.pow(b/a,1/5.255))};c.prototype.getSeaLevel=function(b,a){return b/Math.pow(1-a/44330,5.255)};exports.connect=function(b,\na){return new c(b,a)}");

I'm trying to load the BMP085 module onto an esp8266 with 800 JSvars and I'm getting an our of memory error when the IDE loads the module:

ERROR: Out of Memory!
WARNING: Unable to create string as not enough memory

I have 760 free JSvars after a reset:

>reset
=function () { [native code] }
>console.log("Mem:", process.memory());
Mem: { "free": 760, "usage": 40, "total": 800, "history": 26 }

Does it make sense that this is not enough for this small module? Are there any tricks I could employ?

Question: JSHPINSTATE_IS_PULLUP(state) does not include I2C, i.e., the pull-up is not enabled for I2C even though the bus does require pull-ups. This means that external pull-ups must be provided. Is that intentional?

I'm trying to figure out the gpio and other pin stuff for the esp8266 and I'm confused by the PinState and PinFunction. I see the enums, so I see the difference, but why is there jshSetPinState but no jshSetPinFunction? Is that stm32 heritage and setting the PinState forces a specific corresponding PinFunction?

I've spent the past couple of hours looking at the FAT32 filesystem to use the "internal" esp8266 flash. The characteristics of the serial NOR flash chips are: 4KB block size with the ability to write 256 byte pages (but only erase full blocks). The amount of flash available is 1MB to 3MB for 2MB to 4MB flash chips, and ~32KB for 1MB flash chips (and nothing for the 512KB flash chips).

The problem I'm hitting with the FAT32 implementation is that it really assumes that 512 byte sectors are writable and erasable individually, which is not the case here. Setting the FAT sector size to 4096 would make things work, but then that's the smallest file size, which means that a 1MB filesystem could only support about 200 files and a 32KB filesystem would be a no-go. Write will be really slow because each sector write will consist of an erase followed by a write. On the RAM front the whole thing may blow up 'cause buffers will be 4096 bytes and there just isn't room for even 2 buffers.

One alternative might be to implement sector remapping, i.e., what a wear-leveling controller does, but I don't think we really want to do that. Another alternative is to use a filesystem that is designed for NOR flash, such as SPIFFS: https://github.com/pellepl/spiffs. The same issue will come up to use the 2MB flash on the emw3165, as far as I can tell.

I may just implement the 4096 sector size FAT32 on the esp8266, but I believe the better solution would be to implement spiffs. Thoughts?