 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 and Micromite Plus Beta 23
  Page 4 of 5   |
|||||
| Author | Message | ||||
MicroBlocks Guru  Joined: 12/05/2012 Location: ThailandPosts: 2209 |
I think a firmware which is as empty as possible would be best. Several HEX files can be created by loading a 'driver' and then reading and saving the flash to a hex file. That could be done by us and published. A newcomer could then choose the HEX with the right driver and start right away. Or fire up a terminal, load the drivers and then start. Those hex files can then be maintained completely separate from the firmware. If a driver needs an update, then just use the firmware hex, combine it with the driver hex and ready. This will free up Geoff from having to compile it often. Microblocks. Build with logic. |
||||
twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1566 |
I understand Geoff differently. 1. Load a normal basic text file (the driver or LIBARY file) 2. Execute the LIBARY LOAD. (MMBasic writes it in the flash) 3. Load your basic file But I'm sure Geoff will do it in the best way! 
causality ≠correlation ≠coincidence |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Yes that is what i understood also. When you read the chip after you do step 2 then you have a resulting hex that includes the loaded library. Microblocks. Build with logic. |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1566 |
Sorry, but I see no need to have the HEX file. What is it good for? Edit: Typo:(LIBARY = LIBRARY!) causality ≠correlation ≠coincidence |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
To share. Imagine you have a screen that is not supported by the firmware but is used as the console output. You would have a hard time getting that to work. Instead you use the hex file that has that driver already in it. So just burn that in the chip and ready to go. I do that often with a uMite. I write a program, test it and if it works then i connect a pickit3 and read the complete flash contents. If i want a copy of the program i just burn it into a new chip and ready. Very easy to do and i find it the best way to make multiple copies of the same program. Microblocks. Build with logic. |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1566 |
I see! 
I never shared chips. causality ≠correlation ≠coincidence |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3281 |
Yes, that is exactly what I was thinking of (still to be tested to make sure that it is feasible). Some great ideas bouncing around here. Geoff Graham - http://geoffg.net |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2428 |
the one problem i can see is that this would afford the distribution of 'custom' builds of mmbasic, where there are software components added that neither geoff nor the end user has direct access to. indeed, company "X" could create a commercial product that while being intertwined with mmbasic and providing all the functionality of mmbasic, could (without legal recourse) identify itself as something quite different. bear in mind, i am playing devil's advocate here, just exploring what could happen and not saying it would. on the plus side, i do like the idea of micromite basic being stripped back as much as possible with regards to drivers for various colour LCD displays. i'd like to see no colour LCD support loaded up by default, with this provided by 3rd party custom functions that can be placed in some sort of library space that is safe from being erased by the new command. but i think it if there is such a library space then for transparency it is important that there be some command that allows 'reversing the process', where the library and custom functions can be pulled back into the editor for viewing and review. or a 'library space' could be implemented as a 'horizontal line' lock, that can be placed in a basic listing, whereby the editor will refuse to allow editing of any code past that line without the lock being opened. on a related note, the notion of custom functions being stored just as binary data when the editor is exited, and reconstituted back into basic lines when the editor is again launched, would seem to address the core of much of what is being requested. just my opinion, mind you! cheers, rob :-) |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2931 |
@Geoff, It would be very useful to be able to use the LIBRARY feature within a users program and not just at a command prompt. This would allow a user to have a similar feature as the INCLUDE command in other languages so that specific drivers/sub-routines can be loaded from SD card dynamically in a program (typically at the start). Example: Assume someone wants to play with an8x8 LED matrix (based on the common MAX7219 driver chip) but they do not want to get involved in the details of the code that drives the hardware. A library (i.e. a .BAS file) can be created in the method outlined already (LIBRARY SAVE) that includes the subroutines that do all the 'dirty work' talking to the matrix at the hardware level. Such a subroutine could include a new command like MATRIX(r1,r2,r3,r4,r5,r6,r7,r8) that simply takes the eight byte values passed and displays them on the matrix rows 1-8. Assume for now the .BAS file containing the code for the MATRIX subroutine is called LED_8x8.bas So the person wanting to 'play' simply includes a single line at the start of their program: LIBRARY LOAD "LED_8x8.bas". Then anywhere in their program they can use the MATRIX(....) command as if it were part of MMBasic. The only thing I am uncertain about is whether you need to perform a reset before the LIBRARY becomes effective in FLASH. If you need to do a reset, the above solution becomes invalid as a restart will always be triggered whenever the LIBRARY LOAD "filename' is encountered and the program never progresses beyond this point. Also, is it worth having a .LBR filetype for these libraries (if saved on SD card)? This allows it to easily distinguish between LIBRARY files and normal program (.BAS) files. As others have said, I see a large collection of shared files appearing here if this is implemented . . . WW |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1566 |
Thanks for clarifying! causality ≠correlation ≠coincidence |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
A LIBRARY LOAD would go nice together with LIBRARY SAVE, LIBRARY LIST,LIBRARY DELETE This would then guarantee that no code is 'hidden'. Although it still can be a compiled CFunction which inner workings can be difficult to decompile. At least it would be 'Open'. Microblocks. Build with logic. |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1566 |
I can not see any need for that! Anybody can review the library code before uploading it to the µM. Please keep it simple: only LIBRARY LOAD and LIBRARY DELETE. I think Geoff can/will distribute some basic libraries with his MMBasic package. Just my 2c causality ≠correlation ≠coincidence |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2931 |
Not if it is already loaded into FLASH! |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1566 |
For me the LIBRARY code is like devicedrivers for PCs. I never disassembled my drivers. If something goes wrong you should reload the LIB file. Simplicity is also valuable! (EDIT: And makes it more likely to get this feature ...  )
causality ≠correlation ≠coincidence |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2931 |
@twofingers I agree with you. However, just highlighting that it isn't possible to review the library code if it comes 'pre-installed' in the MM(+). And also picking up Rob's point about 'transparency' as there could be the potential for people to do 'nasty' things. So far to keep it simple I just see the need for: LIBRARY LOAD (issued from Command prompt to copy current code into flash) LIBRARY LOAD "filename" (issued from Running code - IF POSSIBLE! to load code in file "filename" into flash) LIBRARY DELETE (issued from Command Prompt or running code to delete Library in flash) Notes: LIBRARY LOAD to overwrite any existing Library in Flash. Only one Library can be loaded LIBRARY LIST would be a nice to have and can come later if people feel the need for this |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1566 |
But this can sometimes be useful. Some people like to hide their code (copy protection etc.). As a first step I would like to have only: LIBRARY LOAD (issued from Command prompt to copy current code into flash) and LIBRARY DELETE (issued from Command Prompt or running code to delete Library in flash) LIBRARY LOAD "filename" can follow later and can come later if people feel the need for this.
I would prefer if LIBRARY LOAD can NOT overwrite an existing library in flash. The attempt should result in a error message. Yes, only one Library can be loaded! It seems to me Geoff has to do no more than to write the little piece of code ...  causality ≠correlation ≠coincidence |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2931 |
Great idea. So if you need to load a Library without failure simply issue a LIBRARY DELETE first. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10180 |
You need load multiple libraries, otherwise if you want a display driver you can't have anything else unless you start joining them in multiple combinations externally which would be horrid |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1566 |
@WW Yes! 
@Peter I think joining can be done in MMEdit, or? Multiple libraries make this job much more complex. causality ≠correlation ≠coincidence |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Yes, multiple libraries is what will work. With that you automatically have a list anyway so a LIBRARY list is on that moment easy. A LIBRARY DELETE had to go through a list also to find the right one to delete. I foresee the most difficulty with flash fragmentation. Maybe a LIBRARY DELETE just deletes all libraries, and then you can load the libraries you need. This will then be consecutive in flash and have no wasted space. Microblocks. Build with logic. |
||||
| Page 4 of 5 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
