• Hi Guys

    Just wanted to know if there is a port that exists for running Espruino on RTL8195/8711 chipsets. I have experience running espruino on nrf52/nucleo boards and recently also ported the chnages to the RAK itracker module along with full support for on board sensors

    https://github.com/narioinc/Espruino/tre­e/itracker_dev

    If no such port exists for the REALTEK chipsets, can someone guide me as on how to get a basic port functioning. any suggestion would be welcome and i would be glad to contribute back to the community

  • I don't believe there is a port, no.

    There's a bit of info on porting in the github repo's readme at https://github.com/espruino/Espruino and you could use the other ports as references - there are now a bunch of ARM-based ports.

    Getting it running to blink lights is probably not too bad, but I imagine your big challenge will be getting the WiFi working, since that'll probably involve pulling in quite a lot of RTL-specific libraries. For instance there was a port to the EMW3165, but the actual WiFi support was never actually done.

  • Hi Gordon

    Thanks for the quick reply. Seems like a nice challenge for me :) will keep the forum posted on the developments. I do agree that the real uphill task would be the wifi as the normal GPIO inits and drivers would be fairly straight forward. Lets see what I can make of it. There is a fair bit of community around the REALTEK Ameba boards. Maybe I can ask them for a collab on the board :)

    Regards,m
    Naresh

  • @Gordon

    Also have been working on Espruino port to the RAK itracker module by RAK wireless. Got all the sensors working and waiting for confirming the working of the NB IoT and GPS module as well.

    I am pushing my changes here:
    https://github.com/narioinc/Espruino/tre­e/itracker_dev

    Also in works is a Espruino port on a BLE+LoRa module again from RAK

    But would really love to send these changes upstream. Will need sometime to do a self code review to keep the code in line with the code quality in the main repo. Will push my changes soon !! :)

  • There might be some interesting info on porting to ARM in this thread: http://forum.espruino.com/conversations/­310219/

    However I'm not merging third party modules in to the main code. It just makes a lot more work for me if something in the build needs changing and I think I'm right in saying that every single contributed board other than ESP8266 and ESP32 has been contributed and then totally left to rot.

    If RAK themselves are interested then they could pay for me to maintain builds for their boards - much like Ruuvitag and Seeed do (for the WIO) - but otherwise I'm afraid you'll have to maintain a fork.

    It's annoying, but I have to pay myself a salary and I can't afford to end up in a position where I'm working for free to help some other company sell their modules :(

  • Hi @Gordon

    Sure I understand the implications and the maintenance required when handling 3rd party code. It becomes tough to keep things in order with contributed code gets abandoned or when the project needs to undergo revamp/updates.

    I'll be maintaining the code for the itracker module here:
    https://github.com/narioinc/Espruino/tre­e/itracker_dev

    Nonetheless, I really appreciate your efforts with the Espruino project. Keep up the good work. I got to learn a lot from the project and wanted to give back what I had learnt to the community.

  • Thanks!

    If you've got non-board-specific improvements then it'd be great if you were able to issue a PR for them though.

    I noticed you'd pulled in some existing C drivers for the 2 sensors in the iTracker. When I've had to do stuff like that I've generally been using JS modules for the hardware (there is already one for the BME280), so I guess you might find it easier to do that for other ports (they won't be hardware-dependent - your existing drivers seem like they'll only work on nRF5x?).

    I do have some code that'll build JS files directly into the firmware in a way that doesn't eat RAM, so hopefully that'll make its way into normal Espruino at some point in the future.

  • Hi Gordon

    Thanks for looking into the code and also showing me the correct way of integrating sensors. Seems there are a plethora of sensor drivers available. I would definitely try and port my code to JS so that it uses your framework in the intended fashion.

    Yes as you might have seen, my code was very specific to nrf52, but after seeing the JS code i believe I can write the JS equivalents and push the sensor libs for the remaining sensors (LIS2MDL , LIS3DH, OPT3001). I am not a pro with JS (I am mostly into embedded Android, apps and J2EE in my day job) but it would be good excuse to learn JS :)

    Will keep the forum posted on the developments.

  • @Gordon

    So if i want the js drivers for the sensors to be onboard the firmware (as the nrf52 cannot 'require' the modules being a BLE chipset), in which folder should I place the js files ?

  • Thanks! I haven't pushed that code yet (it was part of another branch), but stay tuned - I'm in the process of supporting another board where I'll be doing exactly that. I'll let you know here when the code goes in early next week.

    In the mean time, it's actually a lot easier to develop JS modules anyway, since you can debug much more easily (eg, requesting the values from registers on the fly)

  • Awesome @Gordon !!!

    Will await your code push and the new board ;) This weekend would be a good time for me to go through some of the sensors driver you have authored and understand how to port my boards sensors. Since the sensors drivers aren't board specific, I can send a PR for those to the mainline project for your review.

  • That's be awesome, thanks!

    This is the form I'm writing most device drivers in now, if it helps: https://github.com/espruino/EspruinoDocs­/blob/master/devices/BH1745.js

    • Private C for constants
    • Private class for the device (some modules make the class public) with methods on prototype
    • Public 'connectX' functions - some modules have different connection types (I2C, SPI 3 wire/SPI 4 wire), so I pass in the read/write register functions as arguments to the constructor

    It seems to work pretty well for most stuff.

    Generally to develop, I either:

    • Use the Web IDE, add exports={} up the top, and develop with the library and test code in one file.
    • Use the Espruino command-line tool with -w to watch a file, then put the library in a modules directory.

    hope that helps!

  • Got it !!!

    I'll then use the BH1745.js driver as a reference to keep the code consistent and in-line with the standard followed across the Espruino drivers. Thanks for the debug suggestion @Gordon. Actually I was just about to ask you a better way to debug the drivers quickly :). Maybe you heard my mind's voice !!!

    i saw a sliughtly similar approach in the LIS2D12 driver and thought ill take up as reference for the accel and magnetometer on the iTracker module. the opt3001 driver should be fairly easy to port. I haven't yet got the revision 2.0 of the board which fixes some board errata according to RAK. Once I get the board ill test my drivers on that and then send the PR.

    Regards,
    Naresh K

  • @Gordon

    I had a word with the CEO of RAK Wireless and he seems interested in your proposal for a port maintenance for some of his boards. I am sharing his email id here:

    ken.yu at rakwireless dot com

    I am just a contributor for some of the projects using their boards. Hence I wanted you to have a direct contact with him regarding your proposal. My humble request to please do follow up with them as I feel its a good opportunity.

    I was not sure if you would be comfortable in sharing your official email id with me hence I am requesting you to share the same with Ken himself directly :)

    Thanks

    Regards
    Naresh K

  • That's great - thanks! I'll drop him an email!

  • There's a little error in BH1745.js var MEASUREMENT_TIMES = [ 160,320,640,1280,1560,5120 ]. 1560 should be 2560 i think.

  • Thanks! Yes, just fixed it in GitHub

  • Thanks @Gordon

    This is exactly what I wanted :).

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

Porting Espruino to RTL8195A/RTL8711AM AMEBA Devices (Ameba, RTLDuino)

Posted by Avatar for narioinc89 @narioinc89

Actions