Jump to content
43oh

Blairo

Members
  • Content Count

    19
  • Joined

  • Last visited

Reputation Activity

  1. Like
    Blairo got a reaction from bluehash in 1602 LCD connected via I2C to MSP432 fails to show every character   
    It works! 
     
    I modified the initialization procedure a bit, similar to what you suggested and as the Raystar's documentation sheet said. Did not pay attention to that before, looks like the wrong initialization was the most likely culprit - not |'ing the command with Enable. Anyways, here's the init procedure for blinking, backlight on, right incrementation:
    sendCommand(0x30); //function set sendCommand(0x40); //function set sendCommand(0x34); sendCommand(0x40); //function set sendCommand(0x34); sendCommand(0x0); //display on sendCommand(0x3C); sendCommand(0x0); //display clear sendCommand(0x20); sendCommand(0x0); //entry mode set sendCommand(0x38); Everything works correctly now when sending command bytes over using the way described above. Thanks again!
  2. Like
    Blairo reacted to terjeio in 1602 LCD connected via I2C to MSP432 fails to show every character   
    @@Blairo Ok, maybe enough information to be able to help some more now ;-)
     
    The En pin needs to pe pulsed high for a little over 50 ns to clock the data into the display, I would think you need to do that for the initialization sequence too.
    The enable cycle time is 1.2uS min - which means there should be no need for delays while sending a nibble, you only need to wait a bit after each byte is sendt to allow the display time to process it (IMO). There is no need to negate the En bit either ( & ~En) as the En bit is not set in your data from the previous command.
     
    I would suggest you try to do the transfer in functions, something like this (not tested):
    void sendData (unsigned char byte_data) { unsigned char Nibble = (byte_data & 0xF0) | Rs; I2C_masterSendSingleByte(EUSCI_B0_MODULE, Nibble); I2C_masterSendSingleByte(EUSCI_B0_MODULE, Nibble|En); I2C_masterSendSingleByte(EUSCI_B0_MODULE, Nibble); Nibble = ((byte_data << 4) & 0xF0) | Rs; I2C_masterSendSingleByte(EUSCI_B0_MODULE, Nibble); I2C_masterSendSingleByte(EUSCI_B0_MODULE, Nibble|En); I2C_masterSendSingleByte(EUSCI_B0_MODULE, Nibble); __delay_cycles(1000); } void sendCommand (unsigned char command) { I2C_masterSendSingleByte(EUSCI_B0_MODULE, command); I2C_masterSendSingleByte(EUSCI_B0_MODULE, command|En); I2C_masterSendSingleByte(EUSCI_B0_MODULE, command); __delay_cycles(1000); } Your init sequence seems a bit odd too - for 4-bit I think this may be more like it:
    sendCommand(0x30); sendCommand(0x20); sendCommand(0x80); // 2 lines, 5x8 dots sendCommand(0x20); sendCommand(0x80); // 2 lines, 5x8 dots sendCommand(0x00); sendCommand(0x80); // set D C B bits as needed sendCommand(0x00); sendCommand(0x10); // clear display sendCommand(0x00); sendCommand(0x40); // set I/D & SH as needed but then I may be wrong - chinese datasheets are sometimes not easy to make sense of...
     
  3. Like
    Blairo reacted to Fmilburn in Connecting MSP432 to 1602 LCD via I2C   
    Sorry @@Blairo, I have not mixed Energia and CCS with the MSP432 and have only used the method in the tutorial. Perhaps someone else can help.
  4. Like
    Blairo reacted to Fmilburn in Connecting MSP432 to 1602 LCD via I2C   
    Hello @@Blairo
     
    A while back I made a 43oh post with Energia examples here:  http://forum.43oh.com/topic/8766-sensor-code-examples/
     
    Follow the github link to find them.  The one named I2C_LCD has been tested on the MSP432 and should work for you.  However, you will need to do the following:
    Make sure you do level conversion - the LCDs are usually 5V devices The example is for the F5529.  For the MSP432 you need to connect SCL and SDA to pins 9 and 10 respectively.  There is a footnote to this effect in the code The example is for a 4x20 LCD.  If you are using a 2x16 you need to change the variables rows and columns to 2 and 16 respectively. Make sure I2C address is correct for your LCD. Let me know if it works....
  5. Like
    Blairo reacted to tripwire in Energia-written program runs faster than CCS equivalent   
    Yeah, I was surprised it worked at all without VCORE1. The chances are that the MCU would flake out and crash or reset if your program did anything too demanding at 48MHz with VCORE0.
     
     You can go a lot higher by using the timer peripherals instead of bit-banging the port with the CPU. You can also output one of the clocks (MCLK or SMCLK, can't remember which) to a particular port pin. That's useful if you just need a fast square wave for some reason.
     
    There's also the option of using DMA to write to a port, but then you you have to set 8 pins at a time (ie the whole port has its eight bits overwritten).
     
    Similarly, the CPU can toggle a pin faster if you don't make it read the current state of the port. Read-modify-write operations (as they're called) are relatively slow on ARM cores because you have to load values into a CPU register to modify them, then store them back to where they came from.
     
    For instance, you could replace your loop with:

    while (1){ P6OUT = BIT4; P6OUT = 0; } or something like this:
    unsigned char P6Bit4Off = P6OUT & ~BIT4; unsigned char P6Bit4On = P6Bit4Off | BIT4; while (1){ P6OUT = P6Bit4On; P6OUT = P6Bit4Off; } In either case the CPU doesn't read the current state of the P6OUT during the loop, it just writes to P6OUT. The other pins end up as zero in the first case, or retain the value they had before the loop started in the second.
×
×
  • Create New...