USBwiz_lib compiler errors

Log in or register to post comments
Go To Last Post
7 posts / 0 new
Author
Message
th0th696
th0th696's picture
Level: Rookie
Joined: Sat. Mar 17, 2007
Posts: 25 View posts
Location: Austin, TX
#1
Posted by th0th696: Sat. Apr 19, 2008 - 08:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was toying with a USBwiz dev board, and have successfully gotten it to do some simple things over i2c. I wanted to make use of the library you can download at:

http://www.ghielectronics.com/de...

it is written for the MCC18 compiler, I get a little rambunctious every now and then and just tried to
slap an include into the top of some of the example i2c code from the avr-libc. i.e.:

#include "USBwiz_lib/USBwiz_lib.c"

USBwiz_lib/p18f458.h:11: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘unsigned’

the corresponding line from the aforementioned file in the error is:

extern volatile far unsigned char RXF0SIDH;

And then there is a large number that are essentially the same.

and then one other grouping of errors like this:

USBwiz_lib/p19f458.h:2238: warning: ignoring #pragma varlocate

the corresponding line:

#pragma varlocate 15 RXF0SIDH

As you can see they are both related to the same variable, so maybe all of the errors boil down to a single common foreign variable declaration. Is there an easy fix? Would it be prudent to attempt to change those variable declarations to something a little bit more familiar, or should I be enable some different C-standard or something else in my makefile, or am I fighting windmills here and this will never work?

EDIT: wanted to clarify that I am using GCC and that's why I'm posting here; additionally I'm using ubuntu 710 which means the version of GCC is 4.1.3 here

Tags:

Tools, Compilers and General Programming
Top
CountZero
CountZero's picture
Level: Resident
Joined: Thu. May 27, 2004
Posts: 678 View posts
Location: Sweden
Posted by CountZero: Sat. Apr 19, 2008 - 08:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Isn't this for PICs? In that case very wrong forum...

Top
Bronze MarkJohanEkdahl
JohanEkdahl's picture
Level: 10k+ Postman
Joined: Wed. Mar 27, 2002
Posts: 26945 View posts
Location: Lund, Sweden
Posted by JohanEkdahl: Sat. Apr 19, 2008 - 08:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The code you are working with is not written for avr-gcc. AFAIK avr-gcc does not support the keyword "far" and it does not support pragmas. You have some porting to do...

For the variables you should be able to just drop the "var" keyword. If the variables declared are registers you should probably drop the whole thing - see below...

As for the #pragma, I'm not so sure. Is RXF0SIDH a register? If so, it should be defined in the part-specific include file for the AVR model you are using and that should be pulled in automatically if you have a "standard" makefile and have set the AVR model correctly in that.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here. 

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Top
th0th696
th0th696's picture
Level: Rookie
Joined: Sat. Mar 17, 2007
Posts: 25 View posts
Location: Austin, TX
Posted by th0th696: Sun. Apr 20, 2008 - 09:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh ya, I stated up front that it was written for the MCC18 compiler, and the example code is written for the PIC, and ya those are prolly just registers. So I just commented the include for that file in Types.h. Also notice there's a bunch of types.h when they mean Types.h, probably doesn't matter on windows;p Also the interface header files are missing. Wonder what the far keyword does? Anyhow back on topic. I've seen this chipset mentioned a few times on these forums has anyone tried this before? I get the feeling the overhead is not worth it when using such small devices, but it's nice they at least tried to include some useful code. Kind of pricey, but I do like the features of the board.

Top
Bronze MarkJohanEkdahl
JohanEkdahl's picture
Level: 10k+ Postman
Joined: Wed. Mar 27, 2002
Posts: 26945 View posts
Location: Lund, Sweden
Posted by JohanEkdahl: Sun. Apr 20, 2008 - 10:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Wonder what the far keyword does?

Almost certainly it controls how addressing is done. When something has the "far" keyword it can reside further from where it is referenced, and the compiler will use a longer address to reference it (eg. something "near" is addressed with a 8 bit address and can thus only be +-128 memory locations away, and something "far" is addressed with a 16 bit address and can thus be +-32K memory locations away). At least this is how it has been used in any compiler with those keywords that I have encountered.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here. 

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Top
th0th696
th0th696's picture
Level: Rookie
Joined: Sat. Mar 17, 2007
Posts: 25 View posts
Location: Austin, TX
Posted by th0th696: Mon. Apr 21, 2008 - 07:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Still not sure what to think about the library, it is a nice manual as to how to effectively use all of the features of the USBwiz. And you can disable features and reduce the size of the code, but I still get the feeling that it's unnecessary bloat on 16k of flash (I'm using an atmega168 btw). I'd still love to hear from anyone else using one of these boards. And thank you Johan for your clarification, you are a fountain of knowledge. I think I prefer the style of the register declarations in avr-libc, glad I'm not a PIC programmer!

Top
th0th696
th0th696's picture
Level: Rookie
Joined: Sat. Mar 17, 2007
Posts: 25 View posts
Location: Austin, TX
Posted by th0th696: Tue. Apr 22, 2008 - 10:04 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay I tried a little more tinkering and am running into a little trouble. You are supposed to edit a file called GHI_inter_user.c to fill some basic functions that everything else works on. Anyhow they implement the same set of functions in another file for the PIC (GHI_inter_PIC_I2C.c) It's GHI_PutC function looks like this:

void GHI_PutC(int8 ch)
{
	while(BUSY_PIN);
	if(DATARDY_PIN)// are we going to get somethign new?
	{
		StartI2C();
	    while ( SSPCON2bits.RSEN );
	    IdleI2C();//GHI_Sleep(1);
		WriteI2C(ADDRESS+1);
		IdleI2C();
		rx_fifo[rx_fifo_in++]=ReadI2C();
		//Delay1K(100);
		IdleI2C();
		StopI2C();
		IdleI2C();
			
	 	
	}
	
	// now send the data
	StartI2C();
	while ( SSPCON2bits.RSEN );
	IdleI2C();//GHI_Sleep(1);
	WriteI2C(ADDRESS);
	IdleI2C();
	//we should have an ACK now
	//RestartI2C();             // generate I2C bus restart condition
	//while ( SSPCON2bits.RSEN );// wait until re-start condition is over 
	//Delay1K(1);
	WriteI2C(ch);
	//Delay1K(1);
	IdleI2C();
	//we should get another ack
	StopI2C();
	IdleI2C();
}

I implemented the same with the code from the data sheet:

void GHI_PutC(u08 ch)
{
    uint8_t   twstatus;

        TWCR = (1<<TWINT) | (1<<TWSTA) | (1<<TWEN);
          while(!(TWCR & (1<<TWINT)));
          twstatus = TW_STATUS & 0xF8;
          if ( (twstatus != TW_START) && (twstatus != TW_REP_START)) continue;
          TWDR = 0xA4+1;
          TWCR = (1<<TWINT) | (1<<TWEN);
          while(!(TWCR & (1<<TWINT)));
          twstatus = TW_STATUS & 0xF8;
          if ( (twstatus == TW_MT_SLA_NACK )||(twstatus ==TW_MR_DATA_NACK) ) 
          {              
                TWCR = (1<<TWINT) | (1<<TWEN) | (1<<TWSTO);
                while(TWCR & (1<<TWSTO));
              continue;
          }

        TWDR = ch;
        TWCR = (1<<TWINT) | (1<<TWEN);

        while(!(TWCR & (1<<TWINT)));

        twstatus = TW_STATUS & 0xF8;
        if( twstatus != TW_MT_DATA_ACK) return 1;
        TWCR = (1<<TWINT) | (1<<TWEN) | (1<<TWSTO);
        while(TWCR & (1<<TWSTO));

}

However, things don't seem to be working. Does this look sane? I've also got a post on GHI's official forum here:

http://www.ghielectronics.com/gr...

I sure would like to hear from someone else who is using this chipset about how it's working out for them.

Top