 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 : MicroMite Beta 11
| Author | Message | ||||
TassyJim Guru  Joined: 07/08/2011 Location: AustraliaPosts: 6101 |
The ultrasonic distance command still working well on my sensor both as a 3 terminal and 4 terminal device. The longer trigger pulse is no problem for my unit. STR$() is a lot better but I found an anomaly with printing 0.00001 n = 0
print n print str$(n)+" "+"*"+str$(n,0,1)+"*" n= 0.001 print n print str$(n)+" "+"*"+str$(n,0,1)+"*" n= 0.00001 print n print str$(n)+" "+"*"+str$(n,0,1)+"*" n= 27.00001 print n print str$(n)+" "+"*"+str$(n,2,1)+"*" Output: > run
0 0 *0.0* 0.001 0.001 *0.0* 1.00000e-05 1.00000e-05 *1.00000e-05* 27 27 *27.0* After some more thought, I think it may be intentional for very large and small numbers to always print with their exponents. Jim VK7JH MMedit MMBasic Help |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9308 |
With uM now up to Beta 11 - Geoff - how far away do you think the "Official" release will be? I expect that this chip is going to be published in the likes of Silicon Chip? Smoke makes things work. When the smoke gets out, it stops! |
||||
| paceman Guru Joined: 07/10/2011 Location: AustraliaPosts: 1329 |
The revised STR$ function is spot on for my LCD mins/secs timer countdown application Geoff. It saved me eight lines of workaround - it all happens in one line now. lcd 2,13, str$(dispmins,2,0,"0") +":"+ str$(dispsecs,2,0,"0")
It all lines up nicely around the ":" separator with leading zeroes in place and the missing zero variable value is fixed also. Great stuff, Greg |
||||
atmega8 Guru Joined: 19/11/2013 Location: GermanyPosts: 722 |
Servo Problem: servo 1, 0 and servo 1, 19 do not work, while servo 1, 0.1 and servo 1, 18.9 will work |
||||
| atmega8 Guru Joined: 19/11/2013 Location: GermanyPosts: 722 |
But if i put a servo 1, stop it work. all commands send from commandline, not with "RUN" |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3196 |
Thanks atmega8, I need to change the manual. Geoff Geoff Graham - http://geoffg.net |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6101 |
Geoff, log(0) causes the MicroMite to reboot. I am not sure what needs to be done in these situations. The DOS version is a bit more helpful: "Argument singularity in log -inf" Jim VK7JH MMedit MMBasic Help |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3196 |
The first of the Micromite articles should be in the May issue (due in about 5 weeks). I hope to nail any remaining bugs in the next few weeks and have the final release out in mid next month. Because the Micromite does not have an in chip update facility and many people will be buying the chip pre programmed with MMBasic I figure that it will be important to have the "official release" as bug free as possible. This is why the beta program and everyone's efforts are so valuable. Geoff Geoff Graham - http://geoffg.net |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2350 |
you could implement a firmware update mechanism thus: 1. a basic program that contains the update loader in data statements, and assembles this code in RAM (of which there is plenty free). the basic program then makes a CALL to this code in RAM. 2. the update loader, when called and finding itself resident in RAM, transfers itself into the flash area formerly occupied by the basic program (of which there is plenty free), and having established the flash copy is intact updates the 32MX's reset vector to point to this flash resident copy, so that thereafter the micromite starts directly in 'upgrade mode'. the RAM resident copy then causes a software reset. 3. the update loader, when finding itself resident in flash, sits there waiting to receive a suitable uuencoded .hex file from the console. this code it programs into FLASH as it streams in, being careful to not overwrite itself. once fully programmed, it calculates the checksum of what it has downloaded, and if correct updates the reset vector to point to the newly uploaded (updated) copy of MMbasic. 4. the last thing the update loader needs to do is jump to the 'all clear' section of MMbasic that is normally called when the RX and TX console lines are found to be tied together upon startup - this will erase the update loader from flash. all relatively simple. it is NOT necessary to write the update loader or the basic bootstrap code now, all one needs to do is put in place the mechanisms for it to work in the future - a CALL function being the most obvious, as well as making sure no impediments exist to prevent the above scheme from working. rob :-) |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3196 |
Thanks Jim, it should throw an error. I will fix it. Rob, neat idea and it could work. You would not have to copy the bootloader to flash as the PIC32 can execute code in RAM. It would take a lot of work though and I am running out of time. Geoff Geoff Graham - http://geoffg.net |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2350 |
geoff - the idea of copying to flash is so that a failure at any point will leave the micromite in a state from which it is possible to recover. if the update loader is resident in RAM and power is lost while upgrading the firmware, then the 32MX will need hooking up to an ICSP to recover. the trick when doing any sort of upgrade is to minimize those 'fragile' moments, when a power or communications loss will be fatal (or require equipment the customer does not have). with the complex procedure i outlined above, the only critical parts are when updating the reset vector - an event that is only a handful of instructions long and lasting just a fraction of a second. if only the CALL command was required, then putting that in place now may be relatively simple. alternatively, it may even be possible in the present state of the micromite basic to use POKE commands to point a suitable jump vector into a block of code in RAM and then cause the jump to be executed. in that case, nothing would need to be done now. rob :-) |
||||
| atmega8 Guru Joined: 19/11/2013 Location: GermanyPosts: 722 |
Hi Geoff, i think the better way would be to allow 0 and 19 as a PWM value, as just changing the Manual. Think of a Loop, where Most People may boundary check for 0 and 19. This will cause unneccesarily Troubleshooting for everyone. Just my 2ct.... Dietmar |
||||
 Print this page |
