Guys, thanks for the hangout. I did have a couple of questions, but am not a twitter user (did sign up over the course of the hangout, but not fast enough to post anything). Would appreciate it if you could reenable the chat for the hangout next time.
Particularly impressed with Aron’s USB host. Will mention that to the team to see if we can dream up applications for it. The USB Host highlights an existing problem we have with our imp apps.
We attach all sorts of things to our imps. Embedding drivers in the device code eats up the limited codespace in no time at all. Ideally, we’d like to download drivers for these things on the fly, but we can’t currently do that without the compilestring() feature in Squirrel. As a plan B, we download “drivers” to the device that are functions represented as Squirrel tables and arrays. It works, but it would be great if the device could detect what it needs and request drivers (as classes, singles functions or code containers) from the agent (or cloud).
Alternately, with the extra storage available on the imp003, it would then be possible to serialize functionality on the device in order to load it on demand.
Sorry for the lack of alternative Q&A/chat on this hangout, it wasn’t intentional.
We are managing the hangouts in a slightly different way than before, and new things are scary and hard! I’ll make sure we have it sorted out before the next one!
The compilestring() function ends up taking a LOT of resources and space on the imp, which is (one of the reasons) why we have not included it (it also opens the door for some serious security concerns).
I’ll point @aron at this post to thread to comment some more on the USB stuff
@controlCloud - hmm, that is frustrating that it didn’t how the coding part… looks like we still have some work to do on making these correctly.
There are actually two PubNub blog posts - the first is the one @MORA mentioned (which covers the basic PubNub library), the next is this one (which covers the MessageBus class):
Thanks @MORA! That was exactly the goal of the library. It doesn’t really add “new functionality” - it just makes existing things a lot simpler and cleaner
I had a lot of fun building the USB host code. I have a bit of a bruise on my forehead from bashing it against the wall a few too many times, but it got there in the end and is nice and stable if a little bit janky.
As promised I added the FTDI driver to the existing keyboard and mouse drivers. Any community feedback and improvements will be well received.
Finally got some time to play with these today, was a bit surprised that we need to include the pubnub code ourselves, but hopefully that just underlines the need for include tags even more, when official code cant be included.
The messagebus example works as advertised, theres a fairly low rate limit on pubnub though, and since the lib does not catch up on its own, maybe it would be a good idea to handle it locally as well, either as a queue, or just a variable to track how much rate is left, once the limit is hit messages are limited to 1 per second, and it seems random what is dropped, so it becomes non dependant.
Delay wise its pretty good, after a period of inactivity the delay is about half a second on the first action, after that around 100-200ms, which isnt bad considdering the event had to first go to EI servers, then pubnub and then back to the other device