 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 : VAR RESTORE oddness
| Author | Message | ||||
CaptainBoing Guru  Joined: 07/09/2016 Location: United KingdomPosts: 2171 |
Afternoon all. I am building a lighting controller with a "colour map" for five individual LED strings. The map is stored as a string array in between runs. Obviously I need to save the map to flash after each edit otherwise it would have to be done from the default each time you start it. However I am noticing that VAR RESTOREing a string array, the array has to be DIMensioned before hand. This isn't mentioned in the manual (it says VAR RESTORE will retrieve the previously saved variables and insert them (and their values) into the variable table.) The array is Fmap$(144) Length 10 but for an array, I get problems if the array is not DIMmed before hand: > var clear > clear > dim a$(10) length 10 > a$(1)="fred" > var save a$() > clear > var restore > ? a$(1) Error: Index out of bounds > dim a$(10) length 10 Error: Index out of bounds <- so something has fiddled with a$ > clear > dim a$(10) length 10 > var restore > ? a$(1) fred <- worked > I also get a processor exception sometimes -it seems to be if I attempt to restore a simple variable after dDIMming it. I am posting here in the hope it will mean something to greater brains than mine: > clear > dim float flashtest > flashtest=12345 > ? flashtest 12345 > var save flashtest > clear > ? flashtest 0 > clear > dim float flashtest > var restore▒ CPU exception #7 at address 0x9D02E1FD Processor restarted > clear > var restore▒ CPU exception #7 at address 0x9D02E1FD <- now locked up restoring from flash Processor restarted So I am sort of stuck... I can't get to my array if I don't DIM first, and I can't get to my FLOAT if I do. This is 5.0408 - I know it is a bit old but it seems the most rock solid version, others since have introduced bugs (are they all squished now?) > ? mm.device$ Micromite MkII > ? mm.ver 5.0408 > Can anyone else try to see if they can replicate this behaviour for me? If it's all OK at your end then I think a re-flash might be in order. cheers h |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10572 |
That is expected. From the Micromite manual page 76 I assume you are using a MM2? This has only 2K for the saved variables and the Options. Your array by itself is 145*11 + variable definition overhead. I suspect you are exceeding the 2K depending on what is also saved. The DIM FLOAT flashtest should be irrelevant to the problem. VAR RESTORE is perfectly happy restoring into an existing variable - I always use OPTION EXPLICIT so all variables are always DIMed before any RESTORE The firmware should give an error if you exceed the 2K but it is possible that you have triggered some boundary condition which isn't trapped. When you try and restore the variable definition could then be garbage causing the problem - just guessing but.... |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2171 |
Ah, thanks Peter. How did I miss the notes on page 76? OK, so that answers that. I can get by without the flash test variable - it was only to see if I had a result from the restore. Thanks for the answer - and not scolding me for sticking with 5.0408  |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2171 |
The software for this is advancing really well. Thought you might like to see a little vid of the colour map editor on action. It's still a beta but in use daily with no muckups. This latest tweak allows you to "play" the colour map rather than have to let is run through the whole sequence in real time, so you'd have to watch it for 24 hours. Vid is a bit crappy, I filmed it with a potato but you get the idea https://www.youtube.com/watch?v=wP46Ie4o3F8&feature=youtu.be |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9755 |
Nice one.  I was impressed with how the trace followed your touch-pen-thing on the blue trace. And on a 28....  I'm gonna have to get me a potato.  Smoke makes things work. When the smoke gets out, it stops! |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2171 |
Cheers Grogs, praise indeed. The trace follows really well and because of the slow refresh rate of those little ILI9341 displays (el-cheapo 2.4" jobbies from ebay) I couldn't re-draw the whole display so whenever the touch is recognised (not using any interrupts), I draw a grey line from the pixel either side to the middle on the original trace then do the same but in the right colour (in this case blue)... so I am only ever updating two short lines. It does corrupt the other traces but only while editing. If you move the stylus too fast, it does drop points as I am detecting a touch and then grabbing the "address" - if you have moved in between times, you get spikes and dips where the prog couldn't keep up. This was the easiest method I could find to edit the colour maps and it has worked really well, being totally graphical seems to get the concept across really quickly. Really pleased a little 48MHz Mk2 fills the role admirably once more. Screen update is really brisk on the new F4 but that is only as a comparison. The 170 does a fine job in anger. Customer is very happy and keen for the update. Next is to get it talking both ways with an Android App that is in the very early stages to allow the same functionality from a moby. The mite is already spitting out XML (native for Android) for when it sends the colour map to the moby: <?xml version="1.0" encoding="utf-8"?> <ColourMap> <MasterBrightness>20</> <Colours Chan=1>"Red"</> <Colours Chan=2>"Yellow"</> <Colours Chan=3>"Blue"</> <Colours Chan=4>"C/White"</> <Colours Chan=5>"W/White"</> <PWMVals TimeSlot=0> <Chan Num=1>0</> <Chan Num=2>0</> <Chan Num=3>30</> <Chan Num=4>0</> <Chan Num=5>0</> </PWMVals> <PWMVals TimeSlot=1> <Chan Num=1>0</> <Chan Num=2>0</> <Chan Num=3>30</> <Chan Num=4>0</> <Chan Num=5>0</> </PWMVals> <PWMVals TimeSlot=2> <Chan Num=1>0</> <Chan Num=2>0</> <Chan Num=3>30</> <Chan Num=4>0</> <Chan Num=5>0</> </PWMVals> ... <PWMVals TimeSlot=143> <Chan Num=1>0</> <Chan Num=2>0</> <Chan Num=3>30</> <Chan Num=4>0</> <Chan Num=5>0</> </PWMVals> <PWMVals TimeSlot=144> <Chan Num=1>0</> <Chan Num=2>0</> <Chan Num=3>30</> <Chan Num=4>0</> <Chan Num=5>0</> </PWMVals> </ColourMap> Really I think the editor is a lot of work for not very much... beyond the novelty I expect that once a suitable colour map is derived and you have got things just how you want them, things will just settle down and it will spend weeks just playing the PWM values out, hardly ever interacting with a human. |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
