Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
8 years, 2 months ago.
Freetronics 16x2 LCD nucleo STM32F072RB
Hi all
Freetronics 16x2 LCD nucleo STM32F072RB
I have programmed the nucleo board with the example program included on the component page. I checked the pins listed in the freetronics constructor and they match the arduino header on the nucleo board. The project also compiles correctly. The display only shows squares in the top row.
Not sure how to diagnose. Any hints or tips would be much appreciated.
Cheers Christian
Edit:
Sorry about that here is the code from the original freetronics example project. I was just importing the freetronics example and using the original pins(arduino header names) as the lcd is plugged into arduino socket on the nucleo.
/* Copyright (c) 2010-2011 mbed.org, MIT License
*
* Permission is hereby granted, free of charge, to any person obtaining a copy of this software
* and associated documentation files (the "Software"), to deal in the Software without
* restriction, including without limitation the rights to use, copy, modify, merge, publish,
* distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in all copies or
* substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING
* BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
* DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
*/
#include "mbed.h"
#include "freetronicsLCDShield.h"
freetronicsLCDShield lcd(D8, D9, D4, D5, D6, D7, D3, A0);
int main() {
// turn on the back light (it's off by default)
lcd.setBackLight(true);
// print the first line and wait 3 sec
lcd.printf("mbed application");
wait(3);
// print the counter prefix; the number will be printed in the while loop
lcd.setCursorPosition(1, 0);
lcd.printf("counter");
int i=1;
while (i++) {
lcd.setCursorPosition(1, 8);
lcd.printf("%d", i);
wait(0.001);
}
}
Also here is the code with pin changes for the library you have suggested. This gives a different result the screen is now completely blank. Sorry I'm not sure where you mean to change the pin definitions are you talking about in the TextLCD constructor or is there another file to edit in the library.
// Hello World! for the TextLCD
#include "mbed.h"
#include "TextLCD.h"
TextLCD lcd(D8, D9, D4, D6, D7, D3); // rs, e, d4-d7
int main() {
lcd.printf("Hello World!\n");
}
Question relating to:
1 Answer
8 years, 2 months ago.
Hi Christian. I can confirm that your style of display with the HD44780 (or compatible) LCD controller functions well with the same target Nucleo board (STM32F072RB). We are using the same text display for a pending project as of last week. However, we are testing with a different library:
https://developer.mbed.org/components/HD44780-Text-LCD/
Consider to test the above library but map the pin definitions to match your shield. The code works well with our 16x2 text display powered from +5v (the 3.3 volt logic levels are fine with this target display / controller). Since you can see the cursors, assuming your contrast adjustment is also fine. If you still have issues, consider to share your pin definitions which we found to be the root cause of our earlier errors - we applied the use D0 & D1 pins on the NUCLEO STM32F072RB board but they cannot be used since these same D0 & D1 pins map to the onboard debug UART interface !! After fixing this error, an hour later, we had the display operational. Good luck !
Hi. Thanks for your code post. Your shield has fixed pin mappings so you must be careful on the passed parameters for the library. Our LCD display is free floating so we can wire up any way we wish and have used a different wiring diagram.
Please try again with your module using this code:
// Hello World! for the TextLCD
#include "mbed.h"
#include "TextLCD.h"
TextLCD lcd(D8, D9, D4, D5, D6, D7); // rs, e, d4-d7
int main() {
lcd.printf("Hello World!\n");
}
The pin mappings for your display was sourced from this webpage:
http://shieldlist.org/freetronics/16x2lcd
Please post your results after testing.
Sanjiv Hello World!
Sorry for the late reply. Thank you very much it is now working. You are a legend. I would also like to remark that the link you sent me to is a slightly different model. Here is the unit I am using. This is just for other peoples reference. http://www.freetronics.com.au/products/lcd-keypad-shield https://cdn.shopify.com/s/files/1/0045/8932/files/16x2LCDShieldv2.pdf
Also just going back to the original freetronics (first) code example. the pin list for the Freetronics lcd constructor has the same pins listed as the functioning one but with the D3 and A0 added to the end. Do you know why that would not work ?
Thank you again
posted by 10 Feb 2016Hi Christian. Very glad to hear your display is working. This test was to confirm that your shield and LCD display are not damaged using the same working code as ours. The shield you own features a back light control and also push buttons that can be read using an analog to digital pin on your MBED. The shield features resistors configured as voltage dividers which vary depending on the pushbutton you press. Respectively, for each pushbutton press, the analog voltage will change and the MBED code will read this voltage to decipher which pushbutton you selected. The back light feature is nice to have if you plan to use your display in a dark situation. We do not have this feature on our display. In the absence of the use of this pin, the circuit by default ENABLES your backlight control. So the code we are both using is not enabling nor disabling your backlight and also is not capable of reading the pushbutton values from your shield. Now, I would recommend that you attempt to debug the original code now that you know your shield is working. Proceed as follows, be sure to use the proper pin mappings (as you have done). Is your MBED library up to date ? You can do this check by selecting the MBED label in your workspace for this project -> review the status of the library on the right side of your compiler screen. We just imported the Freetronics project and found that the supplied MBED library is old and needs to be updated. This is a simple UPDATE button selection. This update may very well fix this project to be compatible with the Nucleo STM32F072RB board. Keep in mind that MBED solutions are meant to be generic but sometimes the routines are not perfected for every hardware target board (ie. this LCD project uses a lot of required delays in the code to R/W or initialize the display for 4 bit mode, etc. - if the delays are not properly timed, the display will fail to operate). This is a key reason to be up to date on your MBED libraries. Other suggestions are to review the LCD routines, module at a time against the working code and also the LCD controller data sheet. I would consider to even replace the wait() routines with wait_ms(). Something simple is breaking the original code and most likely only because you selected a different target board as compared to the author of this LCD code. Wish you luck and have fun with your experiments while you learn more about MBED and LCDs ! Knowledge is truly priceless.
https://developer.mbed.org/forum/bugs-suggestions/topic/4913/
Perhaps the above issue is related to this case. Updating the MBED library to the latest may resolve the quirk.
Update - just reviewed the working source code from MBED and that library is also using the working wait() routines. So that should not be the fault. I would focus on trying to compare how the LCD display is initialized against the 2 different code routines. Again, something minor is breaking the code. You should be able to nail the root cause after a bit of trial and error.
posted by 10 Feb 2016