 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 2 of 7   |
|||||
| Author | Message | ||||
| matherp Guru  Joined: 11/12/2012 Location: United KingdomPosts: 8605 |
You don't need SQR because you have FPow Hopefully next release of MM firmware will support typed CFunctions and then it will be possible to create any missing maths functions as functions. Of course it is possible now as subroutines. |
||||
| piclover Senior Member  Joined: 14/06/2015 Location: FrancePosts: 134 |
Here is also a patch applying to the current Micromite v5.1 firmware sources, which makes them compilable under Linux (header filename characters case issues, "\" vs "/" file separator issues, and file path issues in XML files). diff -durN Micromite51/Source/Hardware_Includes.h Micromite51-patched/Source/Hardware_Includes.h --- Micromite51/Source/Hardware_Includes.h 2016-01-08 09:53:36.000000000 +0100 +++ Micromite51-patched/Source/Hardware_Includes.h 2016-04-10 15:05:28.275933576 +0200 @@ -106,7 +106,7 @@ #include "General/SPI.h" #include "General/Flash.h" #include "General/Editor.h" -#include "General/Xmodem.h" +#include "General/XModem.h" #include "General/Touch.h" #include "General/Draw.h" diff -durN Micromite51/Source/Micromite-MX170.X/nbproject/configurations.xml Micromite51-patched/Source/Micromite-MX170.X/nbproject/configurations.xml --- Micromite51/Source/Micromite-MX170.X/nbproject/configurations.xml 2016-01-22 09:19:11.000000000 +0100 +++ Micromite51-patched/Source/Micromite-MX170.X/nbproject/configurations.xml 2016-04-10 15:06:33.105824846 +0200 @@ -27,10 +27,10 @@ <itemPath>../General/Touch.h</itemPath> </logicalFolder> <logicalFolder name="f1" displayName="MMBasic" projectFiles="true"> - <itemPath>..\MMBasic\Commands.h</itemPath> - <itemPath>..\MMBasic\Functions.h</itemPath> - <itemPath>..\MMBasic\MMBasic.h</itemPath> - <itemPath>..\MMBasic\Operators.h</itemPath> + <itemPath>../MMBasic/Commands.h</itemPath> + <itemPath>../MMBasic/Functions.h</itemPath> + <itemPath>../MMBasic/MMBasic.h</itemPath> + <itemPath>../MMBasic/Operators.h</itemPath> <itemPath>../MMBasic/Custom.h</itemPath> </logicalFolder> <logicalFolder name="MX170" displayName="MX170" projectFiles="true"> @@ -40,9 +40,9 @@ <itemPath>../MX170/Serial.h</itemPath> <itemPath>../MX170/Configuration_Bits.h</itemPath> </logicalFolder> - <itemPath>T:/Programming - Micromite/Source/Version.h</itemPath> - <itemPath>T:/Programming - Micromite/Source/Hardware_Includes.h</itemPath> - <itemPath>T:/Programming - Micromite/Source/MMBasic_Includes.h</itemPath> + <itemPath>../Version.h</itemPath> + <itemPath>../Hardware_Includes.h</itemPath> + <itemPath>../MMBasic_Includes.h</itemPath> <itemPath>../Main.h</itemPath> </logicalFolder> <logicalFolder name="LinkerScript" @@ -83,7 +83,7 @@ <itemPath>../MX170/Serial.c</itemPath> <itemPath>../MX170/MiscMX170.c</itemPath> </logicalFolder> - <itemPath>..\Main.c</itemPath> + <itemPath>../Main.c</itemPath> </logicalFolder> <logicalFolder name="ExternalFiles" displayName="Important Files" diff -durN Micromite51/Source/MX470/IOPorts.h Micromite51-patched/Source/MX470/IOPorts.h --- Micromite51/Source/MX470/IOPorts.h 2016-01-08 00:36:35.000000000 +0100 +++ Micromite51-patched/Source/MX470/IOPorts.h 2016-04-10 15:05:28.275933576 +0200 @@ -24,7 +24,7 @@ #ifndef IOPORTS_H #define IOPORTS_H -#include "..\General\Flash.h" +#include "../General/Flash.h" #if !defined(__32MX470F512L__) && !defined(__32MX470F512H__) #error Processor not supported diff -durN Micromite51/Source/MX470/SDCard/FSconfig.h Micromite51-patched/Source/MX470/SDCard/FSconfig.h --- Micromite51/Source/MX470/SDCard/FSconfig.h 2015-03-20 09:57:40.000000000 +0100 +++ Micromite51-patched/Source/MX470/SDCard/FSconfig.h 2016-04-10 14:57:39.249257526 +0200 @@ -35,7 +35,7 @@ #ifndef _FS_DEF_ -#include "Microchip\Include\Compiler.h" +#include "Microchip/Include/Compiler.h" #include "HardwareProfile.h" // Summary: A macro indicating whether Long File Name is supported diff -durN Micromite51/Source/MX470/SDCard/Microchip/MDD File System/SD-SPI.c Micromite51-patched/Source/MX470/SDCard/Microchip/MDD File System/SD-SPI.c --- Micromite51/Source/MX470/SDCard/Microchip/MDD File System/SD-SPI.c 2016-01-14 10:28:49.000000000 +0100 +++ Micromite51-patched/Source/MX470/SDCard/Microchip/MDD File System/SD-SPI.c 2016-04-10 15:05:28.342600131 +0200 @@ -70,7 +70,7 @@ #include "../Include/MDD File System/FSDefs.h" #include "../Include/MDD File System/SD-SPI.h" #include "string.h" -#include "../../FSConfig.h" +#include "../../FSconfig.h" #include "../../HardwareProfile.h" /****************************************************************************** |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
|
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
Edit to my ACOS/ASIN code proposal (to take -1 and 1 into account !) // Return the arcsine (in radians) of the argument 'number'. // n = ASIN(number) void fun_asin(void) { float f = getnumber(ep); if(f < -1.f || f > 1.f) error("Number out of bounds"); if (f == 1.f) { fret = 1.5707963268f; } else if (f == -1.f) { fret = -1.5707963268f; } else { fret = arcsinus(f); } targ = T_NBR; } // Return the arccosine (in radians) of the argument 'number'. // n = ACOS(number) // return the arccosine of a number void fun_acos(void) { float f = getnumber(ep); if(f < -1 || f > 1) error("Number out of bounds"); if (f == 1.f) { fret = 0.f; } else if (f == -1.f) { fret = M_PI; } else { fret = 1.5707963268f - arcsinus(f); } targ = T_NBR; } |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
@Geoff Yet another wish, for v5.2: please, remove that ClearSavedVars(); call, at the end of SaveProgramToFlash(): this is *really*, *really*, super-annoying to get the saved variables wiped out each time you change your program with the built-in editor, having to go through all the menus/process to resave-them again from the program once restarted... |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
Yes, clearing the variables after an edit is annoying. However, l do believe that they should still be cleared when a new program is loaded. Geoff Geoff Graham - http://geoffg.net |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
I disagree... I also often use AUTOSAVE to upload various versions of a program under development (or updates to an old program), and don't want to loose the saved parameters either in this case !... Plus, there's a VAR CLEAR command for the purpose of resetting the saved variables when deemed necessary, and NEW is also clearing them... |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
Yet another wish, for next MM BASIC version: error trapping... Granted, there's already the WATCHDOG feature, which allows to restart the PIC whenever a program stopped because of an error. However, that's quite a radical way of trapping minor errors (such as an invalid date or time entered by the user and passed to DATE$ or TIME$, which stop with an error in that case), especially since it resets everything (variables, date and time, timer, etc...) and is more appropriate to trap catastrophic errors (infinite loops and the like). So far, the only alternative we got to WATCHDOG is to implement redundant checks (redundant, because these checks already exist at the firmware level) in BASIC for every user input that could cause a program error. It'd be *much* easier and smarter to be able to trap such errors and cause them to branch to a subroutine (with the error passed as a string parameter, for example) or to a label. Such a mechanism existed in SuperBASIC (the Sinclair QL BASIC) and was implemented as a WHEN/END WHEN construct (that also allowed to watch a variable value as an alternative to error trapping), like so: WHEN ERROR REM do something to diagnose and recover (the SuperBASIC didn't pass an error string, but the ERRNUM and ERRLINE functions allowed to diagnose the error). END WHEN Another possibility would be to implement it as a "ON ERROR" event, like so: ON ERROR SomeSubRoutine SUB SomeSubRoutine(error_message$) REM do something to diagnose and recover END SUB and also (for simpler recovery, without diagnostic but a simple branch to a safe part of the code): ON ERROR GOTO some_label Of course, for the latter ON ERROR GOTO construct (and unlike the WHEN ERROR/END WHEN and ON ERROR SomeSubRoutine constructs, that would be best implemented as simple subroutine/program interrupt calls), some things should be taken care of, such as clearing the return stack (GOSUB/SUB stack), FOR/LOOP/etc stack and local variables before the branch to the label is done. |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
The ON ERROR GOTO is a pain in the b&tt because an error can occur at many places and figuring out the right branch to continue is difficult and leads to lots of code to maintain. I would rather have a ON ERROR RESUME NEXT. I suspect that is also easier to implement as it will just continue to execute the next line. This is also compatible with GWBasic which i think is the inspiration for MMBasic. A program will then continue its 'flow' and you just check an Err variable to see if it is set to a nonzero value. If an error occured then Err.code, Err.line and Err.Description should be available. Once you captured that error and ignored it or processed it , you use Err.Clear to set the Err to zero and continue the program. Microblocks. Build with logic. |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
|
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
Yes, when I was writing in GWBasic I only ever used ON ERROR RESUME NEXT and it covers all bases. I will add this to the list of new features to be investigated. However, like all new features, it might not make it into the MX170 version as that only has a few hundred bytes of flash left and I want to keep that in reserve for bug fixes. Geoff Geoff Graham - http://geoffg.net |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
As far as I am concerned, only the MX170 matters... SMDs are not for my old eyes... There are several possibilities to squeeze more code into the MX170: - The Touch.c file, which doesn't contain speed-critical code, could be generated as MIPS16 code (504 bytes gained). - Some optimizations could be performed: I'm not sure how gcc generates the strings embedded in the code and if it commons them up when identical, but most error strings could be placed into a table indexed by an error code (or string address, to avoid using a table of fixed length strings that would be half empty and waste space) passed to the error() function (instead of passing the error message itself each time, which may appear several times in several modules). - Some "drivers" (I'm thinking about the humidity sensor driver, the DS18B20 driver, the remote control driver) or barely ever used features (anyone using XMODEM ?...) could be removed from the firmware and replaced with CFunctions modules, to be loaded on a per-project basis, when strictly necessary. This would of course imply to vectorize more routines (SPI, I2C, OneWire, Serial I/O...) to allow accessing them from the CFunctions (which would also be quite interesting to develop other drivers... Bosch sensors, nRF2401 comms, etc). Just suggestions, of course, but now that we got the wonderful CFunctions and LIBRARY features, I think the firmware should only include the BASIC itself and the specific drivers for uncommon (or not always used) hardware should be kept out of it and loaded only as needed, and as modules... |
||||
| Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1664 |
Hi Geoff, Wondering if it's worth considering enhancing the TEMPR and TEMPR start commands to enable the reading of multiple DS18B20's on a single pin. I'm doing it at the moment with some subs provided by Jman. I'm sure all would agree that any temperature related project would benefit greatly from the ability to bring just one cable back to the MicroMite, rather that multiples going to individual pins. The thread relating to the matter:- Help with 1-Wire temp reading. and Search for multiple 1-Wire devices. If not feasible for the MM2, maybe for the MM+. Thanks Phil |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
OK, I will have a look at it. From what I remember you need to know the serial numbers of each sensor which might make the whole thing too complicated (ie, discovering the numbers in the first place). However, if it can be done with a simple syntax it would be worthwhile. Geoff Graham - http://geoffg.net |
||||
| Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1664 |
Thanks Geoff, I'd presume a variable for MaxNumberofSensors could be used, and an array created to store all the serial#'s of the devices found. Don't know whether then it would be best to read all sensors found, or use the array position to read them individually. Cheers Phil. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
given a simple mmbasic program is available to discover the serial number of a single sensor, it may be adequate to only expand the read command thus: TEMPR START pin [, precision [, serialnum ]] TEMPR( pin [, serialnum ]) it is then left up to the user to type in the program to discover the serial numbers of their sensors, note these down one by one, and enter them by hand into their final code. this does create the problem of what happens when a faulty sensor is replaced many years down the line? also, what if a faulty sensor stops a whole string of them from working? a TRY ... EXCEPT ... END construct would help to aleviate some of these problems, so the faulty sensor could be reported without a crash and perhaps even a new one detected by user code. regarding the 28-pin dip question - i think it would kill off a good portion of the userbase if future support for the dip packaged MX170's were to be stopped. i would far rather see other features (or portions thereof) moved into custom functions, such as colour LCD support. given that colour LCD driver code can be tucked away in the 'library' this seems to me, personally, to be a far better option. cheers, rob :-) |
||||
kiiid Guru Joined: 11/05/2013 Location: United KingdomPosts: 671 |
Hi Geoff, I have discussed this with you some time ago, but will bring it up again. Would it be possible to implement multiple SD card support? OPTION SDCARD cs [,cd] [,wp] to become OPTION SDCARD csA: [,cdA:] [,wpA:] [,csB] [,cdB:] [,wpB:] ... optionally up to D: I am happy to supply you with code for processing the filenames in a multidrive environment. Alternatively, if this all is too difficult, would it be possible just to make the SD pin 'soft' so I can manually manipulate the CS and still use the file functions? Thanks http://rittle.org -------------- |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
And here is a quite significant optimization, based on what I wrote above, in my last post in this thread: by sharing strings that are used in different places (different *.c files) in the sources, I gained 1516 bytes of program code !!! The patch against MMBASIC v5.1 is here: 2016-04-21_105726_string_optimizations.zip This kind of optimizations is quite easy to perform, using the "strings" and "sort" utilities under Linux, like so: strings Micromite_5.1.hex | sort >strings.txt
You end up with a file (strings.txt) that contains all the C string candidates ("candidates" because all the strings are there, but there's also gibberish since the 'strings' utility simply extracts from the binary file all the suites of printable characters ending with a NUL (0) character). When the same string appears more than once, it is then worth 'grep'ping the sources tree with it to see where it is used in the source files, and then trying to common that string up via a common header file (I named it Messages.h) containing only "extern const char* SOME_SHARED_STRING;" declarations (this file having to be included in all the source files using the shared string(s), and an associated C file (here, Messages.c) containing the actual string instantiations (const char* SOME_SHARED_STRING = "Some string"; ). You then replace all the instances of the string ("Some string") with the corresponding shared string constant pointer (SOME_SHARED_STRING). Note that not all strings are good candidates for being shared (for example, sharing "End CFunction" does allow to gain a few bytes, while sharing "End CSub" makes you loose a few); that's because gcc may have succeeded to optimize the string usage already (and various versions of gcc may yield to different results: modern gcc versions can even do that kind of optimizations all by themselves, thanks to link time, whole program optimizations, which is not available for the gcc version used here)... Note also that each shared string will eat up 4 bytes in the data segment (for the relocation address, most probably). There's however so much room available in that segment (60kB), that it's not an issue here given the large amount of bytes gained for the firmware. |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3167 |
Thanks for the suggestions on how to gain more flash space. Some are great and I also have some ideas of my own so all is not lost. But, any gains made will be small so I am still not planning a major feature upgrade. I believe that the MX170 Micromite currently has a good feature mix. This is supported by the fact that most feature requests since 5.1 have been for things that are specialised and would be little used. Some time ago I said that I wanted the MX170 version to settle and stabilise for a while and that view is still the case. So, I don't plan to introduce any major features for the MX170 but just fix bugs and polish what is there. kiid: It is on my list for the MX470 but but I have to say, not with a huge priority because I cannot see many people wanting it and I would prefer to not add extra syntax to achieve it. I am not sure what making CD soft entails but that might be a quick way out. piclover: All good compilers consolidate strings so I am not sure where you got your savings from. However, I do have plans to create an error message table, mostly so that translations into other languages could be easily done. Phil23: I have had a look at multiple sensors but it would be messy to implement and another one of those things that not many people seem to be interested in. Sorry but it is on the back burner for a while. Geoff Geoff Graham - http://geoffg.net |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9082 |
@ kiiid - can you not request and recompile the source to include the extra features you need - specifically the extra drive letters? As far as I know, this is perfectly legal, just so long as you don't distribute your modified source. I can't remember if you know C enough to do that though. If you don't know enough C to do that, then please ignore my question. 
I seem to remember our resident Cfunction guru(matherp) producing a simple SD card Cfunction for the 170 series chips. I expect that could probably co-exist with the native SD card support on the MM+, but I might well be barking up the wrong tree there. Smoke makes things work. When the smoke gets out, it stops! |
||||
| Page 2 of 7 |
|||||
 Print this page |
