Search results for:

Yes, it's literally just g.setRotation(...)

The other option is the Sharp memory LCD. They're more expensive, but they are really nice. Huge viewing angle, good contrast and draw virtually no power.

https://www.adafruit.com/products/1393
http://www.espruino.com/MemoryLCD

The other interesting thing is I don't believe they need any external components, so if you were making a product you could literally just solder a connector onto a board and you're good to go - that would bring the cost down a huge amount.

But it is difficult to find a good replacement for those Nokia displays. If you can find out where to source the displays the Digole boards use I'm sure Espruino could be made to drive them directly. I'm interested in getting a reliable source of cheap low-power displays too, so if you found something I'd happily write the drivers.

Could it be that the MQTT module itself just times out?

I haven't personally done it, but something like this should work fine:

include "jswrap_interactive.h"

void doStuff() {
}

JsVar *func = jsvNewNativeFunction(doStuff, JSWAT_VOID);
jsvUnLock(jswrap_interface_setTimeout(fu­nc, 1000/*ms*/, 0));
jsvUnLock(func);

Great, thanks!

Why is the timeout needed? Is there some kind of error from mqtt.connect? The network layer should delay any transmission/reception until after the connection has been made.

... This is actually something that needs sorting generally - Espruino calls the 'connected' callback before the connection has actually been made (the current internal API for networking wasn't really meant for non-blocking connections).

Looks good - my vote would be on the first one to keep it a bit smaller.

What about just putting the silkscreen on the rear of the board? There shouldn't be much on there apart from tracks, and then you can put the pins right near the edges.

Yes, potentially you could use FreeRTOS or something similar. Almost immediately you'll have people asking why they can't use USB devices on it though :)

Best bet would be to compile a linux kernel with the realtime options set - although if Espruino could use a hardware timer on the Pi, it might be a realtime kernel isn't needed at all.

I just pushed a branch for E.memoryArea - I'm not sure yet how it affects execution performance, there's a slim chance it's actually an improvement.

However, you should be able to store stuff in Flash and then use myStr = E.memoryArea(addr, len) to get a string that references it

That's a great idea! Yes, a PR for that would be great.

In terms of flash memory, what's covered here would actually sort that out in a more general kind of way, so I think we should do that first.

I guess another cool option would be to allow a function to be specified. It would then be called and whatever it returned would be used.

Thanks! I don't think it's really highjacking the thread much :) Support for all types of Pi would be a major bonus for the Linux-based release.

though I must admit I do not find my rpi model Bs fast enough to use for Arduino development

I think with Espruino it'd be pretty speedy. After all, all the work gets done in the web browser, which would be running on a proper PC :)

I think the rpi has demonstrated that it is not necessary to "hide" linux to make the system attractive.

True, but if I'm honest I think the real thing that has 'launched' the Pi is the massive community around it. You can just google what you want to do and then copy/paste the commands :)

... also quite a lot of people use the GUI! :)

Carambola existed some time before the Pi (I think?), was cheaper and had Flash, WiFi and Ethernet on board, but I think it failed to become popular mainly because of the way people were thrown headfirst into Linux.

Somehow the Pi just got it right...

Well, Espruino has supported SD cards on arbitrary pins for almost a year now - but as far as I know nobody has posted up any code to use this module.

Ad @DrAzzy said initially, it looks quite easy though - you just have to send the right stuff over SPI to set it up (which you could steal from Adafruit's library) and then you just read chunks of data off the SD card and write them down SPI - it's really only a few lines of code.

We can't write the module for you as we don't have one of those decoders here, but we can definitely lend a hand if you need any help.

Nope, I can reproduce here. I'm really struggling to see why this is happening!

Ok, so you'll need to do:

include "jswrap_modules.h" // for jswrap_require

/*JSON{
    "type": "library",
    "class" : "foo"
}*/

static JsVar *getFooModule() {
  JsVar *moduleName = jsvNewFromString("foo");
  JsVar *m = jswrap_require(moduleName);
  jsvUnLock(moduleName);
  return m;
}

/*JSON{
    "type" : "staticmethod",
    "class" : "foo",
    "name" : "bar",
    "generate" : "jswrap_foo_bar"
}*/
void jswrap_foo_bar() {
  JsVar *module = getFooModule();
  if (!module) return; // out of memory?
  jsiQueueObjectCallbacks(module, "#onbob", NULL, 0);
  jsvUnLock(module);
}

and then this works:

>require("foo").on("bob",function() { print('Hello'); });
=undefined
>require("foo").bar()  
=undefined
Hello

It's a bit nasty. With the prototype chain branch I'm hoping to tidy it up so you'll be able to do:

/*JSON{
    "type" : "method", // <----- changed
    "class" : "foo",
    "name" : "bar",
    "generate" : "jswrap_foo_bar"
}*/
void jswrap_foo_bar(JsVar *module) {
  jsiQueueObjectCallbacks(module, "#onbob", NULL, 0);
}

But right now I think the safest method is above, and should be easy enough to tweak later on.

Some people (Pimonori?) were selling at the £4/$5 price before they ran out.

I wonder if there's any profit margin in there, but I think some companies will be willing to sell almost at cost because people do generally spend extra when they buy something like that.

I do wonder about this focus on ultra-cheap boards though. I'm not sure this race to the bottom is really that helpful in the long run...

Yeah, I'll look today. Ended up quite bust yesterday trying to catch up after the weekend.

what's the advantage over node.js or BoneScript at that point?

It'd just be the digitalPulse and accurate pulse measurement with setWatch.

Also the way you could just point the Web IDE at the board's IP address, connect, and use all the existing Espruino hardware-centric stuff (in fact you could just serve the Web IDE off of the Pi).

Basically it'd be more beginner-friendly than node (IMO)

If I actually had any free time, I'd love to reimplement what we'd done at Altera, but as an online tool using JS. It'd be a lot easier given all the nice parsing and type inference tools there are now.

Sadly I don't have time, and Altera (being a US company) would probably sue the hell out of me if I did :)

Yes - sorry, I didn't mean to actually leave space on the board for the Pico, but to have pins in the right order. People could solder the Pico right on to those pins if they wanted, but it'd hang off the edge of the board.

Thanks - this seems like a really odd one. What error did you get?

I'm just wondering - could this have just been an issue with not doing a make clean?

... to add to this, there are a bunch of (probably more exciting) cheap OpenWRT Linux+WiFi modules out there. A firmware image for them that booted right up into Espruino would be really exciting too.

Espruino currently supports WiringPi so you get fast IO, and when running as sudo you get proper IRQs when a pin changes state! it's actually surprising how much hardware access you can get under Linux when running with root priviledges - you can peek and poke registers like you could on a proper microcontroller.

The thing it's lacking is a utility timer for accurate digitalPulse. As @tve says, this could be a kernel module (in fact that might not even be needed - we just need to find a spare timer peripheral on the Pi and I think we can do it all from user mode with root privileges).

From my point of view, trying to run on Pi without Linux is just crazy. There are millions (billions?) of lines of code in Linux, and you're basically reimplementing what others have done before, just worse.

You can compile the Linux kernel with a 'realtime' flag so you can get proper accurate timing out of it if needed.

IMO, a cut-down Linux disk image that'd run off a ~256MB card, and that booted straight up with Espruino could be really good - and would actually be pretty achievable. You'd get proper USB with WiFi, Ethernet support on the Model B, the dispay, and all that good stuff... and people using it could just jump right into JavaScript without having to worry about Linux.

Paletted code works more quickly, but only for changes on the whole screen. Really it's totally dependent on how fast you can get SPI working, whereas the other method often depends more on execution speed.

I recently added Graphics.getModified which could help with this by only updating the modified area, but it would need driver support.

Well, as far as I know browsers don't have a changeInterval so compliance probably isn't a big problem in this case.

That's great! Glad it works!

It's not the best solution, but hopefully as time goes on I'll be able to find ways of improving the memory usage.

It'd be interesting to see if that works on ESP8266, but it may not - the driver takes up quite a bit of memory, and it may end up being too much.

Thanks - yes, I'll have a think about this and will try and come up with an example...