 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 2 of 3   |
|||||
| Author | Message | ||||
| Chris Roper Senior Member  Joined: 19/05/2015 Location: South AfricaPosts: 280 |
Actually there is a big difference. The external RTC will be battery backed. The external RTC will run whilst the PIC sleeps. The External RTC is also giving you non volatile RAM to save system Configuration variables in. The external RTC could also give you additional FLASH or EEPROM depending on the package. AND most importantly, the I2C Pins can be shared by several external devices, such as port expanders, along with the RTC whereas the XTAL pins are single function and provide no battery backup. You mentioned that battery backup is not an issue on a battery powered solution, but I beg to differ, you will lose the time whilst changing the battery's but more importantly if you need to conserve battery life you need to slow or sleep the CPU which would disrupt the internal RTC, so your battery life is negatively impacted. Unfortunately no, but you could Google it. The ChipKit forums is a good starting point, but I am reluctant to link it from here as the ChipKit could be seen as a competitor to MicroMite in many ways. 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 |
Agreed, and I must admit I missed the fact that you said "Mains Powered with Battery Backup", but I left the points anyway for those reading the thread with different requirements. In Africa unfortunately we are not blessed with stable Mains power and are subjected to frequent blackouts, even here in South Africa we struggle to keep the lights on, so most designs are Battery powered with Mains backup :) Just as an aside, that you may find interesting, you were comparing to the PICAXE 28X2 which uses the PIC18F25K Chip. The MicroMite uses the PIC32MX170 as you are aware and though microchip strive to keep essential pins compatible between all 28 pin PICS, that is the clock, power and ground pins. The PIC 32's and I believe some of the PIC 18's have something called PPS (Peripheral Pin Select) that allows you to allocate, within reason, the pins used by Serial Communications, I2C, SPI and certain Interrupt and Timer / Counter functions. MMBASIC does not expose the PPS Layer, though Geoff has used it to allocate the internal referrals to the pains. If you ever use a Naked PIC32 you can have hours of fun mapping your I/O to suit your needs and the PCB layout of the project. On another note, if your device is to be Mains based, how about using the mains frequency as the reference for the RTC? just one pin with an interrupt would be needed for an accurate time base. http://caroper.blogspot.com/ |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
Because the accuracy is not as good as a (well tuned) quartz-based oscillator. The accuracy of the mains AC power frequency is only guaranteed within +/-20s (i.e. the mains 50Hz frequency is corrected so that the drift of a clock based on it never gets larger than this), while with a quartz, I easily achieve a +/-3s per month or better accuracy, which, in my alarm clock, I further compensated with a software drift adjustment (because at some point, it becomes impossible to adjust the variable capacitor linked to the quartz in small enough a step). I achieved a +/-1s drift over 6 months (in an almost constant temperature room). I already designed a v2 for that alarm clock: if I ever build it, it also got a temperature sensor that will make it possible to take the temperature drift into account as well... 
But yes, if you don't need ticks at a higher frequency than the mains' and can stand a 20s inaccuracy for the clock, then it's definitely a good solution to derive your time keeping clock from the mains. |
||||
| Chris Roper Senior Member Joined: 19/05/2015 Location: South AfricaPosts: 280 |
Thanks, I never realised that, I always thought it was somehow synchronised with an atomic clock or at least something a lot more accurate than +/- 20 sec. Not sure if you are into CFunctions yet, I have not got that far but am keen to explore them in more detail, you may find the algorithms that Roman Black published to be of interest. Whilst not intended for MicroMite his algorithms are well documented and easy to adapt to most any language or platform. http://www.romanblack.com/onesec/High_Acc_Timing.htm That link is directly to his timing stuff but his home page is full of fascinating algorithms, a few of which I have used in various PIC projects. http://caroper.blogspot.com/ |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
I'll have a look. Thanks for the pointers !  |
||||
G8JCF Guru  Joined: 15/05/2014 Location: United KingdomPosts: 676 |
@Chris Roper The first draft of V2.0 of the CFunctions tutorial together with V2.0 of CFuncgen itself are available for download from http://www.cfuncgen.dyndns.org/ V2.0 of the tutorials document includes a new chapter "C for MMBasic programmers" which tries to help MMBasic programmers get into C from a CFunction writing perspective. Peter The only Konstant is Change |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
I'm not getting the same results, here, but I'm made the test with a recompiled MMBASIC without the XTAL change. At the *same* clock speed (48MHz), I get the following results: [code] Geoff's original MMBASIC Recompiled (-O1 -fomit-frame-pointer) Benchmark 1: 0.024 0.029 Benchmark 2: 0.149 0.161 Benchmark 3: 0.238 0.262 Benchmark 4: 0.240 0.262 Benchmark 5: 0.568 0.571 Benchmark 6: 0.777 0.818 Benchmark 7: 1.158 1.243 Benchmark 8: 0.313 0.350 [/code] That's a 10% speed difference, i.e. even with a 50MHz quartz, I still won't have the same speed with custom-compiled MMBASIC... :-( |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
Bump ! Any chance to get a thought from Geoff about my first post in this thread ?... Especially about the ADC & voltage reference issue, which is a *big* issue when compared to, for example, what the PICAXE offers... |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
The simple way to accurately measure voltage is connect a reference voltage to an input, measure it and then use that reading to calculate the correction factor for the other analogue inputs. Not hard to do, so I am not sure that it is that big an issue. However, it would be nicer if MMBasic had more options regarding the reference voltage for analogue inputs so it is definitely on the ToDo list. One point that should be made is that you cannot expect too much accuracy from the analogue inputs. There is a lot of digital noise from the high speed CPU and it requires great care in the circuit and PCB design to reduce the noise. MMBasic also takes multiple readings and uses a special averaging algorithm to reduce noise but it is only partially successful. Geoff Geoff Graham - http://geoffg.net |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
geoff: have you looked into the possibility that the issues with reading the internal bandgap reference may be circumvented by always performing a read from an external pin first without interruption inbetween? if that is the case, the suggestions i've made elsewhere about rolling the two operations into one - x = pin(2, scale) - may be a viable solution. personally, i consider being able to read the internal bandgap reference as quite useful for where the micromite is operated off 2xAA cells. operating off batteries directly is a major advantage in some applications that the likes of the arduino don't so easily offer (but they can read their own internal bandgap reference). btw, i've been doing a little more testing (4.7 beta 23) with the editor bug i reported earlier. it appears that if you do a mark-delete operation at any time, the bug disappears until the micromite is factory reset (using !!!!!!!!!!!). this makes it sound like an uninitialised variable somewhere that mark-delete uninitialises but that mark-cut does not. cheers, rob :-) |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2294 |
nope, i take that back - the bug behaviour is more complicated than that! |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
I would wait until I get back Rob. You have very little chance of nailing the bug by looking at the symptoms. I speak from experience in chasing down many a bug. Geoff Graham - http://geoffg.net |
||||
| Chris Roper Senior Member Joined: 19/05/2015 Location: South AfricaPosts: 280 |
Interesting, I have just loaded the new 4.7B on an MX170 and can't reproduce your bug. http://caroper.blogspot.com/ |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
Not sure how it is done by the PICAXE firmware, but that chip is also a very fast one, and I used several in various projects, driven from 8MHz to their full 64MHz speed, and using the internal reference for A/D conversions: I typically get an accuracy better than 0.5%, which is quite honourable, and sufficient for most use cases... The PIC32MX even got one advantage over the PICAXE with the separate analog supply, which you can easily filter against high frequency noise with a small coil and a decoupling capacitor. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8601 |
I don't understand why this is still being discussed. The issue is that the Microchip silicon supporting the MX170 internal reference is unreliable and the MX470 internal reference doesn't work at all. This is nothing to do with Geoff or MMBasic or comparisons with PICAXE, try chasing Microchip for an updated silicon revision. I have posted a Cfunction on this thread which will read the internal reference on a MX170. This is the same code as Geoff used previously but slowed down and with an additional level of checking so if it works on your chip that should solve the issue. If it doesn't work there is nothing Geoff could do to solve the issue on your chip. The 28-pin Micromite has 10 ADC pins, the 28-pin PICAXE has 16, the Micromite has proper Analog GND and VCC inputs, the PICAXE doesn't. The Micromite has a proper version of Basic, the PICAXE .... Everything is a compromise. If you are looking for > 10 Analog inputs and a working internal reference and only want 1-in-200 (8-bit) accuracy, use a PICAXE. If you want to get closer to 10-bit accuracy and can put up with 9 analog inputs use a 28-pin Micromite with an external reference. If you want 28 analogue inputs use a MM2+ etc. |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
|
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8601 |
I'm sorry if my message came across as intolerant but I have some idea how many hours Geoff puts into the Micromite firmware that he releases FREE. He has just released major new functionality for the MX170 and MX470 that hugely expands its scope and yet you immediately raise an issue for which there is an easy workround and for which he has previously explained that he has not found a satisfactory solution. I'm sorry that you think that I'm sure you know better but Geoff is the one doing the work and providing us with this great resource. I understand you have no interest in the MX470 but do you not think Microchip may have used the same basic silicon design as the MX170 and do you not think this may mean there could also be an issue on that chip even if the errata is only confirmed on the MX470? |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3677 |
Obviously if the silicon is broken then it's up to Mchp to fix it, but with that said if there's a "proper method ... via ... configuration registers" then perhaps posting some working C code for it would be useful. John |
||||
BobD Guru Joined: 07/12/2011 Location: AustraliaPosts: 935 |
Henri You are obviously knowledgeable about this. Have you considered doing some of the development for this and offering it to the community? Bob edit: Sorry, John, I just noticed you said much the same thing. |
||||
| Page 2 of 3 |
|||||
 Print this page |
