NewBee New feature request

Posted on
  • @Gordon
    Let us say that once you debugged your application code that in a few years
    you need to upgrade the firmware and reload the user application. You already
    know the serial number of the Espruino, what firmware it has but not the name
    of the file name you downloaded last in the Espruino. Could you add or spare some extra bytes
    so a person can tell what source code filename was downloaded last in the Espruino?
    By using the WEB IDE all the board information would be displayed including the source file name.

  • We've got the git commit in process.env.

    I'm not really sure what the use case would be for including the file name of the firmware update? Unless the issue is that process.env doesn't tell you about build options (for example, wiznet vs cc3k)...?

  • I'm not really sure what the use case would be for including the file
    name of the firmware update?

    No, I think you misunderstood, its the "user application file-name"

    Have it so that the user provides a file-name in text and have it saved in the Espruino.
    Then in a few years, the user looks at the Espruino and knows what source code file-name
    he used to download his application user code in the Espruino. Very cool indeed.

    Of course, a user can just insert a SD transflash card, with the source code, and leave it in the Espruino.

  • Could you not just write:

    FILENAME="foo_1v01.js";
    

    Up the top of your file? You can then just log in and type FILENAME and it'll tell you. I know you have to keep updating it when you save to a new filename, but it's not too bad.

    I want to avoid taking up memory using things that 1 person in 100 will use - there's just so little available :(

    I guess one good way of handling this would be to add preprocessor-style predefined variables - for instance __FILE__ and __TIME__ - then it's just a matter of adding FILENAME=__FILE__; to the top of your file. Time especially would be pretty cool, as it'd let you automatically set up the internal RTC every time you uploaded code.

    Only thing you have to watch out for is because the Web IDE is a Web App, it doesn't have access to your filesystem - so I don't believe it knows the full path of the file, only the filename itself.

  • Using the file name var with text is so simple yet it will do the job.

    Indirectly, I am paying Pur3, the highest compliment by saying the Espruino would even be around in a few years. The microcontroller landscape is riddled with so many inferior microcontrollers that having a useful and well supported one is a major accomplishment. Now if only you could find a way to increase the memory 2x or more for the power users like me.

  • Well, you can increase the memory of an Espruino right now if you're able to get the chip off the board and replace it with a higher spec'ed pin-compatible one (ex, STM32F103RFT6). Getting the chip off while leaving the board intact is probably harder than putting the new one on (should be possible to drag solder that)

    Someone with access to rework facilities did this: http://forum.espruino.com/conversations/­842/

  • @DRAzzy -Why not just use this pin compatible chip and manufacturer the Espruino with it and be done with it? $3-$5 extra I would gladly pay for to have more memory capabilities.

  • I'm with you on that... I was not posting that as a serious suggestion. Even 64k of ram really isn't enough to take advantage of the other capabilities of the hardware. While that beautiful STM32 chip is capable of much more complex and innovative projects than an Arduino, we're hamstrung by the memory limit, and it's difficult to realize those projects. Because we have to store our code as text in RAM, as opposed to compiled code in flash, Espruino needs a lot more RAM.... (and since the firmware has to contain all the libraries for FS/network/etc, 256k of flash is also insufficient. Imagine if we had 512k - we wouldn't need separate versions for different network adapters, and we'd have plenty of room for the firmware to grow in the future).

    Gordon was talking about offering a version with a higher spec chip, but I think his focus is on the Espruini now... At least that comes with 64k of ram, so you don't need to step beyond the spec sheet to get your 3250 jsvars (and the chip has fewer pins, so the storage seems to better match the "size" of the project that it's appropriate for - and it's cheaper).

    I look longingly at the STM Discovery boards, and dream of the freedom of having over 10k jsvars. It would be paradise! But they don't have the bootloader, and aren't really supported, and so have all manner of issues.

    But I've said all this before.

  • There's been some talk about this before, and I will do the bigger chipped board at some point. It's only very recently that I've got the rev 1v4 of the existing board produced and CE tested though.

    Right now I'm not selling enough boards that it's a huge priority I'm afraid. There's actually quite a bit of effort involved in targeting the bigger chip properly (eg. modified bootloader, new image and support files for the Web IDE), and I'd be amazingly lucky to sell 100 of the bigger board in the next year so I doubt it'd really pay for the work I'd have to put in.

    You almost got a bigger board for the KickStarter, but cost wasn't the issue - it was the lead time. The RCT6 is a very common chip which means that there's a lot of stock around. Getting one of the higher spec ones would have meant a >12 week lead time, which would have meant we'd have totally missed the shipping target and annoyed everyone.

    On the new, small Espruino board the chip is newer and not as common, so I've got to expect the lead time issues. Depending how things go it might mean I'd be able to go for a higher spec chip when I order.

  • I'd be amazingly lucky to sell 100 of the bigger board in the next
    year so I doubt it'd really pay for the work I'd have to put in.

    Wow ... I thought there would be many more Espruino power users other than me and DrAzzy!

  • IMO, once there's an Espruini, there's not much reason to continue producing Espruino boards with the low-spec chip on them; I'd get the biggest chip I could without to much re-designing, raise the price accordingly - and if people want the low-cost board, they get an Espruini, whereas if they want serious capability, they get an Espruino, and it has the bigger board, that awesome prototyping area (I ignored it at first, but the more I use the Espruino, the more potential I see in it - If I were designing it, I'd say "screw bluetooth" and replace the bluetooth pads with a set of SMD pads matching the top, only at the TSSOP pitch)

  • Yes, it's a good point. Once there's the mini board it does make more sense to beef up the original Espruino one.

    @user7114 you can still get a lot done with what's there already. If you're hitting memory issues maybe post up some of your code in another thread? There's usually some quite simple stuff you can do that really decreases memory usage.

  • If you're hitting memory issues maybe post up some of your code in
    another thread? There's usually some quite simple stuff you can do
    that really decreases memory usage.

    I consider myself as an "Espruino power user" which takes the JavaScript Espruino to the maximum of resources. You can never have enough memory for your Espruino. (JSVARS). Through creative software algorithms, minification, and newer Espruino revisions, I just barely fit the code into the Espruino without "out of memory" problems. When you have the high level JavaScript microcontroller like the Espruino, you are able to do much more and in doing so will deplete memory resources rather quickly. BigRam was installed, for more JSVARS memory, only after it worked consistently in our application.

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

NewBee New feature request

Posted by Avatar for user7114 @user7114

Actions