Damn, I was working along the examples, then deleted my imp from the planner view, and havent been able to get it back
Cycling power on the imp, and I get a 3 slow green, then about 12 fast red flashes. Tried to reblink it, but no benefit.
It was working fine before. I’ve tried my other wifi devices, and they can get out to net. I power cycled the router, but no help. The router is an ATT U-Verse wifi router.
(I logged out of e-imp site and back in, no avail).
power cycled my imp lots of times. I have the Sparkfun impee board. It was just working, so something changed.
Here is a video of what I see when i power it up and try to Blinkup it. Its hard to differentiate the colors, but its a 3 slow gree, 11 or 12 fast red pattern.
That’s not a specific flash code; it’s the “connected to server” slow green, followed by fast red indicating connection down. This is usually seen when there’s a firmware issue in your code causing the VM to crash and reload itself, but I believe there’s a different upset in your case.
Looking at it now but might not get much movement until tomorrow. Reassigning the imp to the default imp.unboundsq and leaving it connected (well, cycling) would be useful for us to catch the misbehavior, if possible.
Thanks Hugo. Ok, I did copy&paste the imp.unboundsq code into mine and power cycled and now its coming up and showing up in planner. So it must have been going into some bad state that then didn’t allow it to register with planner(?), so I couldnt see it on the UI.
Does it make sense then to change the firmware such the device can autodetect that he is VM crashing after a certain number of attempts and then running some other im.unboundsq-default code that would then server.log() a message indicating what it did so at least it then starts to show up on planner? For instance, if I had lots of code files, I might not have remembered which one to update to copy and paste the imp.unboundsq into to force it out of that mode. Or, perhaps an override in planner, to force a default imp.clean firmware load when it next boots?
Yep, those are good suggestions; in development you generally want something that’s crashing to stop so you can debug it, but in production you usually want it to reboot (it may be that the code path with the error is rarely called).
We have planner changes which improve the development experience significantly in the works, but the priority right now is the backend.
Thanks Hugo. Looking forward to the planner updates, perhaps even a debugger? with breakpoints so you can stop and look at data values?
Ive been a fan of eimp since I spotted you guys at MakerFaire and am expecting big things from this. Way to go on a great idea and great execution on this.
The next update should have line numbers for errors… baby steps! We have the capability of a single-step debugger but there’s quite a lot of work to do to enable that.
Does it make sense to evaluate the program before it gets downloaded for errors? I realize that there are run time errors that can’t be checked, but it could be checked for static syntax and things like using initialized variables. OTOH, that imposes extra work on web page code editor to then highlight the lines on which its having an issue. if so, maybe add a button for “static code verify”?
The code is obviously compiled locally (and you’re notified of errors at that point), but static analysis is something that is on our list but didn’t come “for free” with the squirrel compiler hence isn’t in there at the start.