From: Peter C. <pe...@pe...> - 2006-10-24 23:58:12
|
Using the following (on PIC14): var_u_char_8_b = (unsigned char) (var_int_16 / 8); where: var_u_char_8_b is unsigned char var_int_16 is int var_u_char_8_b always seems to be zero. If I get rid of the /8 bit var_u_char_8_b appears (I assume) to hold the least significant byte of var_int_16. Is there a problem here? Am I missing something? The work round is obvious, right shift by 4 bits, but that is less useful if I want to divide by say 3 or 7. Any thoughts? Pete |
From: Peter C. <pe...@pe...> - 2006-10-25 18:02:51
|
On Wednesday 25 October 2006 00:58, Peter Chant wrote: Hmm, found a funny with __data __at working with unsigned char but not with int when looking at the following: > Using the following (on PIC14): > > var_u_char_8_b = (unsigned char) (var_int_16 / 8); > > where: > var_u_char_8_b is unsigned char > var_int_16 is int > > var_u_char_8_b always seems to be zero. I was using the following so I could nail down where the offending variables were in gpsim, I declaired the varibles as shown here: __data __at (0x60) unsigned int var_u_int_16; __data __at (0x62) unsigned char var_u_char_8; __data __at (0x030) unsigned char var_u_char_8_b; var_u_char_8 and var_u_char_8_b seem to end up where told but var_u_int_16 seems to end up at 0x63 & 0x64! Not stopping me from doing anything but I could not see anything on this in the manual. Pete |
From: Raphael N. <rn...@we...> - 2006-10-28 16:09:14
|
Hi Peter, > > Using the following (on PIC14): > > > > var_u_char_8_b = (unsigned char) (var_int_16 / 8); > > > > where: > > var_u_char_8_b is unsigned char > > var_int_16 is int > > > > var_u_char_8_b always seems to be zero. I cannot reproduce this behaviour (unless I fail to initialize var_int_16 to something != 0 that is...). I get beautiful results, gpsim loops happily in my catch-all loop in <code filename="bDIV.c"> typedef unsigned char uchar; typedef unsigned int uint; typedef unsigned long ulong; __data __at (0x60) unsigned int var_u_int_16; __data __at (0x62) unsigned char var_u_char_8; __data __at (0x30) unsigned char var_u_char_8_b; uchar div1(int b) { var_u_int_16 = b; var_u_char_8_b = (unsigned char) (var_u_int_16 / 7); return var_u_char_8_b; } void main(void) { uchar res; res = div1(44); while (res != 6); res = div1(50); while (res != 7); res = div1(0); while (res != 0); while (1); /* gpsim reaches here */ } </code> sdcc -mpic14 -p16f877 bDIV.c Could you post a more complete example showing your error? > I was using the following so I could nail down where the offending > variables were in gpsim, I declaired the varibles as shown here: > > __data __at (0x60) unsigned int var_u_int_16; > __data __at (0x62) unsigned char var_u_char_8; > __data __at (0x030) unsigned char var_u_char_8_b; > > var_u_char_8 and var_u_char_8_b seem to end up where told but var_u_int_16 > seems to end up at 0x63 & 0x64! This was a bug, which is now (r4440) fixed: SDCC/pic14 emitted _var_u_int_16 twice, once in its pinned location and again in udata. You did get a warning from gplink about this though... (value of symbol _var_u_int_16 changed in second pass). -- Regards, Raphael Neider |
From: Peter C. <pe...@pe...> - 2006-10-29 21:20:13
|
On Saturday 28 October 2006 17:02, Raphael Neider wrote: > sdcc -mpic14 -p16f877 bDIV.c Weird, it gets stuck in gpsim about [****] here: BCF STATUS,5 BCF STATUS,6 **** MOVWF _var_u_char_8_b =09 ; .line 14; "bDIV.c" =A0 =A0 return var_u_char_8_b; MOVF _var_u_char_8_b,W RETURN=09 ; exit point of _div1 The offending routine is at the bottom of the post, I've added *******=20 to the offending bit. I think I will upgrade my installation (Slackware)=20 to see if latest gpsim and sdcc on a fresh installation makes a=20 difference, not that it should. Just in case there is something odd this=20 will not destroy the old installation as it will be on a different disk=20 partition. The idea of the function below is that it outputs a pulse 1msec wide for=20 position =3D -1000 and 2msec wide for position =3D 1000. void Single_Servo_Int(int position) { //Take -1000 as full one way, +1000 as the other //0 =3D middle. //Note, needs to provide a pulse from 1-2msec width //at a 20msec interval - check in detail. //Base on 20MHz cpu. unsigned char i; =09 //Put out a logic high PORTD =3D PORTD | 0x80; //PORTB =3D 0xff; //PORTD =3D 0x80;; =09 =09 //Limit if (position > 1000) { position =3D 1000; } =09 if (position < -1000) { position =3D -1000; }=20 //i =3D 255; /* lloop =3D 600000; while(lloop > 0) { lloop--;}*/ //First pause, 1msec - 5 000 cycles =09 for ( i =3D 0 ; i < 250 ; i++ ) { _asm nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop _endasm; } //Calc the variable delay ****** for ( i =3D 0 ; i < (unsigned char) ( (position + 1000)/ 8 ) ; i++ )= { _asm nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop _endasm; } =09 PORTD =3D PORTD & (0xFF - 0x80); //PORTB =3D 0; //PORTD =3D 0x00; } |
From: Raphael N. <rn...@we...> - 2006-10-29 23:55:18
|
Hi Peter, > Weird, it gets stuck in gpsim about [****] here: > > BCF STATUS,5 > BCF STATUS,6 > **** MOVWF _var_u_char_8_b > ; .line 14; "bDIV.c" return var_u_char_8_b; > MOVF _var_u_char_8_b,W > RETURN > ; exit point of _div1 Any message from gpsim? > The offending routine is at the bottom of the post, I've added ******* > to the offending bit. I think I will upgrade my installation (Slackware) > to see if latest gpsim and sdcc on a fresh installation makes a > difference, not that it should. Just in case there is something odd this > will not destroy the old installation as it will be on a different disk > partition. Did you recompile the pic14 library after upgrading? I use gpsim r1748 (roughly 0.21.12-pre) and SDCC r4440, when last I looked gpsim releases were rather outdated, maybe you should use the svn version as well? > The idea of the function below is that it outputs a pulse 1msec wide for > position = -1000 and 2msec wide for position = 1000. Checked your code with a main() that calls the given function with arguments of -1000, -500, 0, 500, and 1000, and set a breakpoint once the result of __divsint has been stored into the registers (address taken from .lst file). I then used 'trace 20' to obtain the past assignments of both result bytes and found they were totally reasonable 0x0000, 0x003e, 0x007d, 0x00bb, and 0x00fa respectively. Target PIC was a 16f877 (which one do you use?). ((Two side notes: If you put position + 1000 in an unsigned variable, SDCC should optimize the division to right shifts---and possibly hide your problem... Using 8u instead of 8 might also be required...)) You may want to inspect your .map files to see if you are out of memory; or if gputils have allocated some variables where they should not have been, possibly instructed by SDCC; or ... -- Regards, Raphael Neider |
From: Peter C. <pe...@pe...> - 2006-10-30 21:45:11
|
On Sunday 29 October 2006 23:54, Raphael Neider wrote: > > Weird, it gets stuck in gpsim about [****] here: > > > > BCF STATUS,5 > > BCF STATUS,6 > > **** MOVWF _var_u_char_8_b > > ; .line 14; "bDIV.c" return var_u_char_8_b; > > MOVF _var_u_char_8_b,W > > RETURN > > ; exit point of _div1 > > Any message from gpsim? Not that I recall, and I do remember looking. > Did you recompile the pic14 library after upgrading? > I use gpsim r1748 (roughly 0.21.12-pre) and SDCC r4440, when last I > looked gpsim releases were rather outdated, maybe you should use the svn > version as well? > I think I did, I believed I had deleted them to be sure. I've just downloaded the latest version of gputils via cvs and am installing them now on a fresh Slackware 11.0 installation (wanted to upgrade slack at some point anyhow, might as well do it now and see if my pic problems go away). > Checked your code with a main() that calls the given function with > arguments of -1000, -500, 0, 500, and 1000, and set a breakpoint once > the result of __divsint has been stored into the registers (address > taken from .lst file). I then used 'trace 20' to obtain the past > assignments of both result bytes and found they were totally reasonable > 0x0000, 0x003e, 0x007d, 0x00bb, and 0x00fa respectively. Target PIC was > a 16f877 (which one do you use?). > Good to see my routine was working somewhere as intended! PIC16F877-20I/P - that is on my development board. Once something works I may well change to another PIC, but it is rather handy to develop the software on the board I have here. > ((Two side notes: If you put position + 1000 in an unsigned variable, SDCC > should optimize the division to right shifts---and possibly hide your > problem... Using 8u instead of 8 might also be required...)) Usefull to know. > > You may want to inspect your .map files to see if you are out of memory; > or if gputils have allocated some variables where they should not have > been, possibly instructed by SDCC; or ... I don't think I've been out of memory, but a bit or practice with the map files would not go amiss. I will report back shortly on how I get on with the new installation. Of course slightly disturbed that reinstallation is usually the cop out when you don't know how to fix the problem... Pete |
From: Peter C. <pe...@pe...> - 2006-10-31 00:54:54
|
On Monday 30 October 2006 21:45, Peter Chant wrote: > I will report back shortly on how I get on with the new installation. > Of course slightly disturbed that reinstallation is usually the cop out > when you don't know how to fix the problem... OK, some success, some failure. Downloaded from todays svn/cvs and found some problem with sdcc (failed to build and reported errors in itself). I deleted this and installed the current stable version (2.6.0). It seems to work. I suspect sdcc is probably ok. gpsim is not a runner, both todays cvs (or svn I can't remeber which) and the current stable, (0.21.11) have problems and chuck out the following *** glibc detected *** double free or corruption (out): 0x081dd968 *** I've noticed another problem with free. I'll do a bit of a search to see if this is covered anywhere. If not I suspect I'm best going to the gpsim mailing list with it. A bit of an uphill struggle here but I am grateful and impressed by the help I'm being given. Pete |
From: Scott D. <sc...@da...> - 2006-10-31 06:23:26
|
> On Monday 30 October 2006 21:45, Peter Chant wrote: > gpsim is not a runner, both todays cvs (or svn I can't remeber which) and > the > current stable, (0.21.11) have problems and chuck out the following SVN. 0.21.11 is old, but I'm working on a 0.22.0 release as we speak. > *** glibc detected *** double free or corruption (out): 0x081dd968 *** I saw this error for the first time yesterday in my development code. I fixed the offending code, but may have inadvertently missed something... If you'll send me the C source and the command you used to compile it then I'll try it out on gpsim. If gpsim is the problem I'll let you know (and then I'll go fix it!). Scott |
From: Peter C. <pe...@pe...> - 2006-10-31 23:56:26
|
On Tuesday 31 October 2006 22:10, Scott Dattalo wrote: > So you mean that gpsim runs fine without the gui? If so I wonder if your > gpsim problem is really a gtkextra problem: > Appears to, though to my shame I'm not really good at using it without the gui. The breadboard view is the killer app, that and looking at what the ram is ding. > http://sourceforge.net/tracker/index.php?func=detail&aid=1504169&group_id=1 >1638&atid=111638 > That is almost it, I apply the fix given in the link: The fix to this bug is to change line 4152 in gtkextra/gtksheet.c from g_free(sheet->pixmap); to g_object_unref(sheet->pixmap); gpsim is now stable, however the source viewer is now a mess. I'll email you a screen capture off list. Note that that is a very large improvement from where I sit. I wonder if a downgrade of gtkextra is in order? > > Cunning plan, I have a spare hard drive and external caddy. What linux > > distro are you using? I can install that on the spare drive and see if > > gpsim works then. > > I'm currently using both FC4 and an ancient RH9 that has been patched > more than your great grandmother's quilt. Not so cunning at the moment. The Mandriva installer cannot see the usb caddy but is rather keen to hose my XP installation. Old faithful slackware behaves itself but I get disk errors, it looks like leaving a perfectly good disk unused for 2 years kills it! Doing a slow format with bad block checking as we speak. Not my week by the look of things! Pete |
From: Scott D. <sc...@da...> - 2006-11-01 00:08:15
|
Peter Chant wrote: > That is almost it, I apply the fix given in the link: > > The fix to this bug is to change line 4152 in > gtkextra/gtksheet.c from > g_free(sheet->pixmap); > to > g_object_unref(sheet->pixmap); > > gpsim is now stable, however the source viewer is now a mess. I'll email you > a screen capture off list. Note that that is a very large improvement from > where I sit. This has been fixed in more recent versions of gpsim. You said at one point you had a recent SVN version of gpsim. I'd suggest using that instead of the old 0.21.11. > I wonder if a downgrade of gtkextra is in order? I don't know what to say other than that gtkextra should be re-released. > Not my week by the look of things! :) Happy Halloween! Scott |
From: Peter C. <pe...@pe...> - 2006-11-01 00:14:00
|
On Saturday 28 October 2006 17:02, Raphael Neider wrote: > I cannot reproduce this behaviour (unless I fail to initialize > var_int_16 to something != 0 that is...). I get beautiful results, gpsim > loops happily in my catch-all loop in As of tonight the code you posted fails (gpsim stops) on the first call to the function div1!??! ! |
From: Peter C. <pe...@pe...> - 2006-11-01 00:46:23
|
On Wednesday 01 November 2006 00:08, Scott Dattalo wrote: > This has been fixed in more recent versions of gpsim. You said at one > point you had a recent SVN version of gpsim. I'd suggest using that > instead of the old 0.21.11. Looks a lot better, but is this message important: (gpsim:12227): Gtk-CRITICAL **: gtk_text_buffer_emit_insert: assertion `g_utf8_validate (text, len, NULL)' failed ? Just for info. |
From: Scott D. <sc...@da...> - 2006-11-01 03:31:48
|
> On Wednesday 01 November 2006 00:08, Scott Dattalo wrote: > >> This has been fixed in more recent versions of gpsim. You said at one >> point you had a recent SVN version of gpsim. I'd suggest using that >> instead of the old 0.21.11. > > Looks a lot better, but is this message important: > > > (gpsim:12227): Gtk-CRITICAL **: gtk_text_buffer_emit_insert: assertion > `g_utf8_validate (text, len, NULL)' failed This is from the program memory window. I plan on removing this window and just making it a tab in the source browser. For now, just ignore the error, it causes no known side effects (other than that annoying message). Scott |
From: Peter C. <pe...@pe...> - 2006-11-01 18:24:28
|
On Wednesday 01 November 2006 01:35, Scott Dattalo wrote: > > This is from the program memory window. I plan on removing this window and > just making it a tab in the source browser. For now, just ignore the > error, it causes no known side effects (other than that annoying message). I already was :-), I just wondered whether it was pertinent to the discussion! |
From: Raphael N. <rn...@we...> - 2006-11-01 17:56:08
|
> > I cannot reproduce this behaviour (unless I fail to initialize > > var_int_16 to something != 0 that is...). I get beautiful results, gpsim > > loops happily in my catch-all loop in > > As of tonight the code you posted fails (gpsim stops) on the first call to the > function div1!??! I updated to gpsim r1788 and built it with --disable-gui (which fails due to a bug in modules/gpsim_modules: a reference to PushButton must be moved into the preceeding #ifdef HAVE_GUI block) and simulated the same .cod file as used before---still executes happily till the end. You use the GUI version of gpsim; however, you might try to build gpsim again with --disable-gui, install it or make sure you execute the correct binary, and use gpsim -s bDIV.cod run [Crtl]+[c] // after some time quit Remember at which address _should be a GOTO to itself) loop gpsim was interrupted and look it up in the bDIV.lst file. If it is 0x0061, just before the RETURN from main, your SDCC and gpsim are fine, but the GUI interferes somehow. I would build gpsim with GUI myself, but cannot get my system to find the gtkextra package... Still trying, though. -- Regards, Raphael Neider |
From: Peter C. <pe...@pe...> - 2006-11-01 19:03:36
|
> You use the GUI version of gpsim; however, you might try to build gpsim > again with --disable-gui, install it or make sure you execute the > correct binary, and use > gpsim -s bDIV.cod > run > [Crtl]+[c] // after some time > quit > Just by running it with the -i option I can see it gets to 0x0034 which=20 looking at the list file is correct ("gpsim reaches here"). Note I added=20 some config bits to my bDIV.cod file as gpsim complained about a watchdog=20 timer timeout. I'm learning a bit about the cli side of it as I've been=20 solely sticking with the gui up to now. 0x00000000003567E5 16f877 0x0034 0x2834 goto 0x0034 =46rom the cli it seems to get here irrespective of whether I have the gui = up or=20 not. However, the source browser appears not to be keeping up with the cli, even if I sin= gle=20 step. > Remember at which address _should be a GOTO to itself) loop gpsim was > interrupted and look it up in the bDIV.lst file. If it is 0x0061, just > before the RETURN from main, your SDCC and gpsim are fine, but the GUI > interferes somehow. > I had 0x0034 from my latest build! OK, stripped out the config bits and got the same! > I would build gpsim with GUI myself, but cannot get my system to find > the gtkextra package... Still trying, though. Hmm, I cheated a bit and downloaded the windows snap shot to check that gps= im=20 behaved the same on different systems, it does. Pete |