 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 : MM/MM+ 5.2/6.0?
  Page 5 of 7   |
|||||
| Author | Message | ||||
| piclover Senior Member  Joined: 14/06/2015 Location: FrancePosts: 134 |
Seconded, and easy/cheap to implement... |
||||
| Nathan Regular Member  Joined: 10/01/2016 Location: GermanyPosts: 49 |
Dear Geofff, >Sometime ago someone asked for >Quote: >This ability to have transparent backgrounds on the Text statement. At the moment it >draws the background colour and this cannot be disabled. > >While working through my ToDo list I have reached this and just realised that it is >harder than it seems and will require reading the background back from the LCD. That >is also on my ToDo list but it will be complex to implement and won't make the next >release. > >Just in case someone is hanging out for this... >Geoff Just for information I have running transparent color and a little bit more for the ST7735 and ILI9341 also for SSD1289. All driver have the same interface. The sync option is only running for ILI9341 and allows a flicker free drawing for small shapes. Example for ST7735: ------------------- The only hardware requirement is a 1k resistor in the data line to the st77735 display orientation of drawing can be changed on the fly. ' ' init : ST7735_A0(0, CD, RST, CS, orientation) ' init : ST7735_A0(1, orientation) ' rdvram : ST7735_A0(2,v2Array,x1,y1,width,height) save screen to array ' wbvram sync: ST7735_A0(3,v2Array) write back array to screen ' wbvram : ST7735_A0(4,v2Array) write back array to screen ' bmvram sync: ST7735_A0(5,bmapArray,x1,y1) write picture data to screen ' bmvram : ST7735_A0(6,bmapArray,x1,y1) write picture data to screen ' movesprite sync: ST7735_A0(7,bmapArray,v2Array,x1,y1,vb) restore old window, save act window to v2Array, drawp bmapArray ' movesprite : ST7735_A0(8,bmapArray,v2Array,x1,y1,vb) restore old window, save act window to v2Array, drawp bmapArray ' drawsprite : ST7735_A0(9,bmapArray,v2Array,x1,y1) save act window to v2Array, drawp bmapArray Geoff, the tranparent color is also available in the demo, which I sent to you. 
Peter got the ILI9341 c-code already. Nathan |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
For Geoff: Yet another wish for a (small but I think damned useful) feature for next version: MM.SPIOPEN (and, why not, MM.I2COPEN) flags... With my last project (a meteo station with various I2C and 1-Wire sensors, an ILI9341 LCD panel and a nRF24L01+ radio module on the SPI port to communicate with remote meteo "slave" stations), I came across an annoying issue: when a touch (configured with an interrupt pin) is done on the LCD panel, the touch interrupt sub-routine calls TOUCH(X), which fails and stops the program with a "SPI open" error whenever the touch interrupt happens while the SPI port was open for comms with the radio module... I first thought about testing for the SPI enable pin of the nRF24L01+ before issuing TOUCH() commands, but since that pin must be asserted only after the SPI port is open and negated before it is closed (because the SPI pins are floating while the SPI port is closed and we don't want the radio module to pick-up spurious/random SPI "commands"), this is not doable... I could add a pull-down resistor on the SPI CLOCK pin, but it would add a little power consumption to the circuit (I need to keep dissipation as low as possible to avoid heating too much the sensors which would cause inaccuracies, e.g. on humidity readings), and if there were several SPI modules on the same port, I'd have to test for several pins, which is unpractical/cumbersome/slow. For now, I simply use a global flag variable which I set to 1 before opening the SPI port and reset to 0 after closing it; it works, but I too find it cumbersome and clumsy, especially since the MM BASIC already "knows", internally, that the SPI port is open and could let us know with a read-only flag (MM.SPIOPEN ?). The same holds true for I2C comms and the RTC command, for example (which could also be triggered by an interrupt, if the RTC module interrupt pin is in use)... Of course, the error trapping feature will also solve that issue. However, error trapping is best left to deal with unexpected errors (mostly because of bogus user inputs or hardware peripherals malfunction/glitch/hot-removal-or-whatnot) rather than used for situations that are expected to happen, even if rarely. |
||||
MicroBlocks Guru  Joined: 12/05/2012 Location: ThailandPosts: 2209 |
For the SPI could you not just do a SPI CLOSE before using the SPI OPEN. Maybe even simpler if a SPI OPEN command is given is to close the previous if the parameters are not the same as the previous SPI OPEN. A simple wrapper function could do that, even better if the firmware takes care of it. Something like the following (untested): [code] DIM PreviousSPIDevice$ OPENSPI('TEMP1') .... OPENSPI('TOUCH') FUNCTION OPENSPI(SPIDevice$) IF PreviousSPIDevice$ = SPIDevice$ THEN EXIT FUNCTION ELSE SPI CLOSE ENDIF PreviousSPIDevice$ = SPIDevice$ SELECT CASE Device$ CASE "TEMP1" SPI OPEN .... CASE "TOUCH" SPI OPEN .... END SELECT END FUNCTION Microblocks. Build with logic. |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
That won't work. Please, re-read my previous message (SPI OPEN/CLOSE happen in main loop, while TOUCH() happens in an interrupt sub-routine, that can occur during the main loop SPI transactions). First, the TOUCH() command uses an implicit SPI OPEN command, and it happens inside an interrupt, meaning that issuing a SPI CLOSE there would abort an ongoing (group of) SPI commands that got started in the main loop. You can't either do SPI CLOSE without error if the SPI OPEN was not issued first (so you must keep tack of any OPEN command, meaning there is no gain whatsoever when compared to a global flag). Forcefully closing the SPI channel is not what you want to do in an interrupt anyway (if a SPI transaction was started in the main loop, the interrupt should yield back to the main loop to avoid partly aborted SPI transactions). Also, SPI CLOSE is not enough to return the hardware into a safe state: you would first have to negate the SPI CS pin corresponding to the ongoing SPI transaction on the corresponding hardware. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10180 |
You really don't need these sort of additions. It is easy to test if SPI is open in Basic. All this stuff is in the PIC32 docs and MMBasic has the tools to interrogate. if(peek(word &Hbf805800) AND &H8000) 'test SPI open 'do whatever endif |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2428 |
i presume you are using something like the example given on page 19 of the micromite 5.1 manual: SETPIN 15, INTL, MyInt DO ' do other stuff in here LOOP SUB MyInt PRINT TOUCH(X) TOUCH(Y) END SUB change your code to be something like the following: SETPIN 15, INTL, MyInt TFLAG = 0 DO IF TFLAG THEN PRINT TOUCH(X) TOUCH(Y) TFLAG = 0 ENDIF ' do other stuff in here LOOP SUB MyInt TFLAG = 1 END SUB this moves the calls to TOUCH() out of the interrupt service routine, as well as the PRINT statement. really, an ISR should contain the bare minimum of code. goeff: it may be worthwhile changing the example code in the manual. while using a few more lines of code, the above follows better 'good programming practice'. also, i see there are references to both the 'C/D pin' and the 'D/C pin' in the manual (LCD command/data register select); these should be changed to all be the same, or better still go for 'command pin'. cheers, rob :-) |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
|
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3281 |
I can appreciate why this request is made but there is a limit to the number of special cases that can be accommodated before a language/environment becomes so complicated that ordinary users would give up using it. We could add MM.SPIOPEN but then there would be MM.I2COPEN, then MM.COM1OPEN, and so on. The simple solution is to set a flag and honour it. One of the biggest battles that I have is trying to stop MMBasic becoming bloated with features like BSD Unix or the Windows API. I know that I have only particularly succeeded but it is worth continuing the battle. So, sorry but I do not want to implement a MM.SPIOPEN when the same result can be achieved with a little extra code. Geoff Geoff Graham - http://geoffg.net |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2428 |
you may achieve better results using CPU SLEEP with a fast heartbeat signal fed into the wakeup pin. 10Hz would likely provide adequate responsiveness, and could be generated by a simple 555 timer. cheers, rob :-) |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
|
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2428 |
another small manual error: page 58, GUI TEST, sentence containing "drawn rapidly drawn". btw, i suspect TRON and TROFF could be depreciated and no one would notice. this would gain back a couple of symbols. cheers, rob :-) |
||||
| damos Regular Member Joined: 15/04/2016 Location: AustraliaPosts: 74 |
Like a lot of others, my eyes are getting too old for the really small stuff, although I am going for a long overdue trip to the optometrist. Like many others, I am not a huge fan of surface mount for prototyping projects, although it is ideal for production runs, which is not really appropriate for hobbyists. I like the MX170 a LOT. It is cheap, small and easy to use. It supports really low cost touchscreens, completely removing the need for conventional switches, LEDs, etc, which simplifies the project and actually makes it a lot cheaper. The Plus supports larger displays, but they are quite expensive, and less likely to be integrated into projects that fit into small enclosures. I am more interested in using MM as an embedded device, and not as a full computer. For larger projects I am more likely to use Raspberry Pi or a PC, which are capable of multi-tasking, have GPUs and fast screen refresh, wide support for devices, and tools like Visual Studio, .Net framework, C#, LINQ, SQL Server etc. I would like to see MX170 evolve, even if it means cutting it right back. Here are my suggestions: - get rid of legacy LCD and keypad support. They are not needed with touchscreens - get rid of the built-in editor. While it is excellent, it is a great feature for the PLUS, and MX170 can be treated like an embedded device and rely on MMEdit - get rid of error messages. We can just use codes and map them to a language file which can be included with out program. While useful for debugging, this could also be sorted with MMEdit - have 2 different binaries, one for debug mode and may include features like error strings, editor etc optimized for size, while a release mode version omits them and is optimized for speed. In terms of ON ERROR, I would really like proper exception handling, although I am not sure this is included in BASIC philosophy. My MMBasic wish list: - better debugging tools, particularly in partnership with MMEdit. I am think sort of like Visual Studio - structs, or possibly even classes, although I know BASIC doesn't really do them - collections like typical VB name-value collections - passing labels or function names as parameters, so we can implement event handlers or callbacks. Alternatively an exec function where I can call a function by supplying a string name. eg exec("Keyhit") would be the same as calling function keyhit - MM Plus dialog capabilities My MMEdit wish list: - Visual Studio style debugging in concert with MM chips. Break points, step over, step into, variable inspection windows etc - comments as discussed above with respect to option explicit. I very rarely even get compiler errors anymore in Visual Studio, because it is running my code through the compiler as I type it and underlines it when I get it wrong. A bit harder with an interpreter, but it needs an engine that can check it. You may need to get the source code for the MM intepreter and compile it into a module - multiple file support. My programs get pretty big and moving them into separate files would be good. An include function could merge them all before sending to the MM. This could also help with code reuse. - namespace support. This solves some of the issues discuss on this topic. MMEdit could combine them before sending to the MM, or just mangle them. - minifying. This is sort of a release mode, and strips out all comments, white space etc and sends a really stripped down version of the code to the MM for final release. This combined with variable mangling offers some IP protection if people want it. I use this all the time for Javascript files for web development. regards Dan |
||||
jman Guru Joined: 12/06/2011 Location: New ZealandPosts: 711 |
I strongly disagree I think the built in editor is a GREAT feature of Mite family Regards Jman |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1114 |
I STRONGLY agree with jman -keep the inbuilt editor. MMEdit is fantastic (and in fact already includes many of the "wish list" items mentioned by damos), but requires a PC to run. panky. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
| piclover Senior Member Joined: 14/06/2015 Location: FrancePosts: 134 |
Frankly, this all seems a bit too complex and out of the scope of a BASIC language... Let's keep things simple and efficient, shall we ? |
||||
| factus10 Regular Member Joined: 30/12/2014 Location: United StatesPosts: 45 |
Here's the challenge: what one user rarely uses, another uses often. And, as someone who's been through more systems than I care to count, external dependencies (editors or whatever) are a failure point. As long as this project is, essentially, a single person operation, let's avoid adding additional points of failure. And, if you're really jonesing to make the hardware work exactly the way you want it, there's always assembly, MPLAB C, mikroelektronika C/Pascal/Basic compilers and probably other options. Geoff has done a great job keeping the MM accessible yet powerful. |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9585 |
On the editor thing, I also agree that it should be kept. The editor is one of the major things that distinguish the MM from the competition. All you need is a serial terminal, and you can start programming right on the chip, without a host computer and IDE's of incomprehensible size...... Admittedly, I do not use the editor all that much myself, preferring MMEdit, as I expect, do most members here. Having said that, the built-in editor is excellent for quick stuff and to make a quick change to test something, and once you have it right there, XMODEM it back to the host computer. My 2c only...... This thread is long, and I have been catching up on it since page 4, and there has been some serious discussions going on here, which is all good food for thought. If I might offer my 2c on a couple of points raised by various members: Error messages: I like error codes for embedded chips. Message text gobbles up lots of memory. This is probably not much of an issue in the MM+, but probably is gobbling up a bit of space in the 170 MM chip. I support just having codes for the 170, and full-on text message error reporting for the MM+ - this could be looked apon as a feature of the MM+, to paraphrase the member who suggested that(piclover?) Back in my Atari 800XL days, the error codes were just that - codes. You would get an error like "Error- 170", and you would have to look up a printed table in the manuals to find out what the error meant. YES, that did cause issues even back then in the day along the lines of: "What the hell is error 170?!", but you get used to that idea quickly, and if you have the error chart handy at your workstation..... I guess it also depends on exactly how much memory you would save in the 170 by removing all the text error messages. Error handling: Looking back at the Atari again, it used to have the TRAP command, which was a line-number. The 'Trap' was set just before any routine, and remained active till another trap command was encountered. The beauty of the trap command in the Atari, was that it was global once set, and automatic - any error at any time, would cause a jump to the TRAPped line number - you did not need to check an error variable. In the MM case, you could trap a sub along the lines of TRAP ERRORS, and SUB ERRORS would process any error encountered. The one single ERRORS sub could handle any and all errors, anywhere in the code at any time. You could also have several different error-trapping subs, and select the one you want in certain areas of the code, with perhaps the main loop resetting the trap to the global one. I'm just throwing this concept out there, so there could be issues that I am not thinking of to implementing error trapping like this on the MM, but it was very useful way back in the 80's! I guess when you look at it, looking at MM.ERRNO at any point will establish if the MM thinks there is some kind of error, so it does the same thing, although you have to remember to check that variable, but that is not hard. As I say, I am just letting my memory(pun intended!) flow into this forum post via the keyboard....... Smoke makes things work. When the smoke gets out, it stops! |
||||
| damos Regular Member Joined: 15/04/2016 Location: AustraliaPosts: 74 |
I agree. Having used everything from 6805s through to Android, Linux and building large systems with many networked devices, it is clear that the MM is a world class development platform that fits within a really special niche. While the developer in me wants everything that is in C# and .Net and multitasking OSs, for the applications that MM is suited, it really isn't necessary, and have to constant remind myself of where it fits in. From the original Maximite I have watched the functionality grow constantly, and we are now hitting the limits of the device (certainly in a DIP package). At this rate, we will eventually hit the limits of the highest spec PIC chip. I can see it gaining international acceptance and being used in projects that sell in millions. My wish list was just that, and it is good to see strong reactions to what was basically brainstorming with an outsider's perspective. I like the editor, although the 80 character limit causes me a lot of problems. I do come from an IDE environment and see the power of tools like Visual Studio and Android Studio (or even what I can do in Google Chrome), and for me the debugging is a high priority. The beauty of the MM is the enormous amount of work that Geoff has put into reading through datasheets to turn what can be very complex settings into a single BASIC command that just works every time. This takes a lot of pain out of complex hardware and turns it into a snap together system. |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9585 |
@ damos - I do hope you did not feel members were getting at you. People do tend to be rather defensive of the editor, as that is the MM's main feature that makes it work so well for many people - it's self contained. Welcome to the forums, and please do not be put off by those comments - including mine. I too was just adding my 2c, and not trying to shoot down your ideas or anything.  Smoke makes things work. When the smoke gets out, it stops! |
||||
| Page 5 of 7 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
