Forum - MCS Electronics

 

FAQFAQ SearchSearch RegisterRegister Log inLog in

Output Files

 
Post new topic   Reply to topic    www.mcselec.com Forum Index -> BASCOM-AVR
View previous topic :: View next topic  
Author Message
rkumetz

Bascom Member



Joined: 23 Jan 2007
Posts: 165
Location: Vermont

usa.gif
PostPosted: Sun May 31, 2020 10:10 pm    Post subject: Output Files Reply with quote

I just realized that 10+ years of writing Bascom code has created quite a mass of RPT, DBG and OBJ files.

Given that whenever one makes the decision to delete 100's of MB's of files it is wise to think carefully
before hitting the <ENTER> key I am wondering if anyone can think of a reason to keep these instead
of assuming I can recreate them by recompiling?

Better to have everyone snicker at my question than to be kicking myself later, right?

:shock:

(BASCOM-AVR version : 2.0.8.2 )
Back to top
View user's profile
AdrianJ

Bascom Expert



Joined: 16 Jan 2006
Posts: 2472
Location: Queensland

australia.gif
PostPosted: Mon Jun 01, 2020 1:44 am    Post subject: Reply with quote

None of those are really directly useful without the source code, and IMHO you can delete them, assuming of course you still have the source !

I would even include the hex, eep and bin files in a real cleanup. Even though you can of course program a chip from them, working out which version they actually create can be tricky without a lot of documentation, and you may as well put that in the source code. On the other hand, they are quite small, so the disk space is probably barely worth recovering.

I used to archive them with the release, but in fact I found it was much better to archive the source in a version repository system.

_________________
Adrian Jansen
Computer language is a framework for creativity
Back to top
View user's profile Visit poster's website
Evert :-)

Bascom Expert



Joined: 18 Feb 2005
Posts: 2114

netherlands.gif
PostPosted: Mon Jun 01, 2020 12:11 pm    Post subject: Reply with quote

What's 100's of MB's these days.
I keep those files, why, because if you delete them you need them tomorrow Wink

Very rare case you need a copy of hardware with Bascom code compiled in for example 1.11.4.0
You know this works perfect because the already existing hardware works flawless for 19 years. Flashing the existing hex file and you are done.
Recompiling with a newer version of Bascom gives always problems, due changes in the last years you can't compile it on first try. A example of this is that in the past variable and function names could have the same name without a problem, now it's not allowed any more.
If the software is then compiled you need to go trough all the testing again, that's including all the exceptions etcetera, that's time consuming. For most application we develop timing is critical and you have to recheck that also again.

That's why I keep all the Bascom version from day 1 and all the files used and generated.
Wasting 100MB's disk is is nothing compared the effort you maybe have to do in the future.

Just my 2 cent's.

_________________
www.evertdekker.com Bascom code vault
Back to top
View user's profile Visit poster's website
albertsm

Administrator



Joined: 09 Apr 2004
Posts: 5070
Location: Holland

blank.gif
PostPosted: Tue Jun 02, 2020 9:48 am    Post subject: Reply with quote

when your project is finished and into production you should make a backup on CD and put the compiler (the setup and installation) the license key and the source and generated files.
this way you can make a quick change after 20 or 20 years. of course it requires testing but for a real simple change most of the tests can be skipped. (except when you launch a rocket)
new versions can behave different. for many reasons:
- there is a new function or statement and you used the same name(a rename can fix that)
- a bug is fixed but you depended on that bug.
- there is a new bug.
- variables you used are now system variables. renaming can fix that too.

but there are also reasons to use a new version. it is best if you plan that so there is no time pressure.
- there is support on the new version. old versions are not supported
- the new version has bugs fixed and maybe you was not even aware of the problem.
- the new version might have new functions that do part of the job simpler or better

in any case, these small files do not matter much. i would keep all files but most important :
- bin, rpt, cfg and obj and eep

from the obj you could recreate the bin and hex and you can convert bin to hex.

my first HD was 5 MB. Yes mega byte. but now there is a NAS with 4TB mirrored disks. so these few MB do not matter much. IMO it is best to safe the old setup files. and lib files if you made them yourself.

_________________
Mark
Back to top
View user's profile Visit poster's website
Paulvk

Bascom Member



Joined: 28 Jul 2006
Posts: 1197
Location: SYDNEY

australia.gif
PostPosted: Tue Jun 02, 2020 10:43 am    Post subject: Reply with quote

Just look at how far we have come!
Software to fly to the moon back up!
Back to top
View user's profile
six1

Bascom Expert



Joined: 27 Feb 2009
Posts: 552

germany.gif
PostPosted: Tue Jun 02, 2020 10:49 am    Post subject: Reply with quote

Laughing
don't think so Paul...
Eagle and Apollo had a 4-Bit Calculation Unit and the Sourcecode will fit on a notice sheet of Paper Very Happy

_________________
For technical reasons, the signature is on the back of this message.
Back to top
View user's profile
Evert :-)

Bascom Expert



Joined: 18 Feb 2005
Posts: 2114

netherlands.gif
PostPosted: Tue Jun 02, 2020 11:36 am    Post subject: Reply with quote

On one sheet of paper I doubt it will fit.

Source code can be find on github: https://github.com/chrislgarry/Apollo-11

_________________
www.evertdekker.com Bascom code vault
Back to top
View user's profile Visit poster's website
laborratte

Bascom Expert



Joined: 27 Jul 2005
Posts: 262
Location: Berlin

germany.gif
PostPosted: Tue Jun 02, 2020 3:36 pm    Post subject: Reply with quote

No, six1, this is real. the photo shows Margaret Hamilton with the source code, she and her team created for the Apollo mission.

https://en.wikipedia.org/wiki/Margaret_Hamilton_(software_engineer)
Back to top
View user's profile
six1

Bascom Expert



Joined: 27 Feb 2009
Posts: 552

germany.gif
PostPosted: Wed Jun 03, 2020 6:05 am    Post subject: Reply with quote

yes you are all right... readed the story again...

The Block I version used 4,100 ICs, each containing a single three-input NOR gate
The computer had 2048 words of erasable magnetic-core memory and 36 kilowords of read-only core rope memory

Impressive facts...
But as i understood, only parts of Source are loaded into "AGC" to compute

_________________
For technical reasons, the signature is on the back of this message.
Back to top
View user's profile
MWS

Bascom Member



Joined: 22 Aug 2009
Posts: 1827

blank.gif
PostPosted: Wed Jun 03, 2020 3:33 pm    Post subject: Re: Output Files Reply with quote

rkumetz wrote:
I am wondering if anyone can think of a reason to keep these instead
of assuming I can recreate them by recompiling?

It may be a seldom occasion, but consider a source was compiled with an pretty old version of Bascom, ran perfectly for years, but needs reflashing.
Old Bascom version is picky to run on Winx900 and new version compiles slightly different.
You'll be happy to still have the old hex-file then.

Just compressed a lot I have here, zips from 32Meg to slightly 3Megs, thus ratio 10.
Quote:
to delete 100's of MB's

translates then to a zip-file 10's of MB's big.
Which is nothing at all in times where USB sticks of up to two Terra-bytes are available.
Back to top
View user's profile
rkumetz

Bascom Member



Joined: 23 Jan 2007
Posts: 165
Location: Vermont

usa.gif
PostPosted: Fri Jun 12, 2020 11:25 pm    Post subject: Reply with quote

AdrianJ wrote:
None of those are really directly useful without the source code, and IMHO you can delete them, assuming of course you still have the source !

I would even include the hex, eep and bin files in a real cleanup. Even though you can of course program a chip from them, working out which version they actually create can be tricky without a lot of documentation, and you may as well put that in the source code. On the other hand, they are quite small, so the disk space is probably barely worth recovering.

I used to archive them with the release, but in fact I found it was much better to archive the source in a version repository system.



I do create archives and have a large fireproof waterproof box full of weekly backup DVDs as well as project specific archives.

I keep all of the hex files because if I need to recreate a problem it is much easier to just program a board than to have to recreate it from the source.
By doing that I also avoid making a mistake where I edit the source and forget to give it a new file name.

Thanks!
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    www.mcselec.com Forum Index -> BASCOM-AVR All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum