Jump to content



Photo

GPUtils PIC bug?

gputils pagesel bug

  • Please log in to reply
33 replies to this topic

#16 OP n_K

n_K

    Neowinian Senior

  • Tech Issues Solved: 3
  • Joined: 19-March 06
  • Location: here.
  • OS: FreeDOS
  • Phone: Nokia 3315

Posted 06 February 2013 - 23:10

Humm, bit of a problem;

/usr//bin/sdcc -mpic16 -V -p18f4520 -DDEBUG --denable-peeps --opt-code-size --optimize-cmp --optimize-df -I. -c i2c_master.c
+ /usr//bin/sdcpp -nostdinc -Wall -DDEBUG -I. -Dpic18f4520 -D__18f4520 -D__SDCC_PIC18F4520 -DSTACK_MODEL_SMALL -D__STACK_MODEL_SMALL -obj-ext=.o -D__SDCC=3_2_1 -DSDCC=321 -D__SDCC_REVISION=8413 -DSDCC_REVISION=8413 -D__SDCC_pic16 -DSDCC_pic16 -D__pic16 -D__STDC_NO_COMPLEX__ -D__STDC_NO_THREADS__ -D__STDC_NO_ATOMICS__ -D__STDC_NO_VLA__ -isystem /usr//bin/../share/sdcc/include/pic16 -isystem /usr/share/sdcc/include/pic16 -isystem /usr//bin/../share/sdcc/include -isystem /usr/share/sdcc/include i2c_master.c
In file included from i2c_master.h:4,
from i2c_master.c:1:
/usr//bin/../share/sdcc/include/pic16/pic18fregs.h:580:26: error: pic18f4520.h: No such file or directory

And the files in that directory;
adc.h delay.h float.h i2c.h malloc.h p18fxxx.inc pic18fregs.h signal.h stddef.h stdio.h string.h
ctype.h errno.h gstack.h limits.h math.h pic16devices.txt sdcc-lib.h stdarg.h stdint.h stdlib.h usart.h

I edited the PKGBUILD and compiled my own SVN version of sdcc but I'm not sure what I'm doing wrong that the files aren't there!

EDIT: Scratch that, downloaded the file off the net and it works, not sure why it isn't included by default though.
New problem! config.h:9: syntax error: token -> 'char' ; column 9
make: *** [main.o] Error 1

#define VERSION 0.1

// Set the __CONFIG words:
code char at __CONFIG1H _conf1 = _OSC_INTIO67_1H
code char at __CONFIG2L _conf2 = _VREGEN_ON_2L & _PUT_ON_2L & _BODEN_OFF_2L;


^ It doesn't seem to like that... And I haven't got a clue what it SHOULD look like :p

Edited by n_K, 06 February 2013 - 23:17.



#17 +Karl L.

Karl L.

    xorangekiller

  • Tech Issues Solved: 15
  • Joined: 24-January 09
  • Location: Virginia, USA
  • OS: Debian Testing

Posted 07 February 2013 - 00:26

You should set the device configuration using the pragmas documented in the XC16 C compiler manual.

2.5.14 Specifying Configuration Bits

The #pragma config directive may be used to program the configuration bits for a device. The pragma has the form:

#pragma config setting = state|value
#pragma config register = value


where setting is a configuration setting descriptor (e.g., WDT), state is a descriptive value (e.g., ON) and value is a numerical value. The register token may represent a whole configuration word register, e.g., CONFIG1L. Use the native keywords discussed in the Differences section to look up information on the semantics of this directive.

2.5.14.1 EXAMPLE

The following shows configuration bits being specified using this pragma.

#pragma config WDT=ON, WDTPS = 0x1A


If you need to use special function registers - which I'm guessing your probably do - read chapter 4 of the manual. In particular, the following is an excerpt from section 4.6 "using SFRs":

The convention in the processor header files is that each SFR is named, using the same name that appears in the data sheet for the part – for example, CORCON for the Core Control register. If the register has individual bits that might be of interest, then there will also be a structure defined for that SFR, and the name of the structure will be the same as the SFR name, with “bits” appended. For example, CORCONbits for the Core Control register. The individual bits (or bit fields) are named in the structure using the names in the data sheet – for example PSV for the PSV bit of the CORCON register.


I recommend that you have both the datasheet and compiler manual handy until you know your microcontroller and compiler's special features fairly well. My approach is usually to read the datasheet first to learn the neat features specific to my microcontroller, then read the compiler manual so I understand the caveats and best practices recommended by its authors (who presumably know more about the architecture than me). However, if you have to pick just one section of the datasheet or compiler manual to read, "Chapter 2. Common C Interface" should absolutely be it. That chapter will explain enough to get you started, at least.

#18 OP n_K

n_K

    Neowinian Senior

  • Tech Issues Solved: 3
  • Joined: 19-March 06
  • Location: here.
  • OS: FreeDOS
  • Phone: Nokia 3315

Posted 07 February 2013 - 00:43

This is sdcc not the official MC compiler.
I can't understand why it won't work, this is using an example from the sdcc forums that another user said works fine on the PIC I'm trying to compile for.
main.c:11: warning 115: unknown or unsupported #pragma directive '__CONFIG1H = _OSC_HS_PLL_1H & _OSCS_ON_1H;' (when it was #pragma __CONFIG1H = _OSC_HS_PLL_1H & _OSCS_ON_1H;)
main.c:11: warning 191: #pragma config: bad argument(s); pragma ignored (when it was #pragma config __CONFIG1H = _OSC_HS_PLL_1H & _OSCS_ON_1H;)
I got the config line I changed to #pragma from another post on their forums :s

#19 +Karl L.

Karl L.

    xorangekiller

  • Tech Issues Solved: 15
  • Joined: 24-January 09
  • Location: Virginia, USA
  • OS: Debian Testing

Posted 07 February 2013 - 01:10

Does SDCC support the dsPIC? I though it only supported the PIC18.

I have only used the XC16 C compiler with my PIC24, but I have used both the HI-TECH C compiler and SDCC with my PIC18. I can try to find my makefile and some basic source code if you are interested. All I could find off-hand, though, is the configuration I have often used for the PIC18 with HI-TECH C.

#ifndef CONFIG_H
#define CONFIG_H

#include <htc.h>

/* PIC18F242 configuration details */
#pragma config OSC=HSPLL
#pragma config BOR=OFF
#pragma config PWRT=OFF
#pragma config WDT=OFF
#pragma config DEBUG=OFF
#pragma config LVP=OFF

/* Bit manipulation macros suggested by the HI-TECH C manual */
#define bitset(var,bitno) ((var) |= (1 << (bitno)))
#define bitclr(var,bitno) ((var) &= ~(1 << (bitno)))
#define bittst(var,bitno) (var & (1 << (bitno)))

#endif // CONFIG_H

Edit: OK. I found it. I can't vouch for the completeness of this code and I make no claims that it represents good style or practice, but it does compile on SDCC 3.2 and run on the PIC18F242. The zip archive with the code is attached to this post.

Attached Files



#20 OP n_K

n_K

    Neowinian Senior

  • Tech Issues Solved: 3
  • Joined: 19-March 06
  • Location: here.
  • OS: FreeDOS
  • Phone: Nokia 3315

Posted 08 February 2013 - 09:07

I was compiling and testing for the 18F4520 :p Also got an 18F4550 too now.
I'd like to try out the dspic but unfortunately either the hardware and/or the software fails half way through reading/programming them so I'm actually unable to do anything with them.

#21 OP n_K

n_K

    Neowinian Senior

  • Tech Issues Solved: 3
  • Joined: 19-March 06
  • Location: here.
  • OS: FreeDOS
  • Phone: Nokia 3315

Posted 06 March 2013 - 16:01

Right I've got the XC8 free edition and MPLABX installed on this PC, tried compiling the 18F4520 example for an LCD I got and it does compile... Only problem is that it's not starting instructions at 0x0000 and is instead starting at 0x1067... I can't really understand why?
http://www.wvshare.c...-Touch-LCD-A.7z is the code and I converted it from an MPLAB 8.x project, any ideas?

"invalid address 0xf0010f, possibly not hex file for correct pic type?"

"picprog --device=pic18f4520 --erase --burn -i "/tmp/TOUCH.X.production.hex" --jdm --pic /dev/ttyS0
Picprog version 1.9.1, Copyright © 2010 Jaakko Hyvätti <Jaakko.Hyvatti@iki.fi>
Picprog comes with ABSOLUTELY NO WARRANTY; for details
type `picprog --warranty'. This is free software,
and you are welcome to redistribute it under certain conditions;
type `picprog --copying' for details.

Trying realtime priority 1
Bound to CPU 0
Bound to CPU 1
Bound to CPU 2
Using >1 µs delays. --rdtsc may work for faster timings.
/tmp/TOUCH.X.production.hex:397:invalid input line."

Line 397 is in bold (lines 395-end):
":107FE80000000000000000000000000057617665F6
:087FF80053686172650000008E
:020000040020DA
:08000000FFFFFFFFFFFFFFFF00
:020000040030CA
:0E000000FF071F1FFF8385FF0FC00FE00F409B
:00000001FF"

Edited by n_K, 06 March 2013 - 16:09.


#22 +Karl L.

Karl L.

    xorangekiller

  • Tech Issues Solved: 15
  • Joined: 24-January 09
  • Location: Virginia, USA
  • OS: Debian Testing

Posted 06 March 2013 - 19:44

Microcontroller code compiled with an ANSI C compiler never starts at address 0. It uses the reserved space before main() for global and static variables.

Unfortunately I can't look at your code because it doesn't extract properly for me. However, this adafruit LCD tutorial is a good place to start. I also attached my code for a basic calculator using a 4 line 20 character LCD and 4x4 keypad. It compiles using the HI-TECH C compiler (and most likely the XC8 compiler as well, although I haven't tested that). I uploaded it to my PIC18F242 from MPLABX using the PICkit 2.

Attached Files



#23 OP n_K

n_K

    Neowinian Senior

  • Tech Issues Solved: 3
  • Joined: 19-March 06
  • Location: here.
  • OS: FreeDOS
  • Phone: Nokia 3315

Posted 06 March 2013 - 20:24

Right I've found the problem, apparently it's because MPLAB is (crap) writing 'odd byte counts' to save space or something, and someone wrote a program (fixhex3) to fix the problems but appears it's a private release or something.
So I have absolutley no idea how to make MPLABX create proper files or how to change invalid files into proper ones either :s

#24 OP n_K

n_K

    Neowinian Senior

  • Tech Issues Solved: 3
  • Joined: 19-March 06
  • Location: here.
  • OS: FreeDOS
  • Phone: Nokia 3315

Posted 06 March 2013 - 21:50

Right I got it programmed, having to use picpgm as picprog doesn't support the 'odd byte count' programming type by picpgm does, the downside to using picpgm is that it takes absolutely ages to write, and verifying... WOW... I've got it not verifying as it took over 30 second to verify :(.

But I've got an incredibly strange action from this code, I've tried a 3.4Mhz oscillator, 8Mhz oscillator and 20Mhz oscillator - they all seem to run the code at the same speed, even tried reducing the values in the loop functions - and the program doesn't speed up AT ALL, it is absolutely crazy :s.

#25 OP n_K

n_K

    Neowinian Senior

  • Tech Issues Solved: 3
  • Joined: 19-March 06
  • Location: here.
  • OS: FreeDOS
  • Phone: Nokia 3315

Posted 07 March 2013 - 01:26

Wow, I can't actually believe it :o.
Got an 18LF4520 reading data from an RTC using C, and, it works!
Unbelievable! (Well, I've got it setting LEDs depending on what the seconds are) but heck it's astonishing to be able to write that in 20 lines of code instead of 300 or so, though it does seem to be compiling it to inefficient code;
Program space used 348h ( 840) of 8000h bytes ( 2.6%)
Data space used 15h ( 21) of 600h bytes ( 1.4%)

Ah well, that's nifty!

#26 OP n_K

n_K

    Neowinian Senior

  • Tech Issues Solved: 3
  • Joined: 19-March 06
  • Location: here.
  • OS: FreeDOS
  • Phone: Nokia 3315

Posted 07 March 2013 - 19:40

Right actually it's not working... And I've no idea why! It's getting back straight 1s.
Here's the code I kinda 'converted' it from;
  RTC_t rtc;
  I2C_start();    // START
  I2C_out_byte(0xD0);   // DS1307 hardware address + write command
  I2C_sack();	 // slave ACK
  I2C_out_byte(0x00);   // we will read from this address
  I2C_sack();	 // slave ACK
  I2C_start();	 // repeated START
  I2C_out_byte(0xD1);   // DS1307 hardware address + read command
  I2C_sack();	 // slave ACK
  rtc.sec = I2C_in_byte();   // read sec
  I2C_ack();	 // master ACK
  rtc.min = I2C_in_byte();   // read min
  I2C_ack();	 // master ACK
  rtc.hour = I2C_in_byte();  // read hour
  I2C_ack();	 // master ACK
  rtc.dweek = I2C_in_byte();  // read dweek
  I2C_ack();	 // master ACK
  rtc.day = I2C_in_byte();  // read day
  I2C_ack();	 // master ACK
  rtc.month = I2C_in_byte();  // read month
  I2C_ack();	 // master ACK
  rtc.year = I2C_in_byte();  // read year
  I2C_nack();	 // master NACK
And here's my code;
#define I2C_V2 true
#include <plib/i2c.h>
    int Data[6];
    OSCCON = 0b10100011;
    TRISC = 0x00; // turn on tri-state register and
				 // make all output pins
    PORTC = 0x00; // make all output pins LOW
    TRISA = 0x00;
    PORTA = 0xFF;
    OpenI2C( MASTER, SLEW_OFF);
    __delay_ms(90);
    __delay_ms(90);
    __delay_ms(90);
    PORTA = 0x00;
    SSPADD = 0x3F;
    StartI2C();
    IdleI2C();
    WriteI2C( 0xD0 );  // sends address to the
    IdleI2C();
    WriteI2C( 0x00 );
    IdleI2C();
    StopI2C();

    StartI2C();
    IdleI2C();
    WriteI2C( 0xD1 );  // sends address to the
    IdleI2C();
    WriteI2C( 0x00 );  // sends address to the
    IdleI2C();
//    RestartI2C();
    Data[0] = ReadI2C();
    IdleI2C();
    AckI2C();
    IdleI2C();
    Data[1] = ReadI2C();
    IdleI2C();
    AckI2C();
    IdleI2C();
    Data[2] = ReadI2C();
    IdleI2C();
    AckI2C();
    IdleI2C();
    Data[3] = ReadI2C();
    IdleI2C();
    AckI2C();
    IdleI2C();
    Data[4] = ReadI2C();
    IdleI2C();
    AckI2C();
    IdleI2C();
    Data[5] = ReadI2C();
    IdleI2C();
    AckI2C();
    IdleI2C();
    Data[6] = ReadI2C();
    IdleI2C();
    NotAckI2C();
    IdleI2C();
    StopI2C();
    PORTA = Data[0];
    __delay_ms(90);
    __delay_ms(90);
    __delay_ms(90);
    __delay_ms(90);
    PORTA = 0;
    __delay_ms(90);
    __delay_ms(90);
    __delay_ms(90);
    __delay_ms(90);
    PORTA = Data[1];
    Sleep();
Any ideas?

#27 OP n_K

n_K

    Neowinian Senior

  • Tech Issues Solved: 3
  • Joined: 19-March 06
  • Location: here.
  • OS: FreeDOS
  • Phone: Nokia 3315

Posted 07 March 2013 - 21:24

Oh I don't believe it! I'm sure I read this RTC was 3.3v only so was using a 3.3v regulator and my 18LF4520... Now I read it needs 4.5-5.5v to function!
DAMNIT!
I'll program the normal 18f4520 sometime and try it.

EDIT: It's getting results now, not sure if they're correct but the seconds are changing... Feel like a right bloody tool for not working this out earlier :|

Edited by n_K, 07 March 2013 - 21:50.


#28 OP n_K

n_K

    Neowinian Senior

  • Tech Issues Solved: 3
  • Joined: 19-March 06
  • Location: here.
  • OS: FreeDOS
  • Phone: Nokia 3315

Posted 15 July 2013 - 19:27

Right, I'm reusing this thread! Got a pretty strange problem with the same microchip (18f4520) that I really can't quite get my head around...

Switched to using xc8 (free) and mplabx, and was experimenting with RS232 communication on the PIC, now for some reason for the example BAUDCON values provided in the datasheet, I've always had to use 1 less than the given value, so 11 instead of 12 for 19.2Kbps as if I use 12 it doesn't work, and this is connected up to a modified PC PSU with an LM7805 regulator on the 12V rail...

Now this has been working kinda well until I decided to switch over to the 5V rail as the regulator hasn't got a heatsink and I want to do some longer testing, switched it over and guess what? RS232 communication now fails, I get really weird values on the PC... So I recompiled my source but this time using the PROPER BAUDCON value specified in the datasheet, 12... Now RS232 communication works fine once again, but if I switch back to using the LM7805 it fails unless I switch BAUDCON BACK to 11.

I'm pretty perplexed by why the hell this is just playing up and being a nuisance, nothing is listed in the erratas about it. Measured the output voltage from the LM7805 and it's 4.99V, output from the 5V rail is 5.10V, and the PIC is using the internal oscillator set to run at 4MHz... So I can't really see or understand why a 0.11V difference means I need to use a different BAUDCON.

Has anyone got the foggiest idea why this is? What I do to fix this?



#29 +Karl L.

Karl L.

    xorangekiller

  • Tech Issues Solved: 15
  • Joined: 24-January 09
  • Location: Virginia, USA
  • OS: Debian Testing

Posted 15 July 2013 - 19:48

You should always consider the value from the datasheet canonical. It is very rare that the manufacturer got the value wrong, especially for a large company like Microchip that tends to produce high quality documentation. I would suspect Microchip's compiler before the documentation, although the XC8 is GCC-based and immensely better than the previous two PIC16/PIC18 compilers they produced. The second setup with the 5V power supply sounds correct, and indeed appears to be based on your results. The first setup is suspect.

 

Assuming everything else stayed the same, it sounds like it might have something to do with your voltage regulator. According to their respective datasheets your regulator can produce up to 1.5A and your microcontroller can consume up to 300mA, so that shouldn't be a problem. What other devices do you have connected to your power rail? Are you trying to draw more than current than you regulator can provide?



#30 OP n_K

n_K

    Neowinian Senior

  • Tech Issues Solved: 3
  • Joined: 19-March 06
  • Location: here.
  • OS: FreeDOS
  • Phone: Nokia 3315

Posted 15 July 2013 - 20:35

All that's connected up is the PIC, an elechouse RFID reader/writer (pulls up to 50mA) and a generic 16x2 LCD with backlight. When connected directly to the 5V rail it's pulling ~83mA in total which is more than enough for the setup. The 5V regulator is pulling 78mA from the 12V rail.

I'm using the standard reference implementation with the regulator with a 47uF 16V capacitor on the output of the regulator so to stabilise it. Still can't think why it'd be messed up.





Click here to login or here to register to remove this ad, it's free!