AVR Freaks

Editorial note:  IMO, what a convoluted mess for "generic" init.  And one still has to examine and tailor every line that might be pertinent.

Someone (perhaps the same person that encouraged gratuitous use of |= ) must have brainwashed trained that pointers and a level of indirection is the One True Way.  Regardless of cycle efficiency or code size efficiency or introducing possible RMW effects.

If you put it on any portc pin the result is the same brokenwaveform.png

I don't understand your comment with the |= ...? how else would you set values to the port with not affecting other bits of that port. Also how could I clean up the Init function but still have the same affect as what its doing now? As of now that was the only way I could think about doing it without touching the rest of the functions so that I can easily put the wires on any port/pin combination. I wanted to make it so that way whatever pin was available after wiring up sensors and such, it would only be a few lines of code to change. The way it is now all the pins are isolated from one another in a sense.

Sorry if it seems inconsistent! The result of using portc pin 3 or 5 results in the same brokenwaveform.png. Currently I didn’t hook up the AVcc pin , I didn’t realize it was a requirement. I read the data sheet and will try hooking it up later after work. However, pinc5 and pinc4 appear to be powered with digital power (Vcc) and the rest of port c is from Avcc. As I mentioned previously the code responds the same way as the brokenwavform.png when on pin 5 regardless of what the code shows I tried them all! The only thing I didn’t try is connecting Avcc.

Thanks
Justin

1.1.7
AV CC
AV CC is the supply voltage pin for the A/D Converter, PC3:0, and ADC7:6. It should be externally connected to V CC ,
even if the ADC is not used. If the ADC is used, it should be connected to V CC through a low-pass filter. Note that
PC6...4 use digital supply voltage, V CC .

Note that that isn't really what I said...

Someone (perhaps the same person that encouraged gratuitous use of |= ) must have brainwashed trained that pointers and a level of indirection is the One True Way.  Regardless of cycle efficiency or code size efficiency or introducing possible RMW effects.

In no particular order:

-- Why are you trying to make your own 4-bit HD44780-compatible LCD driver?  What is wrong with the existing implementations?

-- There are other "generic" implementations like Fluery...

-- ... but they resolve things at compile time, and are thus fairly efficient.

-- Generally, when common 'Freaks like me create an AVR8 app, it is a microcontroller and we try to make things compact and efficient..

-- Your approach will be bloated on code size.  It will be bloated in cycles used.  It will waste microcontroller time at the millisecond level.

-- Depending on the rest of the app it opens the possibility of RMW effects.

This isn't like a professional project, I like and prefer to try and code my own things. Its nice tho because problems like this help me and others learn. I just found the problem and fixed it.

1) I connected AVcc to power and that didn't fix the issue

2) to fix the issue, in the header file  I changed my struct to volatile uint_8 and now the code works. So now I can just change the mappings in the init function and I can put the LCD pins anywhere.

typedef struct{

      volatile uint8_t pin;

      volatile uint8_t *port;

      volatile uint8_t *portd;

}PINDATA;

typedef struct{

      PINDATA d7;

      PINDATA d6;

      PINDATA d5;

      PINDATA d4;

      PINDATA rs;

      PINDATA enable;

      PINDATA backlight;

}LCD;

I realize this is not how others would implement this but I was trying something different,

Thanks for all the guidance, your comments forced me to look further into other topics and it was quite useful

When you were old enough to want to drive an automobile, did you build your own?

2) to fix the issue, in the header file  I changed my struct to volatile uint_8 and now the code works.

I was pondering your symptoms, even in the light of inconsistent example evidence.  Then, when you presented your "fix", more pondering ensued.

This is one of the cases where indirect access to I/O can bite.  As mentioned earlier, OP loves pointers and indirection.  Without the volatile a simple extract of your code such as

     *data->enable.port |= 1 << data->enable.pin;
    ...
    *data->enable.port &= ~(1 << data->enable.pin);

 

...looks like it "doesn't work", as the optimizing compiler will see that the code sequence does nothing useful.  Did you look at the "doesn't work" generated code, or present it to us for examination?

Now, why port B "works" is levt as an exercise for the student.