 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 : MM/MM+ 5.2/6.0?
  Page 3 of 7   |
|||||
| Author | Message | ||||
| piclover Senior Member  Joined: 14/06/2015 Location: FrancePosts: 134 |
No, the compiler cannot "consolidate strings" when the same strings are used in different modules (*.c files), unless a whole-program link-time optimization is performed, which is not an optimization available to the PIC-gcc version in use. The saving I obtained comes from the use of a separate *.c file (Messages.c; it is important to instantiate the strings there and not in a header file, so that the strings are not created for each *.c file #including that header) which holds the shared strings, which are used via pointers (declared, but *not* instantiated in Messages.h) by other *.c files needing them. This way, the shared strings appear only once in the final binary (in the Messages.o object file, which gets linked with the rest) instead of once in each *.o file corresponding to the *.c source file using those strings. It's easy for you to see it happening by yourself: just apply the provided patch to v5.1 sources and recompile, then you will see that the program size is reduced by 1516 bytes when compared to the un-patched sources. Note that I do not claim any "copyright" on that patch: it's still your code, just slightly shuffled around for a better efficiency. I'd be more than happy, however, if, to thank me, you would implement error trapping for the MX170 in a future version... ;-) [quote]However, I do have plans to create an error message table, mostly so that translations into other languages could be easily done.[/quote] Moving all the strings (and enumerations/structures, especially the table of procedure and function names) into the data segment would indeed be a good way to save space for the program itself. I'm however unsure how to convince gcc to perform that kind of "move". |
||||
| JohnS Guru  Joined: 18/11/2011 Location: United KingdomPosts: 4071 |
If it's gcc it can be done via a link script (but may be ugly). Separately, it might help to mark messages (and other non-changing data) const so the tools know they're read only and can potentially be combined. A linker (verbose) MAP can help to see the default section names, which you can also override if you want to use a linker script. For 1500 bytes, though? hmm... Example scripts are around, such as for boot roms. Same idea exactly. John |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
MM BASIC almost fills up the whole code segment in the MX170 (256Kb), and added with the MIPS16-ification of Touch.c (another gain of 504 bytes, bringing the total gain to almost 2Kb of free code space), that might be all what would be needed for a new feature (hopefully, error trapping) to make its way in a future version... 
After that, well... We could try and petition Microchip for releasing a DIP-28 PIC32MX170F512B (for 512Kb)...  |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3303 |
As it happens, I was talking with a Microchip tech support guy the other day and asked that very same question but he said that the die with 512K would be too big for the skinny DIP package. Pity, we will just have to wait for Moore's law to further work its magic. Geoff Graham - http://geoffg.net |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9646 |
Die with 320k?
Just kidding. I know they would not do that.  Smoke makes things work. When the smoke gets out, it stops! |
||||
bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2956 |
GDay Kon, All, Why not use a small bit of hardware to do it instead? I don't know about the complications in the software with files open etc but to put an idea into the mix something like this very cheap chip ($0.11ea from Element14) NC7SZ19P6X They are also very small at 1mm x 1.5mm in size. You could set an extra uMite pin as a toggle and wire it like this: 
Then it is a simple matter of setting the TOGGLE pin HIGH for the original SD card and LOW for the NEW SD card. If necessary then close any open files before doing the toggle. Anyway it is an idea that may fix your issue. Kind Regards, Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
Did they consider making rectangular dies, instead of square ones ?... There's plenty of space in a DIP-28 package for that kind of die... |
||||
kiiid Guru Joined: 11/05/2013 Location: United KingdomPosts: 671 |
Hi Mick, this is somewhat similar concept to what I am using. It is possible for me to modify the MMbasic so it can support more devices. I am reluctant to do that though, because once out of the mainstream development, I would need to do that with every next revision which Geoff releases, and speaking in more general terms, I would much rather stay on the hardware side. 
http://rittle.org -------------- |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3303 |
That looks like a pretty good solution Kon. Where is the problem? Do you want to support more than four SD cards? Geoff Geoff Graham - http://geoffg.net |
||||
| kiiid Guru Joined: 11/05/2013 Location: United KingdomPosts: 671 |
Hi Geoff, I don't think anyone ever would need more than four devices. In another device which is also built around the MM, I am using two cards, each one of them selected by its own CS. Obviously one of them is currently not usable because OPTION SDCARD can specify one pin and from that point it is driven automatically. This part here with the multiplexer is an extract from the schematic of my ELLO 2M computer (which I am planning to release public pretty soon, once I announce it officially). Of course I can drive 'manually' the DRVx pins to select the needed device, but the reasons why I am still not doing that I explained in my previous post. PS. There is another little function which I think MM is currently missing and I only discovered that yesterday when I actually needed it - the equivalent of ~ in C. Maybe something like NEG()? http://rittle.org -------------- |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3303 |
Good point, I did not think of that. It means that I will have to put a greater priority on consolidating all error strings into one table. Thanks but you are using some tools which I don't have and to be frank, don't have the time to implement just now. I have been experimenting with moving some stuff into the bootflash area of the MX170 and gained a few bytes. So I had a shot at error trapping and I can report that it works well. So far the syntax is: OPTION ERROR ABORT is the current arrangement where MMBasic will abort the program and return to the command prompt. OPTION ERROR IGNORE will ignore any error. The program will continue with the statement following the statement that caused the error. OPTION ERROR NEXT will only ignore an error in the statement following this command. After the next statement has completed (with an error or not) the behaviour of this option will revert to OPTION ERROR ABORT. The read only variable MM.ERRNO will be set to non zero if there was an error or zero if there was not. Similarly the variable MM.ERRMSG will be set to the error message that would normally be generated or to an empty string if there was no error. I have uncovered two serious bugs in the MX170 that cause trouble in complex and large programs so I will have to release a new version soon (ie, 2 to 4 weeks) and I hope to have this error trapping in there. Geoff Geoff Graham - http://geoffg.net |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3303 |
Ah, that would be the perfect application for a small BASIC sub placed in the library. Something like this: Sub SDCARDn as Integer
Port(pin, 2) = n End Sub You would then have your own command (SDCARD) without hacking the source. Geoff Geoff Graham - http://geoffg.net |
||||
| kiiid Guru Joined: 11/05/2013 Location: United KingdomPosts: 671 |
Yes, it would be perfect. I have thought about it, but wanted to leave the entire system 'blank' and available to the user :) http://rittle.org -------------- |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10407 |
Konstantin, Geoff I may be missing something but I don't understand how multiple SDcards can work sensibly. The cards need initialising into SPI mode on insertion but the MM firmware controls this and makes assumptions about the initialisation status and AFAIK doesn't ever initialise when a file is already open. What it does at other times depends on whether card-detect is implemented in the OPTION command. I have made a tentative start at replacing the Microchip SDcard routines with FatFS which has proper Multiple volumes (physical drives and partitions) and long file names. I've got the FILES command working and therefore most of the underlying basics but it probably needs a couple of weeks on concentrated effort to do a complete replacement (well worth while IMHO). The biggest issue is integrating in with the SDcard error handling in the MM firmware which seems to be spread amongst a number of modules - Geoff: you know this part of the code so much better than me it would take you a fraction of the time. Thoughts? |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
That's one of those rare occasions when the users we are are happy that there's some bug in a software... It means a new version with more goodies soon for us to enjoy ! |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
Sorry, ignore (or delete) this post, wrong button pressed. Wanted to Edit and pressed Quote... EDIT to spurious reply: ARGH !... Can't edit my previous post now... :-/ (for the board manager: would it be possible to allow posters to delete their last post, in case of such a stupid mistake as mine ?... Thanks in advance !) |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3303 |
Peter, Yes FatFS is the way to go. The SD card routines came from the original Maximite (over 5 years ago) and are well due for an upgrade. BUT, while they have been working I have been reluctant to mess with them as I have so many other projects on the go. To me the error handling seems quite logical 
But, as you say, that is probably because I know my way around it. Part of the issue is that Bill's syntax for BASIC merged serial port handling with file access and that dual personality makes for confusing code. The other factor is that I wrote the code over a frantic few weeks without the polish that my later efforts received. Geoff Geoff Graham - http://geoffg.net |
||||
| kiiid Guru Joined: 11/05/2013 Location: United KingdomPosts: 671 |
Peter, these are my thoughts. As far as I know, once initialised a card remains in this state until the power is removed. A simple one-bit flag can be used to determine whether a card has been initialised or not. The card detect signal can be simply polled to find out whether already initialised card has been removed, or a card which is not been initialised so far - inserted. Beyond the point of initialisation there isn't anything much more than selecting which card to address by asserting its CS. If I am missing some detail in this, disregard my comment 
http://rittle.org -------------- |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3303 |
The problem is that the Microchip SD card routines (which are at the core of the MM+ support) only have one file table. So, when you switch from one card to the other you would have to close all files, flush the buffers and initialise the new SD card. Then the same when you went back to the first. You could not access two cards simultaneously - instead it would be like replacing one card with another. Geoff Geoff Graham - http://geoffg.net |
||||
| kiiid Guru Joined: 11/05/2013 Location: United KingdomPosts: 671 |
Ah, that makes sense... 
http://rittle.org -------------- |
||||
| Page 3 of 7 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
