Home
JAQForum Ver 20.06
Log In or Join  
Active Topics
Local Time 16:32 04 May 2024 Privacy Policy
Jump to

Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.

Forum Index : Microcontroller and PC projects : MicroMite feature request

Author Message
Chris Roper
Senior Member

Joined: 19/05/2015
Location: South Africa
Posts: 280
Posted: 03:29am 28 May 2015
Copy link to clipboard 
Print this post

Greetings all,

I realise that my first post being a feature request is a little rude and presumptuous of me, but I thought I had better get it in whist Geoff is busy working on a 4.7 release.

Would it be feasible to extend the current XMODEM command to send/receive the block of memory allocated for Variable Storage? I don't mean the 2K block of FLASH allocated to Saved Variables but rather the RAM allocated to current Variables.

My reasoning is that it would allow the current status of a running program to be saved and restored, by the user program. It could have many applications, similar in concept and use the the Cassette Tape interfaces of the 80's BASIC computers.

Whilst I realise this can be achieved by adding a MMC or SD Card to the target board, that would complicate hardware / software design, use up extra I/O pins and add to the cost, whereas, in applications that are using the Console as an I/O device anyway, it would be convenient to have that same Console port double as data Backup.

I had hoped that my first post would be of my current project but, alas, that is taking longer than I had anticipated, but this feature request is related to it. An Intelligent Training, Development and Test platform based on the MicroMite MkII and the ASCII Terminal controller, integrated into a keyboard.

More details to follow.....

http://caroper.blogspot.com/
 
Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3165
Posted: 10:41am 28 May 2015
Copy link to clipboard 
Print this post

Interesting feature.

I will have to think about it but at first glance it may not be as easy as it seems. Saving ordinary integer and floating point variables is easy, they sit in a table and it would be easy to copy/restore the whole table.

But with string variables and arrays the memory space for these is allocated from a common pool of memory so the data could be anywhere in RAM. To get around this the solution might be to save/restore the whole of RAM including the allocation table. The problem with this is that other parts of RAM will be allocated for other uses (serial port buffers, etc) and if restored these will just use up memory and never be released.

A better way would be to send/receive the variables using some sort of special coded sequence (eg, first the name, then size, then the type, then the data, etc). This is getting quite complicated and will take up a lot of the chip's limited resources.

As I said, it needs some thought.

Geoff
Geoff Graham - http://geoffg.net
 
Chris Roper
Senior Member

Joined: 19/05/2015
Location: South Africa
Posts: 280
Posted: 11:20am 28 May 2015
Copy link to clipboard 
Print this post

Thanks for considering it Geoff, I had assumed that all variables would be in a common block, but having Strings and Arrays dynamically allocated as part of the Heap makes sense.

Just a thought, rather than dumping all variables, it may actually be better for the user and for yourself if the Variables to be sent were specified in advance.

Would that then allow you to leverage the VAR SAVE code, possibly as VAR SEND and the corresponding VAR RESTORE as VAR RECEIVE?

I note that the VAR command does not handle Arrays, I assume that is because of the 2K Block size, but it would be beneficial if Arrays were able to be sent as well even though not saved.

Cheers
Chris

http://caroper.blogspot.com/
 
CircuitGizmos

Guru

Joined: 08/09/2011
Location: United States
Posts: 1421
Posted: 05:24am 29 May 2015
Copy link to clipboard 
Print this post

I would think that an XMODEM implementation in CFunction that could tx/rx an array would be good. It would be up to the user to stuff (and unstuff) that array with variables and other arrays.

That would be a CFunction to send/receive an array.

- - -

Or perhaps if it gets implemented into the language:

XMODEM SEND (send program)
XMODEM SEND RAM (send variable table block)
XMODEM SEND ray() (send array - user stuffed)

...and all the receives to go with that.


Micromites and Maximites! - Beginning Maximite
 
Lou

Senior Member

Joined: 01/02/2014
Location: United States
Posts: 229
Posted: 11:03pm 29 May 2015
Copy link to clipboard 
Print this post

Geoff,

Speaking of feature request, VAR SAVE and VAR RESTORE is it possible/feasible to put in VAR SAVE (and RESTORE) 2,3,4 ??

I have used all 50 of the possible VAR SAVE values and could use many more to store more setups and user controlled values. The values I'm saving are six digit numeric variables for setups and only use up 496 bytes of the 2k memory space allowed for the variables. Maybe VAR SAVE 2,3,4 could be a subset of VAR SAVE and not use more of the possible command handles.

If not possible/feasible for more VAR's directly is there a way to get more VAR's like maybe packing numbers into string$'s or something ??

Thanks for all your hard work, Lou
Microcontrollers - the other white meat
 
Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3165
Posted: 12:33am 30 May 2015
Copy link to clipboard 
Print this post

Wow, that is a lot of variables.

I will put it onto my todo list for investigation. There must be a clean and extensible way to add more variables to the list. Perhaps allowing arrays to be saved would be the answer.
Geoff Graham - http://geoffg.net
 
Lou

Senior Member

Joined: 01/02/2014
Location: United States
Posts: 229
Posted: 08:32am 30 May 2015
Copy link to clipboard 
Print this post

Great, thanks Geoff

That would be a big help to me.

Lou
Microcontrollers - the other white meat
 
Print this page


To reply to this topic, you need to log in.

© JAQ Software 2024