 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 : MX170 4.6b, problem with pin(0) ?
| Author | Message | ||||
| PicFan Senior Member  Joined: 18/03/2014 Location: AustriaPosts: 133 |
Hello, Maybe is this a bug, please look the Modification and the Output in the 2. Example ? TEST 1: Works OK ! REM TEST Analog Input ! spgPin = 23 SETPIN spgPin, AIN PRINT "" PRINT "Display Analog-Value" A = PIN(spgPin) / (pin(0) / 1.2) Example in 4.6b Manual P29 PRINT "V="A end Output on MMEDIT Chat > RUN Display Analog-Value V= 2.46089 > TEST 2: REM TEST Analog Input ! spgPin = 23 SETPIN spgPin, AIN PRINT "" PRINT "Display Analog-Value" vRef = PIN(0) Modification A = PIN(spgPin) / (vRef / 1.2) PRINT "V="A end 1. Output on MMEDIT Chat > RUN Display AnaloÁ Micromite MkII MMBasic Ver 4.6b Copyright 2011-2015 Geoff Graham > 2. Output on MMEDIT Chat, only if you click 2. RUN under 1 Sek. > RUN Display Analog-Value V= 2.46089 > TEST 3: REM TEST Analog Input ! spgPin = 23 SETPIN spgPin, AIN PRINT "" PRINT "Display Analog-Value" DO vRef = PIN(0) A = PIN(spgPin) / (vRef / 1.2) PRINT "V="A PAUSE 2000 LOOP end Output on MMEDIT Chat > RUN Display AnaloÁ Micromite MkII MMBasic Ver 4.6b Copyright 2011-2015 Geoff Graham > Not DO . . . LOOP ! If you change the PAUSE to 500ms, maybe ist works ? Thanks and best regards Wolfgang |
||||
| matherp Guru  Joined: 11/12/2012 Location: United KingdomPosts: 10400 |
should be: PRINT "V=",A |
||||
| PicFan Senior Member Joined: 18/03/2014 Location: AustriaPosts: 133 |
Hello Matherp ! This is not the problem, please look the Output from Example 2 + 3 or test the following: REM TEST Analog Input ! spgPin = 23 SETPIN spgPin, AIN PRINT "" PRINT "Display Analog-Value" vRef = PIN(0) PRINT "END" Output on MMEDIT Chat > RUN Display AnaloÁ Micromite MkII MMBasic Ver 4.6b Copyright 2011-2015 Geoff Graham > False Output for "Display Analog-Value" and no Output for PRINT "END" !! vRef = PIN(0) this Command make the problem, the System is "RESTARTED" ! If you click "RUN" after a short delay (< 1 sek.) maybe it works, after a long delay (2-3 sek.) it works not. Thank you ! Wolfgang |
||||
Justplayin Guru Joined: 31/01/2014 Location: United StatesPosts: 330 |
I have two MX170's that I purchased directly from Microchip at the same time. One "reboots" when I try to read the voltage from Pin(0), the other returns a value. During 4.6 beta testing I reported the problem as a possible bug but no one else experienced the problem. Since one works and the other doesn't, I assumed the problem is a defective MX170. I still use the questionable chip for on a breadboarding since everything else I've tried seems to work normally. --Curtis I am not a Mad Scientist... It makes me happy inventing new ways to take over the world!! |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10400 |
Interesting, reading the internal reference voltage doesn't work at all on the MX470 due to a silicon issue. Sounds like it might be marginal on the MX170 as well. PicFan, what happens if you use CPU 10 to reduce power consumption? This is the issue on the MX470 |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3303 |
When I was developing the MM2 I also had intermittent issues with reading the internal reference but they "magically" went away and I never found the reason. It could because the chips are marginal and the problem only shows up in certain conditions (Vdd, temperature, etc). I was never happy with the PIN(0) concept and this just makes it worse - I may have to remove this feature from the next Micromite version. Geoff Geoff Graham - http://geoffg.net |
||||
| PicFan Senior Member Joined: 18/03/2014 Location: AustriaPosts: 133 |
Hello Geoff ! So it works without problems: PRINT PIN(spgPin) / (PIN(0) / 1.2) The example in Manual MK2 4.6b Page 29 ! A problem is if you make a variable: vRef = PIN(0) Wolfgang The change from CPU 40 to CPU 10 have no effect, the same problem. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10400 |
In the STM32 code I've implemented OPTION VCC nnn This is then used to scale both the ADC and the DAC to correct the absolute readings. Obviously, this doesn't solve the problem on a battery supply which is changing but works well for a normal supply where the voltage may not be exactly 3.3V but is unlikely to change much. |
||||
| Justplayin Guru Joined: 31/01/2014 Location: United StatesPosts: 330 |
@Geoff - Don't know if this helps... If I read from any analog input pin first, pin(0) functions correctly from then on. REM TEST Analog Input !
spgPin = 23 SETPIN spgPin, AIN PRINT "" PRINT "Display Analog-Value" A = PIN(spgPin) B = PIN(0) Print A, B, PIN(0) end --Curtis I am not a Mad Scientist... It makes me happy inventing new ways to take over the world!! |
||||
disco4now Guru Joined: 18/12/2014 Location: AustraliaPosts: 1025 |
I am seeing the same on MX170 with 4.6B. Will reset unless another pin is read first. F4 H7FotSF4xGT |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1116 |
100 pin 470 does not appear to support pin 0 - I get invalid pin error whether with a pre-ceeding analog pin read or not? panky Edit: Running a 100 pin 470 from WW with beta 10 ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
| disco4now Guru Joined: 18/12/2014 Location: AustraliaPosts: 1025 |
The 470 code i.e. beta 10 does not support the pin(0) function as it caused reboots so was not coded into MMbasic, gives you the invalid pin error F4 H7FotSF4xGT |
||||
| panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1116 |
I see also (I think, be gentle boys if I'm in fairyland) that in the 100 pin 470 beta10 that the Pin() and Setpin commands use the actual physical pin of the chip. Is this true for the 28 and 40 pin 150s? What of the 170s? ... or is it just part of the beta part of the 470s? Would this not cause issues with portability? My understanding is that the original Maximite pin numbering was from 1 to 20 and not related to the physical pin of the PIC chip? Thus Pin 1 on the Maximite was actually physical pin 21 on the 26 way connector and some other number on the chip itself. I can't see any reference in the uMite doco or anywhere else that this has now changed. Am I missing something here? Doug. Edit: Found the reference to using physical pin numbering in the 4.6b manual. Curious Geoff, why the change as now in i/o, there is no portability from chip to chip?. Doug. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2948 |
@panky With all the MicroMites (MX150, MX170 & MX470 versions) the physical pin number has always been the reference used in code. I can't be 100% certain as to the new ARM MicroMite port though as still not yet played with one! The MaxiMite was different i.e. physical pin did not correlate to number used in code (as you stated). Hope this clears things up. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2447 |
has anyone had a look at the MX170 source code to see what 1-time initialization is performed when reading an analog input (pins 2, 3, etc) that is not carried out when reading pin(0)? on the face of it, this seems a fairly straightforward bug to nail down. rob :-) |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3303 |
Reading from pin(0) might look like reading from any other pin to the BASIC programmer but it is different internally. I will investigate but I believe that the issue with reading the internal reference is hardware related. Geoff Geoff Graham - http://geoffg.net |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2447 |
it would be a great shame to lose the pin(0) function, as it enables the micromite to work as a semi-accurate analog data collector without need for external reference components. if the answer were as simple as having to always read an analog input before each access to the bandgap reference, would a crude workaround be to re-jig the analog version of the pin() command thus: value = pin( n [, scale]) thus pin(2) would return the analog input at pin 2 assuming a 3v3 supply (as is currently implemented), while pin(2,1.0) would return the value scaled using the bandgap reference. using a scale value other than 1.0 would allow the returned value to be corrected for both variances between bandgap references on individual MX170's, as well as any input divider at the pin. cheers, rob :-) |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
