 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 : Wishlist for MMBASIC
Page 1 of 3   |
|||||
| Author | Message | ||||
| piclover Senior Member  Joined: 14/06/2015 Location: FrancePosts: 134 |
Greetings folks ! I'm new to the board, and would like to contribute a few ideas about the Micromite and its MMBASIC. While I'm an "old" (in several ways, albeit not *that* old either) hobbyist in electronics, I started using PICs in my projects only a couple of years ago (I used to prefer the good old "wired logic", but I can't deny that micro controllers make things so much simpler...). I started with the PICAXE (28X2) since it did not require a PIC programmer (which I didn't yet have back then) and made several projects with it. It's a great little micro-controller, but it's alas closed source and not as cheap as the Micromite, which I discovered only recently (only two finished projects made with the Micromite so far, but two more are already in the pipeline...). When switching (well, not entirely, since the PICAXE is still a chip I'll be using for future projects) to the Micromite, a couple of things bothered me: - There is no way to use the internal voltage reference or an external reference for ADC conversions (there's the PIN(0) since v4.6B is out, but it'll apparently be removed and is not exactly easy/practical to use). See my other post here about this issue. The solution (since the PIC itself allows it) would be to provide a new command (SETADC ?) to configure the use of the internal 1.2V reference or of an analog pin as the Vref instead of AVdd. - There is no way to use an external oscillator, which is a real shame since it means the MMBASIC built-in RTC feature can't be used because of the internal RC oscillator inaccuracy and instability; on my last project I measured a 8s drift per hour +/-2s from one hour to the next (i.e. the drift is not even constant). This pretty much forces you to use an additional RTC IC (PCF8563 & Co), which pretty much duplicates what already exists in the PIC and in MMBASIC ! Plus, the timers 1ms ticks suffer from the same inaccuracy and "jitter" as the internal clock, and can't be used to reliably measure events at a precise timing (again, the use of an external IC connected on an interrupt pin is then required while the internal timers will not be used as they could). Since the PIC itself allows to use an external crystal on pins 9/10 (for the MX170), I don't see why there won't be an "OPTION" (or an extended "CPU" command syntax) to allow this to happen. Well, these were just my two cents, in the hope they could be useful.  |
||||
Zonker Guru  Joined: 18/08/2012 Location: United StatesPosts: 761 |
Welcome to the forum piclover..! Good points made on a good discussion.. There has been talk on the very subject on other threads here... I guess if lets the ADC front end become more use full we should be adding it in...
|
||||
| Chris Roper Senior Member Joined: 19/05/2015 Location: South AfricaPosts: 280 |
Whilst I have nothing to do with MicroMite, other than as an equally new user, I may be able to shine some light on the above as I faced the same issue with the ChipKIT Boards and a couple of production boards for a client. The problem with the PIC32MX built in RTC is the lack of a Vbat PIN. In other words you can dedicate two pins to a Clock crystal and implement a RTC in the Device, but without its own external supply, Vbat, you lose the time whenever the CPU is rebooted. In the 5 years that my collogues and I have been developing production boards with PIC32's I have yet to see a single design that uses the built in RTC in production. We have designs in the field two of which required RTC functionality and use external RTC chips, with independent battery power, for reliability. When working with the 28 Pin packages the problem is compounded by the the scarcity of PINS and those two pins become more valuable than an RTC function that is rarely used. The second point is slightly more tricky and again I faced that dilemma with the PICKit designs. There are a lot of valid reasons to sacrifice 2 I/O pins and run an external 8MHz Crystal for internal timing accuracy. Unfortunately it is not as simple as adding an "OPTION XTAL" type command. If an external crystal is used it has to be reflected in the PIC Option Flags at compile time and once selected cannot be overridden at run time as it is stored in a protected area of FLASH. My solution was to create two ChipKit Boot-loaders for the MX150 (I have not created one for the MX170 yet), one with External Xtal and one with the pins undedicated. With the ChipKit it is easier to work around the pin limitations by using PPS (Peripheral Pin Select) but unfortunately BASIC in any form is not really suited to working with such low level redirection. In this case we would only lose com2: functionality. I would guess that Geoff actually had that in mind when he set out out the MicroMite Pin Map. In practice my ChipKIT 150 Xtal boot loader is hardly ever used. In applications where timing is critical most people turn instead to the PIC32MX250 in which case the crystal not only serves for better timing but allows the use of USB, at the cost of an additional pin (Vusb), but in designs that need USB communications the sacrifice of the PINS is well worth it. I would love to see an MX250 Implementation of MicroMite with USB used as the console, it would also resolve you issue with Jitter, but I am not sure that Geoff has any real desire to go that route. Certainly if he were going to put in the development time and effort to add the external xtal as an option then, from my practical experience, I would advise that he go the whole hog and and use the MX250. But I am not sure if Microchip have any plans for a memory upgrade for the 28PIN MX250, similar to the MX150 -> MX170, upgrade. So the chances are that the Mk II software may not even fit a USB enabled MX250. Not sure I really helped but at least I got my thoughts out there. Cheers Chris http://caroper.blogspot.com/ |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
|
||||
| Chris Roper Senior Member Joined: 19/05/2015 Location: South AfricaPosts: 280 |
But from Geoff's point of view he would have another Version of MicroMite that then needs supporting and Testing every time he makes a minor code change to the core. For us it would be a nice to have feature, but to Geoff it could end up as a logistical nightmare. The external RTC Xtal "may be possible" as, if I recall correctly, it can be configured at runtime, but it then generates an even bigger headache. It uses the same two Pins that Geoff has chosen as Console Rx/Tx. Allowing for the external Clock Xtal would involve moving the Console and again generate a separate version of MMBASIC that need supporting / testing. There is also the the added problem that it is no-longer a drop in replacement for the other 28 Pin versions. Pin Compatibility is not an issue in one off designes, but in an environment like this it is more important that the Devices can be interchangeable without disrupting key functions. These are of course just my opinions, only Geoff can comment on the actual feasibility of your suggestions in the MicroMite product family. http://caroper.blogspot.com/ |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8583 |
It is very easy to compile a personal version of the MM2 code to use the XTAL if you require it. Download the MM2 source. Install MPLabX and V1.32 of the XC32 compiler. You want to get the trial PRO version so you can compile with optimization level 2. Assuming you use an 8MHz Xtal then there are just two tiny changes in the file "Configuration bits.h" edit #pragma config FNOSC = PRIPLL // was FRCPLL #pragma config POSCMOD = HS // was OFF recompile and burn and you have a xtal version - just tried it and it works fine. If you want it to run at 50MHz use a 10MHz Xtal and also edit "configuration.h" #define CLOCKFREQ (5000000L) //was (4000000L) Note if you do the latter then other clock speeds won't work without more editing in "MM_Misc.h" |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
That's the problem... I don't have the PRO version, so the resulting bootloader would execute quite a bit slower when compared to the original one (and correct me if I'm wrong, but the trial version won't last forever, so I could only re-compile the current version of MMBASIC)... But many thanks for the pointers... And if it's that easy to do, then perhaps someone with a PRO version of the compiler would be ready to provide a modified, XTAL-enabled version for everyone to enjoy... |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8583 |
There isn't that much difference between O1 and O2. Using the benchmarks I get the following (MM2 50MHz using 10MHz Xtal): O1 O2 1 0.023 0.023 2 0.146 0.141 3 0.236 0.228 4 0.237 0.228 5 0.447 0.458 6 0.653 0.658 7 1.031 1.025 8 0.311 0.300 |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
|
||||
| Chris Roper Senior Member Joined: 19/05/2015 Location: South AfricaPosts: 280 |
I haven't used MPLAB XC compiler for a couple of years, mainly because I also don't like having to use MPLAB X and also because all of my production units in the field were developed with MPLAB 8.9 and C32, so I am sticking with them for at least the early life of the deployed products. What I did find during early testing of CX, however, was not that it failed to optimise but in som cases deliberately de-optimised the code by injecting superfluous code that bloated the object code size but never actually got executed. That issue was probably addressed long ago but I have since moved on to using the free version of GCC, which is what XC is actually based on anyway. Getting it to work in MPLAB is not a task for the faint hearted or newbies but can be done and several tutorials are available on the web. That allows all levels of optimisation and is free. I mainly use chipKit and GCC as my development environment and pass my code to the core Systems programmers for inclusion in the final design. They Use the Fully optimised XC compiler for production, so there is no need for me to use it for hardware interfacing / testing at the design phase. http://caroper.blogspot.com/ |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
Interesting, indeed... 
Any difference in bootloader size (which could impact the available memory under MMBASIC) ? |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8583 |
By bootloader I assume you mean the MMBasic firmware? In which case the answer is no. For reference the above testing was done using 4.7b8 with the Xtal modification |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
|
||||
| Chris Roper Senior Member Joined: 19/05/2015 Location: South AfricaPosts: 280 |
|
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
Again, it's an extremely interesting (and surprising) result... One would wonder what those "optimizations" are for, and why MicroChip even bothers to restrict them to the PRO version... |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
Ah... THAT might be quite a serious issue then, yes... Unless the RTC functions (DATE$ & TIME$) are changed as an emulated (software), timer-based RTC... |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8583 |
TIME$ and DATE$ should stay correct with a Xtal clocked processor. They are updated by a 1msec timer interrupt as part of the main code. The advantage of using a RTC Xtal is normally that the processor can go to a low power mode and the RTC will keep updating. |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
Then it's not really an issue !  |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9063 |
Is there any reason why you can't just use an external SPI or I2C RTC with it's own battery backup? The likes of a 3231 RTC and EEPROM module would do the trick, has it's own battery backup, and is extremely accurate. ...and it also has a 32kb(4KB) EEPROM memory chip too... Perhaps I am missing something, but if you are now talking about adding a crystal oscillator, you will lose those two pins to the crystal if you did that at all, so why not just use an external RTC if you need and accurate RTC? Smoke makes things work. When the smoke gets out, it stops! |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
The idea is *precisely* not to be forced to have an external RTC chip, when everything you need already exists in the PIC and the MMBASIC. The problem is also with the PIC timer accuracy (SETTICK interrupts). As for the pins, using an externat RTC also forces you to use I/O pins for it (2 I2C pins or 3 SPI pins), so there's no difference with "loosing" the XTAL pins instead... |
||||
| Page 1 of 3 |
|||||
 Print this page |
