C4SX: New Release of C4SX Version 0.3

RW Senser

Hello all-

I am very happy to announce C4SX Version 0.3: It contains several nice enhancements and ALL known CC1B compiler bugs are fixed. If you are interested in C language programing for the SX, please read on!

Details:

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 significant SX-Key specific·improvements in the CC1B compiler and in the C4SX script and utility program. 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 much-improved beta 3 C4SX Zip File" link. 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.

Thanks,
RW Senser

Peter Verkaik

RW Senser,

I downloaded and installed version 0.3
No problems.

I also checked the cc1b (0.7A) output directly.
It loads directly into sxkey ide with only warnings that some directives are not set
This is of course no issue with your conversion, but it is good to see
that the cc1b output is almost sasm compatible.
Are there plans that cc1b outputs #pragma asmDir:
content directly into the assembly output?

I am glad you leave the /*<?asm - >?*/ block conversion in.
That is still the best way to include masm macros in case we need some of those.

regards peter


Post Edited (Peter Verkaik) : 9/6/2007 3:21:52 AM GMT

RW Senser

Hi Peter,

Greetings.

I'll run a couple of tests (concering the 'reset main'). I did see these statements occur (at the end of the source files) earlier. If you happen to somehow have CC1B 0.7, and not 0.7A, this would give the behavior you are seeing.

Yah, I think having the /*<?asm .... >?*/ functionality remain is important for various reasons. One of them is backwards compatibility.

Thanks,
RW Senser

Peter Verkaik

Yes, I used version 0.7 (see my edited post above)
Version 0.7A does it right.
It does not output the #pragma asmDir:
directly. I assume your conversion still takes care of that.

regards peter

Peter Verkaik

RW Senser,
As the number of libraries grow (and thus the number of functions) I was looking for some
free documentation tool. DoxyS
http://www.codeproject.com/tools/DoxyS.asp
seems to do a great job.
There is only an executable doxys.exe and a configuration file DoxySfile
and when placed in the project directory, doubleclick doxys.exe from
windows explorer and it creates a browsable (html pages) document
for all functions, types, macros, variables. I tried it for my libraries and the output
is quite nice. The overview page (see attachement) shows all functions.
If you think this is usable, perhaps we should encourage its use. My library
comments only need little changes for DoxyS to do even better (sometimes
the brief function description appears·twice due to missing . or newline).
It allows hiding of private members (static in C) so it is possible to only document
public library functions.

regards peter

Peter Verkaik

I found a better tool: doxygen
http://www.stack.nl/~dimitri/doxygen/download.html#latestsrc

Attached is a rtf document generated by doxygen that you can load into word.
doxygen also generates·browseable html.
I am in·the process of adapting the source comments for my libraries
so doxygen can deliver the best output. (the attached refman.rtf·is not the final
documentation)

regards peter

Peter Verkaik

RW Senser,
Attached are my libraries, that now includes documentation.
Just unzip it into the C4SX folder. It creates a lib folder that
holds the libraries and a configured Doxyfile file.
It overwrites the c4sx.bat with a new one that has an
added -I"%C4SX_PATH%\lib" cc1b parameter.

The libraries have been placed in subfolders to make
it easier to maintain the libraries.

If you have unzipped the attachement and installed Doxygen,
run start->program files->doxygen->doxywizard
In step 1, click Load... and navigate to c:\c4sx\lib
and select Doxyfile
Then go to step·4: click start.
The html and rtf documentation is now generated.
To view the rtf file, navigate in windows explorer to
c:\c4sx\lib\libdocs\rtf and open refman.rtf (in Word)
To·view the html, navigate in windows explorer to
c:\c4sx\lib\libdocs\html and open index.html

Now whenever the libraries are updated, simply start doxygen,
load the doxyfile from c:\c4sx\lib, and click start to generate updated documentation.

The attached test file no longer uses
#pragma sx48 //select device
Instead it uses
#include <sxdevice/sx48.h> //select device
The advantage of this is that generated documentation for the test file
can make use of defined chip parameters.

To make the test program work for an sx28, it is sufficient
to change the device line to
#include <sxdevice/sx28.h> //select device

regards peter

Peter Verkaik

Not being satisfied with the generated rtf output, I tried the generated latex output.
I downloaded the MikTex package (basic, v2.6):
http://miktex.org/2.6/Setup.aspx

Install MikTex
Create a folder c:\c4sx\lib\libdocs\latex
put the attached Doxyfile into c:\c4sx\lib
put the attached makepdf.bat into c:\c4sx\lib\libdocs\latex

Let Doxygen generate the documentation.
Then navigate to c:\c4sx\lib\libdocs\latex with windows explorer.
Doubleclick the makepdf.bat file
MikTex probably asks to install additional files. Accept.

MikTex creates a refman.pdf file with hyperlinks so you can
browse through the pdf.
The generated pdf is attached. It has pagenumbers and an index.

regards peter

RW Senser

Hi Peter,

Greetings.· I'll download these and take a look.

I noticed that Makepdf.bat has length 0; is that intended?

Thanks,
RW Senser

pwillard

It's just a teeny weeny file with 3 lines of code.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

---

There's nothing like a new idea and a warm soldering iron.

Peter Verkaik

Yes, that is correct.
Those are the 3 lines from the makefile file in the
latex directory.
I could not get the makefile to work with MikTex,
so I put the important lines in a batch file.

regards peter

Peter Verkaik

RW Senser,
I think I discovered an optimization bug.

From my working vp_test.c
TaskSwitch() is located in page0

void TaskSwitch(char W) //gets called from page 3
{
· switch (W & 0x3F) { //call task, returns within 1 tasktick
·· case TXDEQUEUE: TxDequeue(); break; //TxDequeue has identifier 1
·· case RXENQUEUE: RxEnqueue(); break; //RxEnqueue has identifier 2
· }
}

gets compiled into
TaskSwitch
······················· ;· switch (W & 0x3F) { //call task, returns within 1 tasktick
······· AND·· W,#63
······· XOR·· W,#1
······· SNB·· 3.Zero_
······· JMP·· m063
······· XOR·· W,#3
······· SNB·· 3.Zero_
······· JMP·· m064
······· JMP·· m065
······················· ;·· case TXDEQUEUE: TxDequeue(); break; //TxDequeue has identifier 1
m063··· CALL· TxDequeue
······· JMP·· m065
······················· ;·· case RXENQUEUE: RxEnqueue(); break; //RxEnqueue has identifier 2
m064··· CALL· RxEnqueue
······················· ;· }
······················· ;}
m065··· RETP

Note that TaskSwitch() exits at m065 (retp)

Now changing TaskSwitch() to
void TaskSwitch(char W) //gets called from page 3
{
· switch (W & 0x3F) { //call task, returns within 1 tasktick
·· case TXDEQUEUE: TxDequeue(); return; //TxDequeue has identifier 1
·· case RXENQUEUE: RxEnqueue(); return; //RxEnqueue has identifier 2
· }
}
(the breaks are replaced by returns, should make no difference)

Gets compiled into
TaskSwitch
······················· ;· switch (W & 0x3F) { //call task, returns within 1 tasktick
······· AND·· W,#63
······· XOR·· W,#1
······· SNB·· 3.Zero_
······· JMP·· TxDequeue
······· XOR·· W,#3
······· SNB·· 3.Zero_
······· JMP·· RxEnqueue
······················· ;·· case TXDEQUEUE: TxDequeue(); return; //TxDequeue has identifier 1
······················· ;·· case RXENQUEUE: RxEnqueue(); return; //RxEnqueue has identifier 2
······················· ;· }
······················· ;}
m063··· RETP

TaskSwitch() now does not exit at m063 (retp) but at either TxDequeue() or RxEnqueue()
because cc1b replaced the calls with a jump (optimization). The task subroutines exit with a ret (not a retp)
and thus the pagebits are not restored.

SxSim generates a "RETIW caused RTCC overflow" error when using the returns.

regards peter

RW Senser

Hi Peter,

Greetings.· Attached is a small test program that I think shows the optimization bug, called·bug9.c.· Could you give it a quick review and it you think it shows the bug, I'll send your description and this program on to the CC1B author.

Thanks,
RW Senser

Peter Verkaik

RW Senser,
Attached is a modified program that really shows it.
The original had a 'ret' instead of 'retp' at the end of TaskSwitch(),
whereas TaskSwitchRet() had a retp but that was never reached,
so both routines failed to return to page3.
Both programs now assemble ok.

I also discovered SxSim has a·bug (bug9a.c), in that at the end of
TaskSwitchRet() $61E is on the stack, after ret, the pagebits
remain 0 (as they must after ret) and PC becomes $1E,
but the listing shows $61E (??) which is where the program
should continue, if retp was used.

Also, in bug9a.c, fromPage3_1 exits with a ret which should be a retp
to return to page0.

I think if only retp's are used, all these errors are resolved, but
then there must be a page instruction before any call to another page.
(meaning page 1536 must be inserted before call to fromPage3_2).

regards peter

Post Edited (Peter Verkaik) : 9/17/2007 4:17:16 AM GMT

RW Senser

Hi Peter,

Greetings. I have forwarded this to the CC1B author.

Thanks,
RW Senser

Peter Verkaik

Updated libraries.
I added a Timer.h library that provides 8/16/24/32 bit timers.
These timers are task aware, so Virtual Peripherals, Tasks and Timers
can all be used together.

The attached test program (SX48) demonstates this by blinking a led
at portpin RB.1 while receiving and transmitting serial data.
To make this program work for an sx28, just change
the first include to
#include <sxdevice/sx28.h> // select device

Just unzip libraries.zip in folder C:\C4SX\lib
The updated library reference manual is also attached (refman.pdf).
Pages 105-107 contain a detailed description of the Timer objects.

The file vp_test.txt is identical to vp_test.c but for online viewing.

regards peter



Post Edited (Peter Verkaik) : 9/21/2007 2:57:26 PM GMT

Peter Verkaik

I discovered another bug. It shows when using a bit variable as array index.

char p;
bit vpPwm_state @ p.7;
unsigned long vpPwm_signal[noparse][[/noparse]2];
unsigned long vpPwm_count;

· p = 2;
· vpPwm_state = 1;
· vpPwm_count = vpPwm_signal[noparse][[/noparse]vpPwm_state]; \

The code generated is

······················· ;· p = 2;
······· MOV·· W,#2
······· BANK· 16
······· CLRB· 4.FSR_7
······· MOV·· p,W
······················· ;· vpPwm_state = 1;
······· SETB· 16.vpPwm_state
······················· ;· vpPwm_count = vpPwm_signal[noparse][[/noparse]vpPwm_state]; \
······· MOV·· W,#17
······· ADD·· W,vpPwm_state ; **** WRONG
······· ADD·· W,vpPwm_state ; **** WRONG
······· MOV·· FSR,W
······· MOV·· W,INDF
······· MOV·· vpPwm_count,W
······· INC·· FSR
······· MOV·· W,INDF
······· MOV·· vpPwm_count+1,W

If vpPwm_state is not assigned to bit0 (above to bit7) nothing gets added to W,
if it is assigned to bit0, the whole byte (= p) is added to W.

Workaround: do not use a bit variable as array index.

regards peter

RW Senser

Hi Peter,

Greetings.

Thanks for reporting this. I'll reproduce it and forward.

RW Senser

RW Senser

Hi Peter,

Greetings. I'll be sending this new bug to the CC1B author this evening. In the mean time, here is a reply on the previous bug you found.

Thanks,
RW Senser

reply snippet:

"Using the -b option allowed the problem to be reproduced on the initial source example.

The problem is now understood. It will take more time to fix it. I will let you know about next release.

Workaround: Rewrite source code where CALL+RETURN is replaced by GOTO. You can search for T-GOTO in the generated *.FCS file (option -Q), and inspect these cases. Alternatively experiment using retp(), but this may have other optimization consequences not outlined.

Thank you for the report."

Peter Verkaik

Library update.
I added two libraries, vpAdc.h (sigma delta ADC 1-15 bits) and vpPwm.h (16bits PWM)
and expanded the Timer.h library

The Timer.h has an additional 3 functions:
The functions Timer_markUSEC(), Timer_markMSEC() and Timer_markSEC() select the minimal shift value required
to get a specific timeout in microseconds, milliseconds or seconds. This is real time and the timer value
depends on used CPUFREQ and INTPERIOD settings. Basically these functions hide all
the details regarding ticks and shiftvalues. If the requested timeout cannot be generated for the
used Timer object and/or used CPUFREQ and INTPERIOD, then a compile error is generated.
You can now just use
Timer_markUSEC(t,4000); //let t expire in 4000 microseconds
These functions do not generate more code, they just take away the burden of finding
the correct shiftvalue.

Also updated is the interrupt routine. With the Timer and Task code running, there are only
enough ISR cycles to run 2 VP's each interrupt. The adapted ISR routine takes care of that
by introducing a compile time constant VPRATIO that is automatically calculated for
the number of VPSLOTS used.

Just unzip libraries.zip in folder C:\C4SX\lib

It is important that the cc1b compiler evaluates·constant expressions to 32bits.
For this the -cu option must be included in the cc1b call.
The attached C4SX.bat has that. Just copy it to folder·C:\C4SX

regards peter

RW Senser

Hi Peter,

Here is a reply to your 9/27 posting about the 2nd C4SX bug:

"The bit bug looks interesting. The expression is ok for BYTE elements, but fails for 16 bit and above. It translates to a generic expression:

var = ConstA + ConstB * bitVar;

This will now be supported for the next version. Thanks for the report."

So there are two outstanding bugs (the first in this thread's 9/14 posting and the 2nd in this thread's 9/21 posting) for the next version of CC1B. No date is yet suggested for this next version. Since these are "advance coding" bugs, I suspect they won't impact many people.

Thanks,
RWSenser