 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 : ALL "mites" - a thought for an extensible LCD_INIT approach
| Author | Message | ||||
| BrantB Newbie  Joined: 27/10/2017 Location: CanadaPosts: 40 |
This one is likely aimed primarily towards Geoff for consideration, but certainly Peter may also have some valuable insight/input. I have a number of ILI9341-based IPS LCD screens, and it seems that they operate (natively) in an 'inverted' colour mode - where black is displayed as white, and white is displayed as black, and all of the other colours in the spectrum in between are like looking at a negative film strip. Oh boy - I just dated myself. I do recall the days why you actually had to put FILM in your camera, and then develop it with horrible smelling chemicals. But enough about memory lane. A picture is worth 1,000 words ... so, here is a picture of what the tiger BMP looks like on my IPS screen: .jpg) Because my needs (so far) have not involved bitmap graphics, I found it easy enough to work around the issue by defining my own constants, like this: CONST MyWhite = RGB(WHITE) XOR 16777215 CONST MyBlack = RGB(BLACK) XOR 16777215 CONST MyBlue = RGB(BLUE) XOR 16777215 CONST MyGreen = RGB(GREEN) XOR 16777215 CONST MyCyan = RGB(CYAN) XOR 16777215 CONST MyRed = RGB(RED) XOR 16777215 CONST MyMagenta = RGB(MAGENTA) XOR 16777215 CONST MyYellow = RGB(YELLOW) XOR 16777215 CONST MyBrown = RGB(BROWN) XOR 16777215 CONST MyGray = RGB(GRAY) XOR 16777215 Then, as I was printing text or drawing lines, I would just refer to my own constants rather than using the ones built into MicroMite. However, I now find myself with a need for some background graphics (BMPs), so this workaround will no longer ... er, uh ... work.  According to the ILI9341 datasheet, the controller has a pair of commands that determine the display's behaviour (i.e., inverted and non-inverted), which are as follows: 20h = Display Inversion OFF 21h = Display Inversion ON I know this is the key to success (specifically, the 21h command), as I have used these displays with other microcontrollers (and other programming environments). Unfortunately, I do not think there is a way in MM to issue such commands directly to these types of intelligent LCD controllers. I tried messing about a little bit with the LCD CMD (and LCD DATA) directives, just in case their capabilities were actually more extensive than described in the manuals - but, not surprisingly, I did not meet with any success. (I believe that LCD CMD and LCD DATA really are intended to be used only with 1, 2, and 4 line text LCD displays.) As I see it, there are a few ways this problem could be addressed. One would be to add some kind of optional "inversion" parameter to the OPTION LCDPANEL directive - such that the appropriate hex command would be sent (if required/desired by the user). The downside to this is that it would only address this specific problem - and there may be other potholes experienced by other users which could be smoothed over with a more universal approach. Also, I am not sure if this would mean a modification to each discreet display driver (SPI, 8bit, 16bit) - which could get a bit tedious for Geoff/Peter. Another solution would be to extend the LCD CMD (and LCD DATA?) command so that it does support communication directly with the intelligent LCD controllers, and not just the text-based LCD units. Since these commands already exit, it would not take up any more valuable tokens in MM (correct?). Lastly - and I think this is the more elegant ... though, admittedly, more complicated approach - there could be provision for an optional LCD_INIT routine which fires if the label is present. In a way, it would be a similar concept to some of the optional interrupt capabilities which exist for other MM commands (eg. the "done" interrupt for PLAY FLAC command). In other words, for any given display driver built into MM, it would look to see if LCD_INIT exists (or whatever label Geoff/Peter prefer to designate). If it does, then execution would be handed off to that routine, so that the user could issue any additional commands which may be required by a given controller, for a given circumstance. Once those commands had been issued, execution would return to the display driver for any final housekeeping, etc. Of course, this still leaves the challenge of how, exactly, to communicate those additional setup commands directly to the intelligent controller - and this may be where extending the capability of LCD CMD might come into play. I welcome any insight or thoughts that Geoff / Peter might be willing to share. |
||||
Geoffg Guru  Joined: 06/06/2011 Location: AustraliaPosts: 3308 |
Firstly, your problem with the LCD TFT display has already been covered in V5,05.03. From the change log: MMBasic does have the ability to add your own drivers written in BASIC but what you are discussing is a way to hook into the existing built in driver. The only issue that I can see is, does the hook work before or after the unit sequence? And if you do that you might also want to hook in whenever data is sent to the display. Interesting suggestion but it needs some thought. Geoff Geoff Graham - http://geoffg.net |
||||
bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2971 |
Hi Brant, Honestly I have never seen these inverted by default screens, but then I am not that experienced with them. As you have a work around for text why not a work around for your BMPs? Use photoshop or similar and invert your images and use these then they should display correctly for you. Kind Regards, MICK Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2831 |
If Geoff's solution doesn't work on your panels then Bigmik's idea is practical. As images usually need to be preprocessed in a graphics program to get the right dimensions any way, it's just one more click to invert colours . IrfanView has an "Invert Colours" button, can do batch conversion of many image properties simultaneously on a large number of files. And it's free. |
||||
| BrantB Newbie Joined: 27/10/2017 Location: CanadaPosts: 40 |
@Geoffg: Wow. Not sure how I missed that. Probably because my "recent" efforts (last 18 months) have been on the bigger chips - mostly MMX on the PIC32MZ, and much more recently, ARMmite on the H7 ... so I have primarily been following announcements related to those. But thanks for the tip about ILI9341_I. I am not at our R&D lab right now, so I can't say this with certainty, but I get the impression that ILI9341_I support probably does not extend to the 16bit interface (nor the 'bigger' environments like MMX, H7, etc.). My next time slot at the lab will be Thursday (it is late Tuesday night, here, right now), and I will do some more investigating then. @BigMik I guess I was standing too close to a tree to be able to see the forest  . Processing the BMPs externally seems so obvious now. @phil99's point about there typically being a need for pre-processing is a good one.I don't have enough "samples" to be able to draw a strong conclusion based on irrefutable scientific method ... but, for what it is worth, I suspect the different behaviour (of my screens) has a lot to do with the IPS technology versus TFT. That is just a hunch. A while ago, we had a substantial project which required readability in sunlight, so we sourced several 2.8" IPS screens (which happened to have the ILI9341 controllers). Because we ended up with quite a stock of them, they tend to be one of our go-to pieces for new projects (where a small screen is appropriate). These are just the LCD panels themselves with the FPC ribbon "cable" - they do not have any integrated "backer" PCBs. This was driven by space constraints and certain mounting requirements in a small enclosure, in our initial project. So, we ended up having to design our own "carrier" PCB (passive - no active circuitry) for the display, and the FPC cable connects directly onto our custom application PCB. Here are a couple of pics of the project that started it all ...   The IPS screens are absolutely fantastic. I love how crisp and bright they are. Someone would have to twist my arm quite aggressively to get me to switch back to TFT. Even as we move up in size (which I anticipate we may have to do in an upcoming project), we will be looking at IPS - likely based on an SSD1963 controller, or similar. At any rate, @Geoffg, providing hook-in routines may be something that is still worthwhile pondering. If you don't want to provide two hooks for start-of-init and end-of-init sequencing, then my vote would be to at least provide a single end-of-init hook. It seems to me that this would put the responsibility - and flexibility - squarely in the hands of the programmer. He/She would need to make sure that the additional commands being sent did not interfere with what MMBasic had already set up. In the most extreme case, this would actually allow for a completely customized initialization of the display, where the programmer essentially starts with a reset and handles the whole set up redundantly (with any required custom commands interspersed where they need to be in the sequence). A start-of-init hook would not provide this advantage. I do agree wholeheartedly - it requires some thought. |
||||
| BrantB Newbie Joined: 27/10/2017 Location: CanadaPosts: 40 |
@MatherP: Could you please confirm for me that there is no ILI9341_I support in the ARMmite series (H7, F4, L4)? I ask, because I did some experimenting in the lab today on an H7 and no matter what combination I tried, I kept on getting various syntax related errors when attempting various OPTION LCDPANEL commands. (Yes, I had first done OPTION LCDPANEL DISABLE prior to experimenting  .)I tried: OPTION LCDPANEL ILI9341_I_16 OPTION LCDPANEL ILI9341_16_I OPTION LCDPANEL ILI9341_I16 OPTION LCDPANEL ILI9341_16I For each of those, I got back "Error: Argument count". I also tried tacking on an orientation parameter in each case, just in case that was the issue, but it did not help. Interestingly, I got a different type of error ("Error: Invalid display type") when I tried the SPI version as follows: OPTION LCDPANEL ILI9341_I, P, 55, 54, 53 So, this leaves me with the distinct impression that the inverted version of the ILI9341 driver (i.e., ILI9341_I), which @Geoffg previously referred to, is not supported in the ARMmite branch of the family tree. Cheers. |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8297 |
It may not be supported at the moment, BrantB. It was added to the other branches as an extra whereas the 32-pin version of the ILI9341 is the standard for the F4. It probably wasn't anticipated that an inverted version might be used. Peter might be able to give more info when he reappears late next week. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| BrantB Newbie Joined: 27/10/2017 Location: CanadaPosts: 40 |
True - I should have acknowledged knowing that Peter was away, and indicated that I did not expect an immediate answer. I sure hope he is getting some R&R, as he certainly deserves it. The man is a coding machine, and I'm not convinced that he ever sleeps! |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
