Home  |  Contents 

Microcontroller and PC projects
  Forum Index : Microcontroller and PC projects         Section
Subject Topic: Saving space in the firmware Post ReplyPost New Topic
Page of 3 Next >>
Author
Message << Prev Topic | Next Topic >>
CaptainBoing
Guru
Guru
Avatar

Joined: 07 September 2016
Location: United Kingdom
Online Status: Offline
Posts: 687
Posted: 03 August 2018 at 11:37pm | IP Logged Quote CaptainBoing

bearing in mind the value RISC bought to the CPU market back in the 80s, it is important that a language concentrate on providing a really good core of "primitives"

Geoff has mentioned that for a long time that he is really pushed for space in the xx170 firmware for new developments, so I was wondering; what would you get rid of to free-up space?

There are a few functions that rarely get used and are easy to derive yourself if you need them. I would point the gun at:

Max() & Min() - two or three lines of code inside a function

Date$ & Time$ - replace with a single Now$ and use Left$/Right$ to extract the bits you want. This brings a few benefits elsewhere in your own code; date & time are often queried together, RTC SETTIME becomes easier and setting the date & time is a single action.

Would you consider these to be valid considerations for the MMBasic Lite (is it still supported?)

What are your own thoughts on the lite, cut down version - do you use it?



Edited by CaptainBoing on 03 August 2018 at 11:41pm



Back to Top View CaptainBoing's Profile Search for other posts by CaptainBoing
 
JohnS
Guru
Guru


Joined: 18 November 2011
Location: United Kingdom
Online Status: Offline
Posts: 1725
Posted: 04 August 2018 at 12:28am | IP Logged Quote JohnS

Some/most of those are very small so will save next to nothing.

Get the source and take a look. Better, build it and look at the MAP file to see how big each part is and then pick something big enough to save a decent amount of space.

Or just use a bigger chip :)

John

Back to Top View JohnS's Profile Search for other posts by JohnS
 
Geoffg
Guru
Guru
Avatar

Joined: 06 June 2011
Location: Australia
Online Status: Offline
Posts: 2446
Posted: 04 August 2018 at 7:08am | IP Logged Quote Geoffg

FYI Max() & Min() use 328 bytes.

The main problem is, what do you use the space saved by removing certain features? Most would like it to be used to implement some feature, but each person has their own favourite.

Quote:
What are your own thoughts on the lite, cut down version - do you use it?

I would also also be interested in the answers to that one.
Back to Top View Geoffg's Profile Search for other posts by Geoffg Visit Geoffg's Homepage
 
Grogster
Guru
Guru
Avatar

Joined: 31 December 2012
Location: New Zealand
Online Status: Online
Posts: 6306
Posted: 04 August 2018 at 8:20am | IP Logged Quote Grogster

The Lite version is perfect if you have a big code you need to run on the smaller MM's, but living without the editor? I think not.

The built-in editor is what makes the Micromite the Micromite, and without it, you are back to the Arduino or PICAXE method where you have to run the code and if there is any bug, you have to recompile and download again.

What I love about the built-in editor, is that if the program falls over with an error, you can enter the editor, fix it, confirm it is fixed, and then update the master code in MMEDIT - which I always have running at the same time. Very quick way to squish bugs in the MMBASIC code, and much faster then having to redownload the program each time it falls over while in debugging stage.

I would expect that unless Microchip release a new version of the 28's with more Flash and RAM, that the 170 PROBABLY won't get that many more new features, as I seem to recall reading that Geoff wanted to keep the little remaining space for bug fixes that may be needed. Correct me if I have got that wrong.

If you need more RAM and/or Flash, it's time to move up to the MM+/MMX series of chips. I guess they ARE SMD, and that might put some people off, but the Explore-64 was designed specifically to get around that issue, by having a breadboard-friendly module you can still use to experiment with, without needing to worry about soldering any SMD.

My 2c only, and I suddenly realise that I have digressed a little from the topic - sorry.

__________________
Smoke makes things work. When the smoke gets out, it stops!
Back to Top View Grogster's Profile Search for other posts by Grogster Visit Grogster's Homepage
 
CaptainBoing
Guru
Guru
Avatar

Joined: 07 September 2016
Location: United Kingdom
Online Status: Offline
Posts: 687
Posted: 04 August 2018 at 3:32pm | IP Logged Quote CaptainBoing

@Grogster: For me, I rarely use the editor for the reason you highlight and that different terminals seem to not always be fluent VT talkers and that the running code and the "writing" code get out of step. As soon as a bit of code gets beyond a few lines it ends up in an editor on my laptop with all the flexibility that brings.

My dev' cycle might seem a little convoluted but it works really well for me: everything is written and maintained in the editor (Notepad++) Ctrl-A, Ctrl-C, F10 on the Mite (via putty or USB Terminal), a right click to paste everything, Ctrl-Z and that is it. It is a fast cycle and I reduce field reliance to an editor and a terminal prog.

Getting rid of the editor on production projects was a great move and all my later production runs use the LiteMite.

Your point on MMX is well taken and larger projects certainly head down that route... cant get an MMX into a ceiling rose those. One of my little mite boards, HC-12 and a tiny mains PSU go in with room to spare for the SSR to control the light below (just).

"My 2c only, and I suddenly realise that I have digressed a little from the topic"

so?

Edited by CaptainBoing on 04 August 2018 at 3:40pm
Back to Top View CaptainBoing's Profile Search for other posts by CaptainBoing
 
CaptainBoing
Guru
Guru
Avatar

Joined: 07 September 2016
Location: United Kingdom
Online Status: Offline
Posts: 687
Posted: 04 August 2018 at 3:46pm | IP Logged Quote CaptainBoing

Geoffg wrote:
FYI Max() & Min() use 328 bytes.


Yeah they were never going to be huge, I was just trying to grab a couple of little-used things off the top of my head as examples of getting rid of things that can be built easily enough using base statements/functions.

In truth I hate to see anything of a language itself being sacrificed. Specialized functions built in to service a specific piece of hardware or an obscure function are better served by a good library so the programmer can choose what he wants in the code - which is why I like the way LiteMite has gone.

Edited by CaptainBoing on 04 August 2018 at 3:51pm
Back to Top View CaptainBoing's Profile Search for other posts by CaptainBoing
 
GoodToGo!
Senior Member
Senior Member
Avatar

Joined: 23 April 2017
Location: Australia
Online Status: Offline
Posts: 166
Posted: 04 August 2018 at 4:07pm | IP Logged Quote GoodToGo!

Gotta say, Iíve never used the editor, I use either MMedit and, to a lesser extent, Notepad++. At this time my progs arenít big enough to fill a 170. I havenít used the lite firmware either, because I tend to use the Select Case, LCD and RTC commands pretty often.

Cheers!
GTG!

__________________
...... Don't worry mate, it'll be GoodToGo!
Back to Top View GoodToGo!'s Profile Search for other posts by GoodToGo!
 
lew247
Guru
Guru
Avatar

Joined: 23 December 2015
Location: United Kingdom
Online Status: Offline
Posts: 998
Posted: 04 August 2018 at 4:40pm | IP Logged Quote lew247

The now$ and extract date and time sounds ideal to me, it's dead simple to extract both
Back to Top View lew247's Profile Search for other posts by lew247
 
robert.rozee
Guru
Guru


Joined: 31 December 2012
Location: New Zealand
Online Status: Offline
Posts: 1315
Posted: 05 August 2018 at 2:00am | IP Logged Quote robert.rozee

a well timed thread...

a few days ago i was looking at the C source for the MEMORY command. geoff wrote a while back that this consumes around 3k of flash space, and i was interested in trying to figure out how to write a replacement in basic.

but then looking at the source, it occurred that cmd_memory (the function that does the work) in places duplicates stuff that is carried out elsewhere. for instance consider the section of code that sums the basic program held in flash:

// count the number of lines in the program
    p = ProgFlash;
[...]
    if(i && ProgramSize == 0) ProgramPercent = ProgramSize = 1;

this summing is also carried out as part of the functioning of SaveProgramToFlash (used by AUTOSAVE and the editor). if SaveProgramToFlash were to store the size of the number of lines and flash spaced used (stashed away in a couple of integers in flash), then there would be no need for cmd_memory to carry out the calculations.

i suspect the same principal may apply for saved variables, custom functions, and fonts. anything in RAM is changing dynamically, so would still need to be counted up every time MEMORY is called.


btw: did anything ever happen around getting rid of TRON and TROFF? i doubt if anyone would notice if they went. and TRACE On|Off could even be replaced with OPTION TRACE On|Off to save a token.


cheers,
rob :-)

Edited by robert.rozee on 05 August 2018 at 2:05am
Back to Top View robert.rozee's Profile Search for other posts by robert.rozee
 
Phil23
Guru
Guru


Joined: 27 March 2016
Location: Australia
Online Status: Offline
Posts: 1525
Posted: 05 August 2018 at 8:03pm | IP Logged Quote Phil23

My 2c on a Lite would be to dump all the "Special Device" support.

DS16B20's
Temp/Hum Sensor
Distance
Servos
Keypad
Text LCD
Graphic LCD
Maybe even RTC
Ö
Ö
Ö

Have them available as external's,
but keep the editor there as it is a valuable basic tool.

Pretty sure there would be very few implementations that would use all of the above.

But then again this may be a direction for Geoff that is more trouble than it is actually worth.

Basically if a 170 can't cut it, an E64 should do the job.


Cheers.

Phil.
Back to Top View Phil23's Profile Search for other posts by Phil23
 
robert.rozee
Guru
Guru


Joined: 31 December 2012
Location: New Zealand
Online Status: Offline
Posts: 1315
Posted: 05 August 2018 at 9:21pm | IP Logged Quote robert.rozee

i believe DISTANCE has already gone that way, becoming a c-function. my suspicion that the decision was helped along by the HC-SR04 and similar boards provided quite 'variable' performance for many users!

the same has happened with the HUMID command, that makes use of DHT22 sensors. like many humidity sensors, these often seem to work for a while (6 months or more) before packing up due to contamination from the atmosphere. this makes for a less-than-happy user experience.

a while ago geoff mentioned in a forum post that one key point for an inbuilt function is that it be something that can not easilly be otherwise accomplished in basic. going beyond this, one of the 'selling points' of the micromite, from the start, has been a simple out-of-the-box experience for the beginner. as such, support for certain 'core' devices was built in by geoff: DS18B20, keypad, HD44780-based LCD modules, servos. all these were cheap peripherals, that could easily be hooked up on a breadboard, and then accessed with just a few basic statements.


now, i must confess that i have always thought support for colour LCDs should be via c-functions. but having said this, a great many forum members do seem to use colour LCD modules with touchscreens in many projects.


cheers,
rob :-)
Back to Top View robert.rozee's Profile Search for other posts by robert.rozee
 
Azure
Guru
Guru
Avatar

Joined: 09 November 2017
Location: Australia
Online Status: Offline
Posts: 446
Posted: 05 August 2018 at 11:17pm | IP Logged Quote Azure

Silly question (maybe) how much slower is using a CFunction than having it built-in to MMbasic.

If the difference is minimal then one way would be to build a library of CFunctions (that have been removed from internal) and you just include the ones you want. This is already being done with some functions.

I agree it is not ideal as it adds more steps for the beginner but at the same time it adds a lot of flexibility for new options.

Could be written up (as a suggested way) to load the one that are wanted during the initial board setup and then save them to the library. Then they are there until the library is cleared.

Just a thought that might create useful discussion for Geoff to consider.

Edited by Azure on 05 August 2018 at 11:18pm
Back to Top View Azure's Profile Search for other posts by Azure
 


Page of 3 Next >>
In the news...
 
Post ReplyPost New Topic
Printable version Printable version
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot delete your posts in this forum
You cannot edit your posts in this forum
You cannot create polls in this forum
You cannot vote in polls in this forum

Powered by Web Wiz Forums version 7.8
Copyright ©2001-2004 Web Wiz Guide

This page was generated in 0.1445 seconds.
Privacy Policy     Process times : 0.02, 0, 0, 0.12