|
Forum Index : Microcontroller and PC projects : Question about settick
| Author | Message | ||||
Quazee137![]() Guru Joined: 07/08/2016 Location: United StatesPosts: 600 |
settick never fires while waiting for console input. Is that how it should be working? Option EXPLICIT SetTick 1000,tock,4 Dim k, count=0 Do Input "Waiting for tick to fire ";k Print "main loop "; count Loop Sub tock count=count+1 Print "Ding Dong ";count End Sub |
||||
MicroBlocks![]() Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Yes. Use inkey$ instead. Microblocks. Build with logic. |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1671 |
MB is correct. From the MMbasic manual for Maximites (v4.5) EDIT: I did not find the text above (about interrupts) in the manual for the Micromites (v5.4). Geoff should maybe complete that. I think this could be a replacement for Input (and LINE INPUT) that works with SETTICK (not tested). Michael causality ≠correlation ≠coincidence |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2171 |
yes. Input is a very blunt instrument and as you have discovered, once you disappear inside it your own program loses control of things until INPUT returns. There was a thread a little while back where a number of options were posted that give you much better functions that play nice with your code and still give you the input you require as shown in rave's link in the previous post and Peter63 function here |
||||
Quazee137![]() Guru Joined: 07/08/2016 Location: United StatesPosts: 600 |
Thanks everyone for the replies. I looked in the 5.4 manual for the Micromites and did not see any thing showing it would not work. This will also apply to LINE INPUT ? So inkey$ will do. Quazee |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3308 |
Page 40. Geoff Graham - http://geoffg.net |
||||
Quazee137![]() Guru Joined: 07/08/2016 Location: United StatesPosts: 600 |
Geoffg is there an updated version of the 5.4 MicroMite user manual? Page 40 shows information on the Timing related to PAUSE, PULSE, TIMER and SETTICK. Quazee Thanks. Found it on 38 and 39 under Interrupts |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2171 |
Not on its own. INKEY$ grabs any *single* character waiting in the buffer, if there's nothing waiting you get the empty string "" So what you'll have to do is grab characters in a loop and build up your input data in a string variable, generally until INKEY$ returns character (13) - this is the enter key on most keyboards. Then will you have your "INPUT" string in your variable. it isn't hard to do but if you want something canned, use one of the functions mentioned earlir. I rarely use INPUT at all, only when I can afford to wait indefinitely in a program of for debugging etc. At any time in main threads where other things are happening in the background I always build up a string using the method above. |
||||
| twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1671 |
Thanks Geoff. All good! I found this (I scanned the manual only for the occurence of SETTICK) Michael causality ≠correlation ≠coincidence |
||||
Grogster![]() Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9750 |
So inkey$ will do. Not on its own. INKEY$ grabs any *single* character waiting in the buffer, if there's nothing waiting you get the empty string "" Yes indeed. I made that mistake a few times, when I thought that the keyboard input was buffered - it isn't. (well, not past one byte it isn't)Smoke makes things work. When the smoke gets out, it stops! |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2171 |
(well, not past one byte it isn't)good point. You have to scan the keys (I always do it in in the main loop) fairly frequently and build up a global variable, I then set a flag when char(13) received so anything that needs to know about input gets signaled there is a complete line waiting. |
||||
MicroBlocks![]() Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
?? Keyboard input is buffered otherwise you would miss keystrokes. INKEY$ does not wait when there is nothing in the buffer. I always make sure i use INKEY$ about every 200ms or faster. This will keep the user happy as longer times will be felt as being non responsive. Microblocks. Build with logic. |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3308 |
Yes, the console input is buffered (128 characters). So, for example, the user could type in 20 characters and the next 20 calls to INKEY$ will return all 20 one by one. Interrupts should be allowable during INPUT and LINE INPUT but it is amazingly difficult to implement so it has remained on my ToDo list for the time being. Geoff Graham - http://geoffg.net |
||||
Grogster![]() Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9750 |
Really? That's never worked for me. If I check INKEY$ at the time I am expecting a keystroke, I get it. If I check it any other time - even if keys have been pressed, I always get back an empty string, so the code never does what it should. IE: If I check INKEY$ inside a loop, and grab characters as they arrive, no problem. If I don't check INKEY$ inside a loop, and just request a key from INKEY$, it is always "". I assumed this was cos at the time of the request, no key was being pressed, so you get back an empty string. I will have a play with this command now - perhaps I was doing something else wrong at the same time. EDIT: I am wrong. Totally wrong. ![]() This test code does exactly what Geoff says it does. At the time I was trying to get INKEY$ to work for me, I must have been doing something wrong. I stand corrected. Smoke makes things work. When the smoke gets out, it stops! |
||||
| The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |