 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 7 of 7 |
|||||
| Author | Message | ||||
| paceman Guru  Joined: 07/10/2011 Location: AustraliaPosts: 1329 |
I'll check that out. David, I think Geoff's new LCD routines are great for everyone not wanting to do anything fancy with the LCD and as he's said, that's what he intended of them. But I'd like a flashing cursor (a pretty common thing) and I'm no software guru. There's a couple of straight forward options for that now that non-experts can use. This thread's about any issues with the beta 7 firmware and it seems to me this fits right in. I don't see any 'storm in a teacup'. Greg |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
Please don't misunderstand me, I don't disagree with anything that is being said on this thread. Its just that I have been using 16x2 LCDs in MPU/MCU projects for years and don't recall an occasion where a flashing or steady cursor was warranted. The screen is only 16 (or 20) characters long and you should know where you are putting the data hence no real need for a cursor. Most of the time, the screen will display a fixed text with a variable data e.g. "Volts =" followed by the variable. If it were for a much bigger display then a cursor could be desirable but that is a different kettle of fish. Maybe I should refrain from commenting on this issue as I will use the i2c version of the LCD because of its simplicity and versatility. As an after thought, perhaps a uMBasic command such as: LCD Command, cmd_value
would obviate the need for elaborate coding. I'm sure most of the command structure already exists. David M. |
||||
| paceman Guru Joined: 07/10/2011 Location: AustraliaPosts: 1329 |
I've got three or four projects using 20x4 LCDs and will be entering data (e.g. exposure time, calibration coefficients etc) with a keypad. One of the keys will be for a 'Menu' and the menu options will show on the LCD. I'd like to leave some parameters e.g 'Set Time = xx:xx' always up on the screen in the same position so you never have to think about where you are in the menu. Requests from the selected menu option for input data will always be on the bottom line. You could display the input data alongside the data request but it's neater to display them on the 'fixed' line (where you'd normally look for that data) with a flashing cursor, as they're entered. You also save character positions and the required format of the input data is already displayed on the fixed line. It'll look something like this: Line 1...|SET TIME = xx:xx
Line 2...|COUNTDOWN = xx:xx Line 3...| Line 4...| Enter New Time This timer example is pretty simple but other projects are a bit more involved. That's not a bad option either but it's more work for Geoff and uses more firmware memory. The other options that Geoff mentioned above are already available. Greg |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Well Geoff did ask for suggestions :) and i agree with Mobi that a LCD DATA command would be great to have. Another way to accomplish it is to tweak the current LCD firmware code and allow for zero values for the line and column parameters. Current command [code] LCD line, pos, Text$ [/code] Same syntax only zero for the line and pos parameters. [code] LCD 0, 0, Command$ [/code] Maybe that will fit and is easy to add. Microblocks. Build with logic. |
||||
| MOBI Guru Joined: 02/12/2012 Location: AustraliaPosts: 819 |
If the LCD CLEAR command is expanded to have a parallel name, instead of just being able to send the one command (in this case, clear screen is "1"), allow a variable from 0 to 255 which gives you all the LCD functions. (command 0, I believe is master reset - but will have to confirm that.) There should be almost zero extra overhead needed as LCD CLEAR and "all command options" is the same command except that a constant is replaced with a variable. I don't think the extra commands will allow things like "centre justified text", I think you will just have to do a BASIC work around, though you might achieve it with "scroll left and right" commands cleverly used. Either way, I think that is going to be beyond the entry level user. @TZA, that is also an option however, I think that when it comes down to bytes saved, expanding the LCD CLEAR function would win. It just goes to show what possibilities are that we haven't come across yet. uMite is still in its infancy?? David M. |
||||
vasi Guru Joined: 23/03/2007 Location: RomaniaPosts: 1697 |
Lets see if implementing either NRF24 or RFM12 is possible in the remaining flash and then I'm sure such an "LCD Command" will not be hard to add (or maybe RF won't be possible at all, and then will be a lot of space to refine everything in this firmware to assure a winning product). Hobbit name: Togo Toadfoot of Frogmorton Elvish name: Mablung Miriel Beyound Arduino Lang |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3196 |
I thought that I would add a LCD CMD and LCD DATA command (it should not take long) and see how much space is taken up. If I run short of flash later on they can be the first to go. I am also thinking of a format function like: s$ = FMT$(nbr, m, n) where nbr is the number to be formatted, m is the number of characters before the decimal point (will be blank padded), and n is the number of characters after the decimal point (zero padded) and if zero just a whole number will be produced. Geoff Geoff Graham - http://geoffg.net |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2350 |
i really don't see how it will remain. the interpreter will treat (for example) "C20" as any other variable or constant, substituting the value of 1020 for it. the code that handles the horizontal positioning will then see 1020 as the X offset, and can interpret it as a command for centreing, etc. the need to detect the text string "C20" is replaced with the need, at a lower level, to detect the value 1020. when using NaN 'values' the detection part needs to be a little more robust. the C language that MMbasic is written in will probably be ok with straight comparing such values, but will likely hiccup with anything more complicated. the MMbasic interpreter may need to use a routine specific for detecting NaN's and converting them into something more useful. but this is a short routine that needs to be written just once. an additional advantage of using NaN's is that the person coding in basic is limited in what they can do with them beyond what the MMbasic author wishes to allow. i've used such methods before with good results. i'd be interested to hear geoff's take on the idea. rob :-) addendum: a quick check reveals that IEEE 4-byte reals with an exponent of FFh can be used for signalling, with a non-zero 23-bit mantissa free to be used as the signal. detecting can be carried out in C by simply re-casing the 4-byte real as a 32-bit integer. |
||||
| paceman Guru Joined: 07/10/2011 Location: AustraliaPosts: 1329 |
That'd be excellent Geoff and as you said they can go if necessary. I think they'll be good for a lot of people, especially the more 'amateur'. Many thanks. Greg |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
Question about micromite beta 7… I'm using pin 16 as a counting pin, i.e. "setpin 16, cin", immediately I type "print pin(16)" and I get the value of 1. Should this not be 0 right after the setpin command? When I send 100 pulses, I get a value of 101. Thanks again for your help. |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2817 |
I can confirm the same as viscomjim on a 44pin TQFP (using pin 44 as counter input). I have ensure no floating input although Im sure Geoff would have accounted for this using internal pull-ups. According to manual on Page 23, the counter should be set to zero. For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
| viscomjim Guru Joined: 08/01/2014 Location: United StatesPosts: 925 |
I kinda wish I could test it on a 44 pinner… Are you using your new board WhiteWizard? |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2817 |
Just tested on one of my 11 prototypes. Yet to populate a new PCB as they've only just arrived and its now late here in UK so will solder in morning in daylight! PM me if you wish me to send you a board! For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3196 |
Pin 16 could be floating high at the start and that could account for the extra count. The count is done on low to high. Geoff Geoff Graham - http://geoffg.net |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2817 |
Hi Geoff, I have tested the above with the same effect on the 44pin TQFP and also get an initial count of one even when ensuring no floating input. Tied to ground with autosave on. Reboot and immediate value of one. Frequency does return correct value though! Regards, Phil For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
Lou Senior Member  Joined: 01/02/2014 Location: United StatesPosts: 229 |
viscomjim wrote: Question about micromite beta 7… I'm using pin 16 as a counting pin, i.e. "setpin 16, cin", immediately I type "print pin(16)" and I get the value of 1. Should this not be 0 right after the setpin command? When I send 100 pulses, I get a value of 101. Thanks again for your help. Tried the same here on 28 pin device using pins 15, 16, 17 and on 44 pin device using pins 42, 43, and 44 with same results. IR modules are hooked up on pins 16 (28 pin device) and 43 (44 pin device), didn't test pins 18 (28 pin device) or pin 1 (44 pin device) because LCD displays are hooked up there. Scope shows count pins are HiZ state when configured as counters, not pulled up. Test Program: setpin(16),cin 'or pin under test do print pin(16) 'or pin under test pause 500 loop Prints 1 when program starts with pins pulled up or down. On IR pins count goes from 1 to 40 when key pressed and increased by 39 with every key pressed on the remote so counting is consistent on both devices. Hope this helps. Lou Microcontrollers - the other white meat |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3196 |
Sounds like a bug... thanks. I will look into it. EDIT: Yes, it was a bug. Thanks very much - I would never have found that one. It will be fixed in Beta 8, due out almost immediately. Geoff Geoff Graham - http://geoffg.net |
||||
| Page 7 of 7 |
|||||
 Print this page |
