C4SX: Release of C4SX Version 0.2

RW Senser

Hello all-

This posting announces an enhanced C4SX: C4SX Version 0.2.

This is an environment (editor, compiler, and loader for the SK-KEY) that makes it
possible to compile C programs under Windows and then run these C programs on the SX.·
This NO-COST environment has been used to produce several large, production-quality C
programs and includes serial I/O support.

There have been several improvements in the C4SX utility programs, more documentation
added, C libraries/includes added and more sample programs are provided. The sample
programs have been tested on the SX28 and the SX48.

The sxio.h C header file ("library") makes it possible to use C getchar(), putchar()
and puts() functions with the SX (assuming you have a USB2SER or other serial
capability connected to you SX). Also present are some experimental ctype.h,
string.h and stdlib.h include files.· A more advanced set of includes is also provided,
thanks to Parallax SX Forum contributions.····

You can view documentation, including a "Quick Start", at:
http://www.rwsenser.com/c4sx/C4SX_Environment.htm
You can download the full C4SX Zip file from http://www.rwsenser.com by following
the "Click here to download the beta 2 C4SX Zip File".· Note that you will also need to
download some other components from the web (Parallax SK-KEY, CC1B compiler and
possibly an editor).· Clear instructions for what to download are given in the
C4SX documentation.

If you are interested in C for the SX, please give this new C4SX a try.

Feedback, comments and/or questions about C4SX are always welcome, please post them to
this forum.· Or, you can also email them to c4sx@rwsenser.com

If there is continued interest from the SX Community, C4SX with be expanded and
further refined.

printf("Thanks,\nRW Senser\n");

Peter Verkaik

Downloaded and installed. No problems.

I added -V to the cc1b commands section·in C4SX.BAT file

rem call CC1B compiler
if %MODE% == 1 call "%CC1B_PATH%\CC1B" -I"%CC1B_PATH%" -I"%C4SX_PATH%" -V -atmp· %1.c
if %MODE% == 2 call "%CC1B_PATH%\CC1B" -I"%CC1B_PATH%" -I"%C4SX_PATH%" -V -atmp· %2.c

This makes cc1b generate a .var file which contains a detailed variable listing.
It can be opened with any text editor, including notepad++

regards peter

RW Senser

Hi Peter-

Many thanks for doing the download and install.

I'll add the -V to the C4SX.BAT script for the next release.

Thx,
RW Senser

Peter Verkaik

RW Senser,
When I use RTCC or STATUS·in a C source, cc1b outputs RTCC EQU $01· or STATUS EQU $03
to its assmebler file. Your conversion program already comments out INDF, FSR, RA, RB, RC, RD, RE
but it does not comment out RTCC and STATUS so sasm throws an error that RTCC and STATUS
are·reserved words.

regards peter

RW Senser

Hi Peter,

Thanks for the information. I'll check into this.

Thx,
RW Senser

RW Senser

Hi Peter,

Greetings.· I made a patch to CC1B2SX.· My testing shows it handles the error you hit.· Please give this a try and let me know if it handles the issue.

BTW, I saw your posting on the vp libs for C4SX, nice going.· The sxio.h is also based on the Ubicom·vp uart asm code.

Thanks,
RW Senser

Peter Verkaik

Downloaded and installed the patch.
Works.
For the sx18/20/28:
Now if only the CLRB 4.FSR_7 after a BANK ddd with ddd>=128
could be commented out, that would be great.

regards peter

Peter Verkaik

RW Senser,

The predefined TO (STATUS.4) and PD (STATUS.3) are also
sasm reserved words and should therefor be commented out.
But when using these, the generated code looks like
SB 3.TO
Not only complains sasm that TO and PD are reserved words,
TO and PD are not bit identifiers.
The correct way for sasm is
SB TO

Workaround:
define a TO_ and PD_ and use these instead of TO and PD.

shadowDef bit PD_ @STATUS.3;
shadowDef bit TO_ @STATUS.4;

When using the above declarations, the code generated looks like
SB 3.TO_
and that keeps sasm happy.

regards peter

RW Senser

Hi Peter,

Greetings.

Relative to "Now if only the CLRB 4.FSR_7 after a BANK ddd with ddd>=128" you might give the attached batch script a try.· At the beginning of it·are comments that show how to run it under Windows.

It just replaces all the CLRB 4.FSR_7 instructions·by NOPs.· My research shows that the CLRB instruction, after the BANK instruction,·is not needed on the SX18 and SX28 anyway.· I believe the SX48 is a different case.

Maybe this 'hack' will be useful until a real fix for CC1B is available.· I'm not inclined to put a 'hack' like this in CC1B2SX.

I've not tested this heavily -- the output from it does assemble correctly.

Thanks,
RW Senser

Peter Verkaik

Thanks for that script. I will try it, but I rather replace it with ;CLRB 4.FSR_7
so it is just commented out. Just in case·an incidental occasion must
be undone.
Can I change the line
··fobj_out.WriteLine("······ nop···· ;** removed **" + line·· );
simply to
··fobj_out.WriteLine("······ ;CLRB 4.FSR_7 ;** removed **" + line·· );

regards peter

Peter Verkaik

I changed the line to
··fobj_out.WriteLine("······ ;CLRB 4.FSR_7 ;** removed **"·);

and that works great. No need to include it in CC1B2SX. I can put
the script command into C4Sx.bat
The moment cc1b is bugfixed I can simply remove it from c4sx.bat

regards peter

RW Senser

Hi Peter-

I figured you would remove the NOP <<smile>>.

ALSO, I have two replies from the CC1B author. He says he has this bug fixed in the next release. He also gave me some additional information about an SX-48 bug. I'll posted his info tonight on this Forum. He's wanting to know about any other real CC1B problems (bugs). Do you know of any other real bugs with CC1B?

I'll be back online tonight (USA time).

Thanks,
RW Senser

Peter Verkaik

I do have another bug that is specific to sx18/20/28

void RomCopy(char dest, long source, char len) {
· char i = 0;
· while (len > 0) {
··· _SystemTemp = RomChar(source);
·char k = LargeArrayAddress(dest,i);
·_SystemRam[noparse][[/noparse]k] = _SystemTemp;
/*<?asm
·bank source ;;cc1b misses this statement
?>*/
·source++;
·i++;
·len--;
· }
}

cc1b misses a bank statement after writing a value using indf.
I fixed it by adding the bank statement. Note that it only works
while there is no other local parameter named source (otherwise cc1b
may rename source to source_1)

For sx48/52, the bank statement is generated by cc1b.

If not already, can you mail this bug also to B. Knudsen

regards peter

RW Senser

Hi Peter,

Greetings.

I need a small program that shows this error.· I wrote up the attached small C program but it does not have the failure when I call the RomCopy function.· I think I have experienced this same error in one of my larger test programs and it is hard to reproduce in a small pgm (at least it is/was for me).

My pgm·test pgm·is attached.· If you have time, could you enhance it to show the error?· If so, please· send it back to me, with·any includes being used so I can rerun the test.· I will then forward it to Bengt.

Thanks,
RWSenser

Peter Verkaik

See attachements. I included the generated .src

regards peter

RW Senser

Hi Peter,

Greetings. Thanks for these. I compiled your test case and verified the bug is shown.

I've sent the information on to the CC1B author.

Many thanks,
RW Senser

Peter Verkaik

Additional info:
In your cc1b-bug4.c, if you use
#pragma rambank 0

then the error also shows.
Appears to show only when using rambank 0

regards peter

RW Senser

Hi Peter,

Thanks for the update. I have a reply from the CC1B author. He says this will be fixed in the coming release and noted the following:

"This problem seem to be conceptual. Such large arrays on SX20/28 devices are possible, but unexpected. They are handled on the SX48/52 devices. The problem is now corrected in the source for the next release.

Workaround: Try inserting a manual bank update (Microchip format, see SX.TXT):
_SystemRam[noparse][[/noparse]k] = _MainTemp;
#asm m+
bank 0
#endasm
source++;
The compiler assumes that _SystemRam[noparse]/noparse resides in bank 0 according to the start address and therefore omit the bank instruction. Moving variable 'source' to another bank than 0 will also solve the problem"

It appears to me that his workaround does what you are already doing in yours.

Thanks,
RW Senser

Peter Verkaik

I found an even better way than using a fixed bank number.

void RomCopy(char dest, long source, char len) {
· char i = 0;
· while (len > 0) {
··· _MainTemp = RomChar(source);
·char k = LargeArrayAddress(dest,i);
·_SystemRam[noparse][[/noparse]k] = _MainTemp;
··· FSR = &source; //select correct bank
·source++;
·i++;
·len--;
· }
}

I also noticed that all 'asm code' between
/*<?asm and ?>*/
always gets inserted, also for library functions that are not used.
This is not a problem as this code is never called. But it does
consume codespace.

regards peter

Post Edited (Peter Verkaik) : 8/24/2007 4:46:12 AM GMT