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

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+Peripherals, 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.

EFEU is, or will be soon, offline.
My server needs an update, and it will take some time to get it running again.
It is connected to an update of my contract.
Usually in a case like this, you've to expect unexpected problems ;-)
Right now, to give an example, 2 server instances are fighting for one domain name.

Thanks for putting in the work to keep it running after the update...

Do you have an idea how many uses it gets?

I've no log for that.
There is an indirect indicator. I get a message if Versions in EFEU and Git repository don't match. This is checked on each start of EFEU.
Depending on that my guess is 3 to 10 a month.
Feedback from users is close to zero.
Mainly, I use it for my own testing.

If I had more time to work on my own projects, I would be using the hell out of that, heh... It's a really awesome tool. We gotta get more people using Espruino! Quite honestly, I think Espruino would be an amazing "my first hobby electronics platform" - the live console was just amazing when I was getting into electronics. I might well not have stuck with electronics long enough for it to get really fun, had I started with Arduino instead of Espruino - and that would have sucked, because I love electronics now.

It's kind of a pain to build Espruino firmware myself, since I don't have a convenient linux machine in my apartment, so I have to ssh into a linux machine (I use one on AWS, as that's less work than sorting out my home linux machine so it's not such a pain in the arse to use)

If you use windows, try WSL + VS Code with the Remote WSL extension, works pretty good. Or even a full blown linux VM might be less hassle than SSH and copy from an AWS machine.
Or not, depends on you :)

EFEU tool appears not to be running at the moment. Are there any plans to reinstate it?

I needed to figure out how to create a custom build yesterday (for the first time) and noticed it was down also. I needed to remove/add some libs to MDBT42Q.

But what I found is that it is real easy to do these builds, @Gordon has made the process real easy to make the build process work at https://github.com/espruino/Espruino/blob/master/README_Building.md

Took me hour or so to create a custom MDBT42Q build without any prior knowledge - I just used the Ubuntu you can fire up in Windows.

Just for anyone who had not had a go at this.

Sorry, did not take care on EFEU for some time, since feedback was close to zero.
Will take a closer look soon, and do an update.