Search results for:

The main thing I find missing in a decent TOC for the web site. Some pages like internals and performance are really hard to find. The reference page also needs some love , for example, in day-to-day use I would prefer the first "page" to have a multi-column index so I can immediately click on the class I'm looking for.
+1 On automatically generated docs. What I to look into for myself is how to write high-level comments in the source files so they get picked-up by doxygen.

...

If back-to-back requests aren't working then that's a bug IMHO. The esp8266 is definitely capable of doing the back-to-back requests as well a concurrent requests.

Gordon, thanks for the tip! That might well be the issue.

Well, I made a tiny start so something at least compiles and pretends to be for the emw3165: https://github.com/tve/Espruino/commit/8­2169d6d73f2690a3cac405fc78db65966f2a15a Maybe it'll save someone a few minutes of keystrokes :-). I'm now stuck with an st-link-v2 adapter that doesn't quite want to work. It doesn't reset the emw3165 reliably or something like that. Symptom is "Error: timed out while waiting for target halted". Grrr.

Thanks for the clarifications! WRT jshSleep, since there's this funny main loop task thing in the esp8266 that means that any esp8266 interrupt handler or network callback needs to somehow kick-start the main loop task again if it's asleep. That's gonna a bit a maintenance headache, but certainly doable.

Has anyone gotten any parts of Espruino to work on the emw3165?

Pull request created: https://github.com/espruino/Espruino/pul­ls
I'm gonna take a little bit of a break on the esp8266 and see how much promise the emw3165 holds. The crappy SDK and HW in the esp8266 has gotten at me, plus I just received an emw3165 WifiMCU...

I implemented the utilityTimer functions, but I'm not so sure how to test them. I thought that setTimeout would call that, but it doesn't, so I'm a bit puzzled.

I then noticed that jshSleep gets called with a delay of (2^63)-1 (-1?) from jsInterative. What is that supposed to do with such a value?
Could you also explain a little what jshSleep should do in general? I have the feeling that it should suspend the idle loop for the time requested, is that correct? Is there a notion of canceling a sleep?

An issue I've run into in implementing the timers is that all functions executed at interrupt time need to be in IRAM. This means that I need to set some __attribute__ on each one in order to ensure that they get into the right segment. This means that jstUtilTimerInterruptHandler and everything it calls needs to be tagged as such. But that seems impractical. Thoughts?
The fallback would be to just schedule a task and do the callback there, which will be less exact.

Question about timers: the hardware timer on the esp8266 cannot do intervals under 100us nor over 8388607 microseconds. I was naively going to use a busy-wait delay for stuff under 100us but that could cause recursive calling of jstUtilTimerInterruptHandler which is "not good". Suggestions? For example, should jshUtilTimerReschedule return false if it can't do the interval?
I have a similar question at the long end. Do I need to handle very long intervals or is there a max that Espruino will ask for?

@Gordon how & when would you like to handle merging my esp8266 fork back into mainline? There are a number of things still on my todo list:

1. supporting timers
   
2. reviewing GPIO (I don't understand why there are only 8 in Espruino when the esp8266 has 16)
   
3. adding i2c support
   
4. revisiting Wifi & its initialization
   
5. getting someone else to test my fork a bit, specially on 512KB modules and non-linux compilation
   
6. reformatting the esp8266 files to have the same indentation as the rest of espruino
   
   

I plan to spend significant time on this this week-end, but I'll be working very little (if any) on it this coming week. Dunno whether you want to sync up. Of course anyone can merge my fork to their fork or mainline anytime.

FYI. I implemented system time. Timers are next...
https://github.com/tve/Espruino/blob/mas­ter/targets/esp8266/jshardware.c#L317-L4­70
Feedback welcome.

I added design thoughts on the clocks and timers to https://github.com/espruino/Espruino/wik­i/ESP8266-Design-Notes#system-time.

I'll add comments to jshardware.h and you can then review and correct.

OK, I guess it comes down to preference/opinion. Let me try to enumerate why I believe that auto-save should be the default ;-):

• On the esp8266 the default when setting the wifi config is to save it to flash.
  
• On our laptop, when you associate with an access point it also gets stored and comes up again. You don't say "save this network" explicitly anywhere.
  
• If you don't auto-save you really have at least two configs, the saved one and the current one, so you really need more functions to set the current, set/save the saved, get the current, and get the saved one.
  
• The esp8266 actually has a notion of storing multiple network configs, like your laptop, and picking the appropriate one after a scan, but I have not seen code that uses that
  
• When you have persistent connections the notion of saving becomes a bit odd IMHO: you're saying you want a current connection that is re-established across certain events (such as loosing signal) but erased when certain other events occur (power cycle)? So it's really semi-persistent with some definition for what type of event causes loss of persistence? Boot? Reset? Power-cycle? Which do and which don't?
  
  

:-D

I'm not so sure about the save() call. I would like to use Espruino without wires, also for development. That means I need to store the wifi settings persistently and unaffected by whatever latest sketch I may have loaded. If I have to save() and that changes the wifi settings, then I have to be careful to have all this wifi init boilerplate in every sketch? That's not very appealing, is it?

There is already some code in the esp8266 target, I have not looked at it more closely though. See https://github.com/espruino/Espruino/blo­b/master/targets/esp8266/telnet_client.c­

Sounds like there need to be a couple of simple config options around what to do on reset/reboot 'cause I would definitely want it to always reconnect and you seem to want something different. I think I can cook a proposal up...

For the connection at boot it might be handy to have a onInitialConnect callback that can be used to trigger stuff when a connection is first established after a restart/reset. This would be different from a onStateChange callback that is called everytime something happens and makes more sense to display status or so.

Where can I find information about what the various jsh time functions are intended to do? E.g. jshGetSystemTime, jshSetSystemTime, jshGetMillisecondsFromTime, jshGetTimeFromMilliseconds
Specifically:

• why are jshGetMillisecondsFromTime and jshGetTimeFromMilliseconds hardware dependent? It seems they just multiply/divide by 1000
  
• is GetSystemTime supposed to be a RTC or just a us counter form boot? Is it to keep actual time-of-day in the end or to measure elapsed us, ms, or sec between events?
  
• what is the purpose of jshSetSystemTime?
  Thanks!
  

Thanks for mentioning the FAT32 filesystem. I'll look at it.

I had to write the read-alignment code, but it's done now and works :-)

I looked through the various libraries linked off the wiki page. What strikes me is that other than the particle.io one none handle the fact that wifi can come up automatically at power-up. They all seem to think that the JS code needs to drive the wifi activity when I think that that's not a good idea for several reasons.

The first is power. In the case of the esp8266 the SDK can initiate a connection before Espruino even starts to run. Depending on the state is was in (e.g. sleep) it shouldn't have to get a fresh association.

The second is that things do get complicated quickly. For example, do you really want the logic to handle state transitions and to retry to connect if the AP is lost in JS? That quickly adds up to quite some code.

Or if power-save sleep results is the loss of a connection, do you want to code the logic to receive a callback and then reconnect in JS?

I would much prefer an interface that prescribes the desired state and that lets some lower device dependent code make it happen and "keep it so" even through restarts. So instead of "connect" I would prefer a "station" call that makes Espruino a station on the specified network (the params are mostly the same). Similarly an "access_point" call that makes Espruino an AP.

How is that different? The "station" call might take some parameters to control how aggressively to reconnect when the AP is lost but the biggest difference is in the semantics. In one case the effect of a call is persistent, in the other it's not.

Maybe this can be implemented in layers so a lower layer with the primitives is available as well, but that does add code and complexity.

FYI, I started a wiki page for esp8266 design notes: https://github.com/espruino/Espruino/wik­i/ESP8266-Design-Notes

Oops, scratch that comment. I now see that flash is read and written one byte at a time when called from JS!? Killer...

The reason this is an issue is that flash is memory-mapped in the esp8266 because it executes most of the code directly from flash (there's a 32KB instruction cache). When reading or writing arbitrary cache locations the SDK first has to disable the memory mapping, then perform the SPI transactions, then re-enable the mapping. So there's quite some overhead. It may or may not matter for small stuff, like a few KB, but this would most likely not be a good interface to do the firmware upgrade through.

In the context of the esp8266 port, I'm wondering about flash read and write alignment. jswrap_flash_write documents and enforces 4-byte alignment, which is great: https://github.com/espruino/Espruino/blo­b/master/src/jswrap_flash.c#L88-L122 But jswrap_flash_read doesn't (and the comment talks about writing https://github.com/espruino/Espruino/blo­b/master/src/jswrap_flash.c#L132). Are unaligned reads necessary? (Yes, it does complicate the implementation.)