Search results for:

Im not sure what limitations you are referring to?

I2c, onewire and spi work fine. Pwm is not supported in hardware, so is done in software.

Here is an example of spi driving a Nokia display:

http://forum.espruino.com/conversations/287196/#comment13070259

The limitation with the board really is lack of ram - this limits your code size.

What is it you intend to do?

I know that waiting for a response from the team does keep one patiently waiting, I thought I'd pass along some tid-bits in the mean time.
Please be aware that the official espruino boards are supported by @Gordon

Ports to other boards such as the esp8266 are supported under open source software - I.e people volunteering their time, so replies might be instantaneous! Sorry if this reads as harsh - it's not intended to be!

The esp8266 is a chip, and various different modules are available that may on may not have the LED.

There is a module called nodemcu that maps the PIN numbers on the nodemcu board to gpio numbers, so that might be useful for you. The flash button is always wired to the same gpio in, so you can use that for testing. This is what is checked on power up to put the chip into flashing mode, so when the board is running you can check the button state.

Here is an example with a button and a led, and also reading a temperature sensor, so just remove that part of the code:

http://forum.espruino.com/conversations/282721/#comment12822865

Is this first time after a fresh flash, or after a save()
?

Yes - I don't understand why the OR is used, if the hardware is getting read - then that would be sufficient I would have thought?

@Gordon

JshPinState jshPinGetState(Pin pin) {
  if (GPIO_REG_READ(GPIO_OUT_W1TS_ADDRESS, 1<<pin))
    return g_pinState[pin]|JSHPINSTATE_PIN_IS_ON;
  return g_pinState[pin];
}

If the hardware is getting read - is there any point in using the g_pinState[pin] array?

And I don't follow why the OR is used?

Thanks

Well that's good then, so can this be set back to be the default?

I wonder if when @tve removed if the release=1 flag was off?

Is this with crypto and graphics enabled in the Makefile?

The reason it was removed is that it did not fit and the rom space was overflowing. @MaBe - it might be worth seeing if the graphics module fits within the current build I'm not sure how much space it was short on.

Please post your code

@Gordon. For the esp the pin state is saved in array - so that could be used for the toggle.

https://github.com/espruino/Espruino/blob/master/targets/esp8266/jshardware.c#L420

This might just work out of box:

JshPinState jshPinGetState(Pin pin) {
  //os_printf("> ESP8266: jshPinGetState %d\n", pin);
  return g_pinState[pin];
}

@JumJum

Once this is up on github, we can take a look and also add it to the esp32 port - or a least document as a todo.

Sorry no hibernate or power management on the pi.

The sd card is creally the bottle neck. The way pi boots is quite odd, the gpu reads data from thef first fat partition on the disc, loads that into memory, and then hands that over to the arm CPU which then boots and reads the Linux paritition. For a minimized Linux, the kernel boot file is about 200mb.

What is the URL for the online version of the web ide?

Perhaps this could be added as one of the bookmarks?

I think the graphics module was removed from recent esp8266 builds as the firmware got too large to fit.

@MaBe might have a recent build with graphics defined.

I have spent quite a bit of time getting a pi to fastboot.

You can use buildroot or yocto to build a custom kernel. I think I had a buildroot version booting in about 4 secs, and the wifi network would be up in about 10 secs - compared to 30-45 secs on the normal pi Distro.

It is a lot of work to do a custom kernel - not for the faint hearted!
There are a few minimal pi installs that could be a starting point for you.

Have you tried to flash it?

What issue are you having?

@JumJum

There is also the sigma - delta -API :

http://esp-idf.readthedocs.io/en/latest/api/sigmadelta.html

This might be easier to implement Rather than the led API:

http://esp-idf.readthedocs.io/en/latest/api/ledc.html

As well as pwm there are 2 8 bit DAC available

No, it's a work in progress. And given that I don't have a carrier for an sdk card and only a breadboard I would heave to cobble the hardware together, making another possible failer point !

Thanks - it looks like a Gordon has merged the changes on github.

I'm currently working with @jumjum porting espruino to the esp32, which has much more resources. I'm looking at integrating the i2c and spi libs at present, so this work you have done with sd cards will be useful. There is a native virtual file system with the esp-idf, however the espruino implemention should sit on top of the spi code and just work.

Thanks. I saw the pull request on github.

Some of the esp memory reads need to be on four byte boundaries, so perhaps this is what is going on?

Did you try on a later version of the library, it looks like it is up to version 13, rather than 10c?

I have cut and paste code from examples and then saved on the phone in notepad.

Then you can cut and paste lines, into the Nordic app, and execute them on the puck.

If you leave a carriage return between the statements, they are easier to cut and paste.

Try another USB port. It might be that the port your using can't supply enough power and the chip is browning out.

@hartmut

So you had to update the espruino source with the updated fs library?

Is this on github, it would be great to do a pull request so this can be brought back into the project!

Upload your code via the ide, and test. Then you can use a command line tool to save the save area of eprom to a file - which board are you using as the method would be different for each board.

Also - the saved code might not work on a new version of the firmware, as the addresses of functions can change - so any oninit() might not work correctly with an updated firmware.