• You can find EFEU here http://www.jumware.eu:88/efeu
    Its an online tool which supports you to create your own customized version of Espruino firmware.

    Please have in mind, it is beta.
    It will not be updated to changes in Espruino before July, may we see each other in Alberta during that time ;-)
    If you find problems, have ideas to make things better, or whatever, please use this forum for now.
    As soon as everything becomes more stable, we will find other ways.

  • That sound more than great, I'll try some custom firmware when I'll get some times. Excellent job, it's impressive!

  • I like the tool. Good idea and effort! This will be very useful for tailoring the firmware to individual needs, optimizing the build to fit those needs.

    What if I want to make a 'non-standard' board out of a standard one, eg, use MDBT42Q to make one that supports 3 SPI instead of just one (to take a random example ;-)
    Can we have a tab where the basic capabilities (eg number of SPI) can be selected?

    I like the menu pick and choose style (although I haven't tried to build one yet) and add your own extension. Can you replace modules with your own (eg jshardware.c)?

    Also, requiring a .md file with each submission (maybe could be deferred) would go a long way toward having extensions used by someone other than original author...

    (note: I had posted this on a different thread, but realized that it really belonged here..."

  • @TomWS, I guess your 3 SPI instead of just one is really just a random example, because the number of these peripherals is given by the hardware. Initially you could only have in Espruino the peripherals the particular chip supported - it is also called hardware spi (to stay with the example). Over time though @Gordon added the software SPI - and other peripherals as software peripherals. The added types of peripheral the poor ESP8266EX - ESP-8266 ESP-## branded boards/modules - did not have or not have enough of, such as Software I2C and Software Serial. But as we know they have some limitations, most in speed / timing, since all is handled by code in Espruino firmware... (see https://www.espruino.com/EspruinoESP8266¬≠#limitations).

  • @allObjects, my 'random comment' was tongue in cheek since I'm referring to the boards with nRF52832, which does have 3 hardware SPI Master ports and 3 hardware SPI Slave ports (via 3 shared resources), and I'm using those 3 hardware ports on my MDBT42Q board, it's not so random after all.

    It is true that boards that are fabricated without any additional GPIO pins, the availability of extra SPI ports is meaningless. But Pixl, MDBT42Q, and nRF52 Thingy, to name a few, are all capable of simultaneously supporting multiple hardware SPI ports.

  • Yup... after posting I was curious about the 'limitation of 1 HW SPI'... and the specs says: 3 HW SPIs.

  • @TomWS
    Replacing exisiting code like jshardware.c with other code from unknown source would open a possible backdoor for virus etc. @Gordon gave me some examples for that.
    Therefore the decision is to use c-sources from repositiory only. There we have a good chance to refuse dangerous code.
    Requiring a md file for each submission is my recommendation. But I would not make this mandatory. Feel free to write and add pull request for md file where you miss it. Good starting point is the JSON mapping for each class/function/... in c-code.

    @allObjects, thanks for your explanation. You brought it to the point as always.

    Any change like 3SPI would cause changes which are not easy to do, at least on my best knowledge. If it is a simple change only, I would recommend to add changes to Espruino repository itself.
    I've no idea, what MDBT42Q supports. This should be done by somebody with better skills

  • [@JumJum] ... Any change like 3 SPI would cause changes which are not easy to do...

    because Espruino has also the information about the pins that can be used with certain signals of the Hardware SPI.

    See the information about the multiplexers that define the hardware connectivity possibilities for timers/counters at http://www.espruino.com/STM32+Peripheral­s, a page about how Low-level STM32 Peripheral access works, and can be used to count signal changes on an input pin with timer/counter registers when the (Espruino JS) application software implementation with setWatch(...) is toooooooo slow / the pulses come to fast / frequency is too high.

    The multiplexers are like switchboards that 'connect' (Espruino firmware) program controlled thru these multiplexers the hardware pin with the hardware SPI register. The restriction comes that not all pins can connect to all hardware peripherals (registers).... and the differences are

  • My general take on this is: If you're modifying C source files or otherwise making big changes, you're more than capable of setting up a dev environment (which with 'Bash on Windows' or Linux is basically copy/pasting one command in a terminal). In fact trying to compile and debug your code using a web compiler would be amazingly slow, painful and frustrating, plus you'd waste loads of CPU time on @JumJum's server (which he's providing for free) doing hundreds of builds.

    On the other hand, if you want a custom build with some modules built-in, or you need to disable something and enable something else, EFEU is really nice to use and way faster than doing your own dev environment.

  • Looks great, but showing V2.01 not the latest V2.03x in the compile directoy. Is this settable somewhere or should we wait for EFEU to be updated?

  • Sorry, I just spend vacations in Alberta, wait for next month please.
    On long term, there will be an automatic update.
    There are some minor changes in 2 py files, which need to be pushed to github.
    Right now I've to these changes manually.
    Next step will be to blacklist jswrapper files, an idea brought up by Gordon.
    But once again, this will be next month.

  • Good news first,

    • efeu is updated to latest release and latest edge.
      Bad news,
    • its not done automatically
    • there are changes for ESP8266 in EspruinoBuild, but there is nothing new in provision.sh (?)
      @MaBe, could you please tell me, what to do ? Right now efeu uses v2.2.1
  • there are changes for ESP8266 in EspruinoBuild, but there is nothing new in provision.sh (?)

    All changes are in code and make files.

    Yes SDK 2.2.1 is ok

  • Thank you and fantastic! We will give it a bash.

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

EFEU (tool to customize your own firmware) online in beta

Posted by Avatar for JumJum @JumJum

Actions