AVR Freaks

Been there.  Done that!

Thanks!  I know the datasheet says 2.7V, but it also says 400ns clock and I know it will run at 300ns.  I've been scratching my head over this for the last day or so and it is getting a bit irritated.

Well, I might have found the problem.  The datasheet I have says the ST7920 works from 2.7V to 5.5V.  I just found another datasheet that states 4.5V to 5.5V...  Given the age of this board (mid 2000's), that is MUCH more believable to me.

I've got a couple of SPI level shifter ICs on order, so I should know in a few days.

Thank David!  I'll dig back into the datasheet and see exactly what it has to say about the VOUT configuration and see if I can get that working.  If not, I'll try it on Thursday when the level translators arrive.  Currently, I have a mix of 5V megas (and tinys) and 3.3V xmegas, so using an external level translator is probably the best bet at this time.  Of course, that all depends on what project this thing ends up in.

I really appreciate you looking into this for me!

I tried it at 5V on the display and at least got a stripe of noise at the top of the display.  Of course, I might have messed up the u8g code with all my "testing" so I need to go through it before I try it again.  If not, the level translators should be here tomorrow. 

But seeing some pixels light up is a positive result!
 

Well, the level translator got things talking.  Noise is an issue now with my test setup (no surprise actually), so I'm going to make up some short cables and see if that gets things cleaned up enough so I can move on with the testing.  I really wish this display used RS485 instead of SPI...

It basically IS ported.  They way u8g has the hardware abstracted, it was very easy to modify the avr/arduino code to work with the xmega.  I just need to go through it and use there method of use ifdef <__blah__> to add new sections for the xmega and basically copy and edit the "mega" hardware files to make new ones for the xmega.  My current hack is just to edit the existing avr code to work with the xmega, so that is no good for integrating it into the code base.

Yes.  In the avr branch of u8g it has sections for atmega and arduino already defined.  I've already added the xmega sections like you have shown.

That is what I am working on now.  When I first edited it to test, I just hard coded SPIE and PORTE and I had to bypass the pin mapping OR and ANDing stuff.  Getting that to work in the GENERAL case is quite a bit trickier than the specific case!

We need to be able to specify exactly which SPI unit to use as the xmega has multiple units and more than one may be in use, so I have edited the function definitions to take an additional SPI_t argument.  I'm trying to get around also having to pass an additional PORT_t argument as well (see other thread I just created).

I'm not sure how I am going to handle the pin mapping stuff u8g uses.  My instinct says to handle it with #defines in the u8g.h file, but I have no idea if my instincts are correct on this.  For example, this bit of code:

case U8G_COM_MSG_RESET:
      u8g_SetPILevel(u8g, U8G_PI_RESET, arg_val);
      break;

from u8g_com_atmega_st7920_hw_spi.c handles setting and clearing the reset pin on this display and u8g_SetPILevel is defined as:

void u8g_SetPILevel(u8g_t *u8g, uint8_t pi, uint8_t level)
{
  uint8_t pin;
  pin = u8g->pin_list[pi];
  if ( pin != U8G_PIN_NONE )
    u8g_SetPinLevel(pin, level);
}

which if you follow the u8g_SetPinLevel function through you finally get to a define like

#    define U8G_ATOMIC_AND(ptr, val) 	do { uint8_t tmpSREG = SREG; cli(); (*(ptr) &= (val)); SREG = tmpSREG; } while(0)

And that is going to have to be edited to work with the atxmega chips.  Well, at least I THINK it is going to have to be reworked!  My memory tells me this would not work with the xmega and I changed it (hard coded) in my tests to a "normal"

PORTE.OUTSET = PIN3_bm;

for example.

Which brings up a question that I hope someone here can answer:

Do we need to worry about writing interrupt safe code by disabling and then reenabling interrupts around the .OUTSET amd OUTCLR calls?  I would think the answer to that is "no", but my thinking has gotten me into trouble before...

I think I have about convinced myself that I am just going to #define this problem away, at the cost of making the code a bit harder to read.  The bright side, it is a method already used in this code fork!  For example:

#if defined(__AVR__)
... All the standard AVR specific stuff such as...
void u8g_i2c_init(uint8_t options)
{ hard coded to SPI unit here }

void blah(blah) {}
...
...

#elif defined(__AVR_XMEGA__)
-- The new ATXmega specific code such as...
void u8g_i2c_init(SPI_t SPI, uint8_t options)
{ Configures specific SPI uint as passed by the SPI variable }

void blah(SPI_t SPI, blah){}
...
...

#endif

The other approach WOULD lead to simpler code base, but it would further splinter ug8.  Right now, the AVR related stuff is in it's own fork.  This includes the run of the mill AVR code as well as the Arduino stuff.  I'm currently trying to fold the xmega code into this fork by creating new blah_atxmega_hw_spi.c (or what ever) files and then editing the u8g.h and other files to integrate them.

At this point, I'm not too sure it doesn't make more sense to create a pure xmega fork and be done with it.  That would get rid of a LOT of junk that just isn't needed and make it easier to read.  It would help keep the original AVR code "easier" to read as well.

With a "pure" xmega fork, I could rewrite all the initialization stuff to use an SPI variable.  I also probably wouldn't waste my time porting the software SPI stuff either (why when you have so many hardware SPI ports available?).  I would also drop a lot of the #define stuff they did to allow it to work with so many different architectures.

One reason I am thinking of going this route is that the majority of the u8g code is NOT hardware specific at all, so newer releases could still be used with this hardware specific code with no issues or with fairly simple edits.

Any thoughts on this?

Having thought about this for a while, I have decided that I am going to go the fork it route.  There is a LOT of crap in the arduino side of the house, so dumping ALL the avr mega stuff would clean things up quite a bit (including a butt load of "#ifdef blah" statements) and would create a stand alone library for the xmega.  Then I could edit it to directly support the xmega without worrying about breaking anything on the other platforms.

That is the upside.  The downside is I am heading to Alamogordo in the morning for a few days to take care of a few projects for my mom, so I probably won't get back to this until this weekend.

Oh well.  Gives me brain time to think about how I want to implement this.

Some.  I just got back from Alamogordo and I have started to clean out the u8g.h file.  I should have time to finish the edits tomorrow.