 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 7
  Page 4 of 7   |
|||||
| Author | Message | ||||
vk4tec Senior Member  Joined: 24/03/2012 Location: AustraliaPosts: 239 |
Hello I have been watching the conversations with interest and keep an eye on Geoffs page and silicon chip. Is there work going on on a new mite ? I seem to get the impression that what is going on is some decision making I have a couple of "ALL IN ONE" development boards I think if you aim for 1. Minimilistic BASIC mite - for embedded projects 2. All singing all dancing development board RTC I2C TEMP HUMIDITY SERIAL USB That is what floats my boat anyway - Andrew - Andrew Rich VK4TEC www.tech-software.net |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9308 |
The MicroMite is a new embedded controller chip that Geoff has been developing, which runs MMBasic and has a heap of the features you have been reading about. No VGA or video output, no keyboard and several other things have been removed(cos you don't need them for an embedded controller, and if you DO - then just use the full-size MM!), dirt cheap at $3 a chip etc. It is in Beta testing at the moment, but I am sure it will be "Officially" released very soon - I am pretty sure most of the bugs have been discovered and fixed. As far as I know, Geoff plans to publish it in Silicon Chip magazine at some point. If you want to find out it's basic specs etc, then check out this thread - all FORTY pages of it!!!!! But the very first post by Geoff tells you all about it's basic specs. Some aspects of what he has written there have now changed as more features were added during Beta testing, but it will give you a very good starting point. Smoke makes things work. When the smoke gets out, it stops! |
||||
| dmasz Newbie  Joined: 12/09/2013 Location: PolandPosts: 21 |
Hello, As Geoff asked the audience: """"""""" I know that I am going to regret asking this but is there any other device that would benefit from having support built into MMBasic? """"""""" Here are my 2c I would like to propose features under consideration: - ROTARY ENCODER with software debounce function (for mechanical types encoders) - SOFTWARE DEBOUNCE on input for switches support as it is very useful option. br Dan |
||||
| robert.rozee Guru  Joined: 31/12/2012 Location: New ZealandPosts: 2350 |
for software debouncing in a variety of situations over the years, i've always used a simple up-counter. upon each pass round the main loop check to see if the switch is detected as open or closed: if closed increment a counter, if open set the counter to zero. next line, upon seeing the counter above a certain value (corresponding to around 50mS) set a SWITCH_n flag to be true. this is pretty easy and flexible to code, allowing fine-tuning of the debounce delay/count that is required. SETPIN 4, DIN count4 = 0 switch4 = 0 ... <begin main loop> ... IF PIN(4) THEN count4 = MIN(count4 + 1, 100) ELSE count4 = 0 switch4 = 0 ENDIF IF count4>20 THEN switch4 = 1 IF switch4 THEN <code to execute if switch 4 is closed> ENDIF ... <end main loop> which reminds me, can i put in a plug for inclusion of the functions MAX, MIN, and the 3 missing trig functions in the language? rob :-) |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9308 |
I always just use double-checking, and it has always worked(ported from PICAXE code - not tried this on MM, but should work): if pin(1)=1 then pause 250 if pin(1)=1 then <your button press code here> endif else goto start endif If the button(or switch) is still active after quarter a second from the first trip instance, then it performs what that button is supposed to do. If it is not active at that point, then go back to start of code(or where-ever). Smoke makes things work. When the smoke gets out, it stops! |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2350 |
the problem with that is the "pause 250"; for a quarter of a second your application is frozen. pretty much everything i write (and have written in the past) needs to operate in real-time, with several other tasks going on simultaneously. so most applications end up as a main loop spinning round, with events kicked off as required and designed to be completed in small 'slices'. rob :-) |
||||
atmega8 Guru Joined: 19/11/2013 Location: GermanyPosts: 722 |
Hi, tested LCD 4 and 2 Line, tested ds18b20, SPI Device (RFM 12), analog in, PWM, IR Sony remote Control input... So far no problems/Bugs ...  |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9308 |
Understood. In my application for the code above, this was a kind of "Start" button, so the code was only EVER looking for that button to be pressed, and not caring one jot about anything else going on, so I can certainly see what you mean about needing to watch other things too in another application. Smoke makes things work. When the smoke gets out, it stops! |
||||
| atmega8 Guru Joined: 19/11/2013 Location: GermanyPosts: 722 |
|
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9308 |
As I understand it, no set interrupts are cancelled, it's just some commands(such as INPUT) will pause them until complete, whereapon, the interrupt resumes. INPUT and LINE INPUT are examples of that. From the MM manual: Smoke makes things work. When the smoke gets out, it stops! |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3196 |
Excellent, thanks very much. Geoff Geoff Graham - http://geoffg.net |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3196 |
The subject of interrupts seems to be causing puzzlement. The best way to clear this up is to explain how they work. Interrupts in MMBasic are different from hardware interrupts. In MMBasic the interpreter makes a check for an interrupt after each command has been decoded and executed. If an interrupt is detected it will jump to the interrupt code and then, when an IRETURN is encountered, return to the main program. Because this check is made after every command it has the potential to slow down the program. For that reason I have been careful with this part of the interpreter and have optimised it as much as possible. Most commands take about 50uS to execute on the Micromite and that means that the interpreter will only check for an interrupt every 50uS (on average). So for example, if you set an interrupt to trigger on a high input, it could be possible for that pin to go high and then low again while the interpreter was executing a command and in that case the interrupt would go unnoticed. Because interpreted BASIC is inherently slow the interrupt system was not intended to detect very fast events so this was not a problem. When you execute an INPUT command the interpreter could sit there forever waiting for a keystroke and so the interpreter could miss any number of interrupts during that time. In the manual I describe this as "interrupts are disabled" but in reality the interpreter is just not looking for them. The other command that has the potential to cause missed interrupts is the PAUSE command. But in this case the interpreter constantly checks for interrupts while it is spinning waiting for the pause time to finish (it is doing nothing else) and there is special code to catch the return from an interrupt and re enter the PAUSE command to serve out the remaining pause time. So, you can have interrupts during a PAUSE command. All the other standard commands in the BASIC language execute quickly enough that there is not an issue with missed interrupts. But some of the "special device" commands/functions like DS18S20() have an issue in that they take an appreciable amount of time to execute. For example, the IR SEND command must clock out the IR code with precise timing and it cannot jump off and execute some arbitrary code in the middle. Also, it takes some time to send the whole key press (up to 32mS) with the result that any interrupts that occur and then go away during that time will be missed. The big problem is the DS18S20() function which has to wait for 200mS (an eternity) while the sensor is doing the measurement. I could have used the same trick that I used with the PAUSE command to check for interrupts while it was waiting but I wanted to keep the code size small and I figured that if a user was sophisticated enough to use interrupts they could also write their own function using the 1-wire commands and get interrupts in that. But I will go back and look at the DS18S20() function and see just what the overhead would be to check for interrupts while it is waiting for the measurement to complete. Perhaps more precise wording in the manual would also help here. So, another long winded post but I hope that it helps to clear the air. Geoff Geoff Graham - http://geoffg.net |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2817 |
An excellent and very clear explanation. Many thanks . . . For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
| vk4tec Senior Member Joined: 24/03/2012 Location: AustraliaPosts: 239 |
Good to know this sort of info Helps you undestand what you can use the gadget for When you are coding in Assembly Language you know the timing and bits and bytes When you add Basic over the top it is important to know these key features - Andrew - Andrew Rich VK4TEC www.tech-software.net |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2350 |
excellent explanation - perhaps this should be added into the manual? brings to mind the days of MSDOS, where the nature of the beast was that it was on the whole mostly non-reentrant. mmbasic is similarly non-reentrant, but also seems to have many interrupts created in software. rob :-) |
||||
vasi Guru Joined: 23/03/2007 Location: RomaniaPosts: 1697 |
In my experience with DS18B20, after issuing the measure command, you can query the sensor any time you want (even continuously), but you will get an actualized value only after the required amount of time. Anyway, you can issue the measurement command, do other activities (let the microcontroller to drink his coffee) and then you can read the sensor. No blocking. http://www.youtube.com/watch?v=F0-XlE1B9cI Hobbit name: Togo Toadfoot of Frogmorton Elvish name: Mablung Miriel Beyound Arduino Lang |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
It seems that i2c is a bit of a "leave it alone" subject, but in the case of IR or PS2, where there could be significant delays resulting in missed interrupts (MM Basic variety), it is possible to use two MCUs, one as the IR/PS2 decoder and the other as the i2c interface. Yes, I realise that it is adding to the complexity of a project, but it works for serial input devices where you can't afford to have the input stream interrupted. The i2c master can poll the combo-module without interrupting the serial in part. When the IR or PS2 has finished sending its data, it does a handshake 8 bit transfer to the i2c part. The i2c master ignores any data received by polling until a "data ready" control byte is sent. This can be hours later if needs be. The module can be split into two parts for versatility, i.e. serial to parallel and parallel to i2c. If there are left over data from previous key presses, a simple write to clear the control byte is all that is needed. I know there are uM specific for IR etc, but this is an option for the adventurous. David M. |
||||
| atmega8 Guru Joined: 19/11/2013 Location: GermanyPosts: 722 |
Vasi, but this means, that geoffs implementation of the DS18B20 unneccesarily looses Interrupts. Let the DS do its conversion and after the conversion time just ask the device again, Bingo. @ Geoff, If you implement it in this way, the DS routine would work unblocking, meaning that Interrupts in The background can' t get lost! Is this not a better way? |
||||
| vasi Guru Joined: 23/03/2007 Location: RomaniaPosts: 1697 |
@atmega8, I did that a while ago, with PIC18F2550, Jallib library and JALv2 compiler (FreeJALduino board), just to demonstrate that I can query the sensor anytime, even if it didn't finished measuring the temp. Anyway, I said exactly what you said :) [quote]Anyway, you can issue the measurement command, do other activities (let the microcontroller to drink his coffee) and then you can read the sensor. No blocking. [/quote] But is there in the wild a broken lot of DS18B20 who can't behave as in my movie. Hopefully all the stocks around the world are 0 regarding that defective lot. Hobbit name: Togo Toadfoot of Frogmorton Elvish name: Mablung Miriel Beyound Arduino Lang |
||||
BobD Guru Joined: 07/12/2011 Location: AustraliaPosts: 935 |
I understand that it is necessary, after initiating conversion, to wait 200mS for a DS18B20 to complete that conversion. I haven't read the datasheet; is there any flexibility in the waiting time. Can you wait longer than 200mS? A possible solution to the problem of suppressed interrupts during this time could be to separate the command to the DS18B20 into two parts: initiate and read. These to be two separate MMBasic commands which must be separated by at least 200mS and this would allow interrupts to occur during that time. How practical is this? Thoughts anyone. edit: I just realised that this suggestion had already been proposed by atmega8. Reading the emails is a lot harder than reading the posts directly. |
||||
| Page 4 of 7 |
|||||
 Print this page |
