Reply by Chris Hills November 21, 20072007-11-21
In message <4742cde8$0$30493$426a74cc@news.free.fr>, Habib 
Bouaziz-Viallet <habib@aldebaran.systems> writes
>Le Mon, 19 Nov 2007 16:13:52 +0000, Chris Hills a &#4294967295;crit: > >> In message <47419e83$0$20130$426a34cc@news.free.fr>, Habib >> Bouaziz-Viallet <habib@mizar.systems> writes >>>Le Mon, 19 Nov 2007 14:13:36 +0000, Chris Hills a &#4294967295;crit: >>> >>>> In message <xnejem5spe.fsf@delorie.com>, DJ Delorie <dj@delorie.com> >>>> writes >>>>> >>>>>Habib Bouaziz-Viallet <habib@mizar.systems> writes: >>>>>> Is the choice of the compiler is important ? >>>>> >>>>>Somewhat. N30 has a special syntax for saying "this variable lives at >>>>>this specific location in memory" that gcc doesn't support. GCC uses >>>>>linker tricks to do the equivalent, >>>> >>>> Apart from that other compilers may also use syntax that is different to >>>> either of those. >>>> >>>> That is why the choice of compiler needs to be known for the header >>>> files. If you did not know that should you be doing the project you are >>>> on? >>>Are you really understand what i'm talking about ? >> >> Yes I understand. >Do you ? To say at least, your posts prove me otherwise. >> >>> 'Cause i'm far from to >>>understand yours. >>> >>>Habib >> >> I know. That is a problem for you >> >My apologies M. Hills, i do not need to understand you because there's >nothing to understand. > >Habib.
There is not standard C for accessing hardware registers. You have already been told that two compilers do it differently . I know that most of the compiler vendors do their header files to access hardware differently. I know I have to support 6 different compiler makes. -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by Chris Hills November 21, 20072007-11-21
In message <47421A32.F91B9D02@yahoo.com>, CBFalconer 
<cbfalconer@yahoo.com> writes
>Chris Hills wrote: >> Habib Bouaziz-Viallet <habib@mizar.systems> writes: >>> Chris Hills a &#4294967295;crit: >>>> Habib Bouaziz-Viallet <habib@mizar.systems> writes >>>>> >>>>> I'm seeking about header C file for M32C/M16C internal >>>>> ressources (UART's, SSC, SPI, ... etc registers definition). >>>>> I guess there are some common reg and bits definition over >>>>> M32C/M16C family. >>>> >>>> For which compiler? >>> >>> IIs the choice of the compiler is important ? >> >> Yes. > >Not if the header is written in standard C and leaves the weird >translation and manipulation to the system sensitive .c file.
No such thing as "standard C" when referring to header files for hardware registers. Most compiler vendors have different ways of doing them -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by Habib Bouaziz-Viallet November 20, 20072007-11-20
Le Mon, 19 Nov 2007 16:13:52 +0000, Chris Hills a &eacute;crit:

> In message <47419e83$0$20130$426a34cc@news.free.fr>, Habib > Bouaziz-Viallet <habib@mizar.systems> writes >>Le Mon, 19 Nov 2007 14:13:36 +0000, Chris Hills a &eacute;crit: >> >>> In message <xnejem5spe.fsf@delorie.com>, DJ Delorie <dj@delorie.com> >>> writes >>>> >>>>Habib Bouaziz-Viallet <habib@mizar.systems> writes: >>>>> Is the choice of the compiler is important ? >>>> >>>>Somewhat. N30 has a special syntax for saying "this variable lives at >>>>this specific location in memory" that gcc doesn't support. GCC uses >>>>linker tricks to do the equivalent, >>> >>> Apart from that other compilers may also use syntax that is different to >>> either of those. >>> >>> That is why the choice of compiler needs to be known for the header >>> files. If you did not know that should you be doing the project you are >>> on? >>Are you really understand what i'm talking about ? > > Yes I understand.
Do you ? To say at least, your posts prove me otherwise.
> >> 'Cause i'm far from to >>understand yours. >> >>Habib > > I know. That is a problem for you >
My apologies M. Hills, i do not need to understand you because there's nothing to understand. Habib.
Reply by Habib Bouaziz-Viallet November 20, 20072007-11-20
CBFalconer a &#4294967295;crit :
> Chris Hills wrote: >> Habib Bouaziz-Viallet <habib@mizar.systems> writes: >>> Chris Hills a &#4294967295;crit: >>>> Habib Bouaziz-Viallet <habib@mizar.systems> writes >>>>> I'm seeking about header C file for M32C/M16C internal >>>>> ressources (UART's, SSC, SPI, ... etc registers definition). >>>>> I guess there are some common reg and bits definition over >>>>> M32C/M16C family. >>>> For which compiler? >>> IIs the choice of the compiler is important ? >> Yes. > > Not if the header is written in standard C and leaves the weird > translation and manipulation to the system sensitive .c file. >
The Perl Script (Many thanks to M. DJ Delorie) works fine ! Just make ./mkport.pl < reg_m16 and magically this script build a rm16c_port.h (and also an ASM file) !! Great Job indeed !! Habib
Reply by CBFalconer November 19, 20072007-11-19
Chris Hills wrote:
> Habib Bouaziz-Viallet <habib@mizar.systems> writes: >> Chris Hills a &#4294967295;crit: >>> Habib Bouaziz-Viallet <habib@mizar.systems> writes >>>> >>>> I'm seeking about header C file for M32C/M16C internal >>>> ressources (UART's, SSC, SPI, ... etc registers definition). >>>> I guess there are some common reg and bits definition over >>>> M32C/M16C family. >>> >>> For which compiler? >> >> IIs the choice of the compiler is important ? > > Yes.
Not if the header is written in standard C and leaves the weird translation and manipulation to the system sensitive .c file. -- Chuck F (cbfalconer at maineline dot net) <http://cbfalconer.home.att.net> Try the download section. -- Posted via a free Usenet account from http://www.teranews.com
Reply by Chris Hills November 19, 20072007-11-19
In message <47419e83$0$20130$426a34cc@news.free.fr>, Habib 
Bouaziz-Viallet <habib@mizar.systems> writes
>Le Mon, 19 Nov 2007 14:13:36 +0000, Chris Hills a &#4294967295;crit: > >> In message <xnejem5spe.fsf@delorie.com>, DJ Delorie <dj@delorie.com> >> writes >>> >>>Habib Bouaziz-Viallet <habib@mizar.systems> writes: >>>> Is the choice of the compiler is important ? >>> >>>Somewhat. N30 has a special syntax for saying "this variable lives at >>>this specific location in memory" that gcc doesn't support. GCC uses >>>linker tricks to do the equivalent, >> >> Apart from that other compilers may also use syntax that is different to >> either of those. >> >> That is why the choice of compiler needs to be known for the header >> files. If you did not know that should you be doing the project you are >> on? >Are you really understand what i'm talking about ?
Yes I understand.
> 'Cause i'm far from to >understand yours. > >Habib
I know. That is a problem for you -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by Habib Bouaziz-Viallet November 19, 20072007-11-19
Le Mon, 19 Nov 2007 14:13:36 +0000, Chris Hills a &eacute;crit:

> In message <xnejem5spe.fsf@delorie.com>, DJ Delorie <dj@delorie.com> > writes >> >>Habib Bouaziz-Viallet <habib@mizar.systems> writes: >>> Is the choice of the compiler is important ? >> >>Somewhat. N30 has a special syntax for saying "this variable lives at >>this specific location in memory" that gcc doesn't support. GCC uses >>linker tricks to do the equivalent, > > Apart from that other compilers may also use syntax that is different to > either of those. > > That is why the choice of compiler needs to be known for the header > files. If you did not know that should you be doing the project you are > on?
Are you really understand what i'm talking about ? 'Cause i'm far from to understand yours. Habib
Reply by Habib Bouaziz-Viallet November 19, 20072007-11-19
Le Mon, 19 Nov 2007 07:24:13 -0500, DJ Delorie a &eacute;crit:

> Habib Bouaziz-Viallet <habib@mizar.systems> writes: >> Is the choice of the compiler is important ? > > Somewhat. N30 has a special syntax for saying "this variable lives at > this specific location in memory" that gcc doesn't support. GCC uses > linker tricks to do the equivalent, although it's possible to write a > perl script that converts one to the other. However, I'm attaching a > simpler perl script I use to manually enter the I/O definitions > myself, and a sample (r8c-1b) definitions file. Run on on the other, > it creates a stand-alone .h (for C source) and a usable .S (for ASM > sources). > > -------------------- mkports -------------------- > #!/usr/bin/perl > # -*- perl -*- > > open(S, ">r8c-ports.S"); > open(H, ">r8c-ports.h"); > > print H "typedef unsigned char byte;\n\n"; > print H "typedef unsigned short word;\n\n"; > > while (<>) { > s/\#.*//; > s/[\r\n]+$//; > > ($name, $addr, $bits) = split(' ', $_, 3); > next unless $name =~ /\S/; > > $type = "byte"; > > if ($bits =~ /^\.HI\s*(.*)/) { > $type = "word"; > $bits = $1; > } > > if ($bits) { > print S "\n"; > print H "\n"; > $nl = "\n"; > } else { > print S $nl; > print H $nl; > $nl = ''; > } > print S "$name\t= 0x$addr\n"; > > if ($bits) { > $bitf = 0; > $unspec = 0; > $type = "${name}_type"; > print H "typedef union {\n"; > print H " struct {\n"; > $sbits = ''; > for $field (reverse split(' ', $bits)) { > if ($field eq ":") { > print H " byte unspec_$unspec:1;\n"; > $unspec ++; > $bitf ++; > } elsif ($field =~ /(.*):(\d)/) { > print H " byte $1:$2;\n"; > printf S " ${name}_$1\t= 0x%02x\n", ((1 << $2) - 1) << $bitf; > $bitf += $2; > } else { > print H " byte $field:1;\n"; > printf S " ${name}_$field\t= 0x%02x\n", 1 << $bitf; > $sbits .= sprintf " _$field\t= %d\n", $bitf; > $bitf ++; > } > } > print S $sbits; > print H " };\n"; > print H " byte b;\n"; > print H "} $type;\n"; > } > > print H "#define $name (*(volatile $type *)0x$addr)\n"; > } > -------------------- r8c-ports.def -------------------- > pd0 e2 > pd1 e3 > pd3 e7 > pd4 ea > p0 e0 > p1 e1 > p3 e5 > p4 e8 > > drr fe > > prcr 0a : : : : prc3 prc2 prc1 prc0 > > pm0 04 : : : : pm03 : : : > pm1 05 : : : : : pm12 : : > cm0 06 > cm1 07 > ocd 0c > > iccr1 b8 ice rcvd mst trs cks:4 > iccr2 b9 bbsy scp sdao sdaop sclo : iicrst : > icmr ba mls wait : : bcwp bc:3 > icier bb tie teit rie makie stie acke ackbr ackbt > icsr bc tdre tend rdrf nackf stop al aas adz > > # CPU control > > sar bd : : : : : : : fsb > icdrt be > icdrr bf > > pinsr1 f5 : : : : : : uart1sel:2 > pinsr2 f6 : trb0sel0 : : : : : : > pinsr3 f7 : : : trciodsel trciocsel : : > pmr f8 iicsel txd2en txd2sel u2pinsel ssesel : : int1sel > > # interrupt control > > inten f9 int3pl int3en : : int1pl int1en int0pl int0en > intf fa int3f:2 : : int1f:2 int0f:2 > > kupic 4d > adic 4e > ssuaic 4f > iic2aic 4f # i2c > cmp1ic 50 > s0tic 51 # serial 0 transmit > s1tic 53 # serial 1 transmit > s0ric 52 # serial 0 receive > s1ric 54 # serial 1 receive > txic 56 # Timer X > traic 56 # Timer A > tzic 58 # Timer Z > trbic 58 # Timer B > int1ic 59 > int3ic 5a > tcic 5b # Timer C > cmp0ic 5c > int0ic 5d > > # UARTs > > u0mr a0 : prye pry stps ckdir smd:3 > u0brg a1 > u0tb a2 > u0c0 a4 uform ckpol nch : txept : clk:2 > u0c1 a5 : : : : ri re ti te > u0rb a6 .HI > > u1mr a8 : prye pry stps ckdir smd:3 > u1brg a9 > u1tb aa > u1c0 ac uform ckpol nch : txept : clk:2 > u1c1 ad : : : : ri re ti te > u1rb ae .HI > > ucon b0 cntrsel : u1sel:2 : u0rrm u1irs u0irs > > # Timer X (r8x-1b) > > txmr 8b txund txedg txmod2 txocnt txs r0edg txmod:2 > prex 8c > tx 8d > > # Timer Z (r8c-1b) > > tzmr 80 tzs tzwc tzmod:2 : : : : > pum 84 inosec inostg tzopl : : : : > prez 85 > tzsc 86 > tzpr 87 > tzoc 8a : : : : : : : tzos > tcss 8e : : tzck:2 : : txck:2 > > # Timer A (r8c-26) > > tracr 100 : : tundf tedgf : tstop tcstr tstart > traioc 101 : : tipf:2 tiosel toena topcr tedgsel > tramr 102 tckcut tck:3 : tmod:3 > trapre 103 > tra 104 > > # Timer B (r8c-26) > > trbcr 108 : : : : : tstop tcstr tstart > trbocr 109 : : : : : tosstf tossp tosst > trbioc 10a : : : : inoseg inostg tocnt topl > trbmr 10b tckcut : tck:2 twrc : tmod:2 > trbpre 10c > trbsc 10d > trbpr 10e > > # Timer C (r8c-1b) > tc 90 .HI > tm0 9c .HI > tm1 9e .HI > tcc0 9a tc0iisb tc0int3 : tc0icp:2 tc0ssb:2 tc0sb > tcc1 9b tc10oms:2 tc11oms:2 tc10csb tc1rs tc1if:2 > tcout ff
Rrriiiight ! That is exactly what i need ! Many Thanks M. Delorie.
Reply by Chris Hills November 19, 20072007-11-19
In message <xnejem5spe.fsf@delorie.com>, DJ Delorie <dj@delorie.com> 
writes
> >Habib Bouaziz-Viallet <habib@mizar.systems> writes: >> Is the choice of the compiler is important ? > >Somewhat. N30 has a special syntax for saying "this variable lives at >this specific location in memory" that gcc doesn't support. GCC uses >linker tricks to do the equivalent,
Apart from that other compilers may also use syntax that is different to either of those. That is why the choice of compiler needs to be known for the header files. If you did not know that should you be doing the project you are on? -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by November 19, 20072007-11-19
Habib Bouaziz-Viallet <habib@mizar.systems> writes:
> Is the choice of the compiler is important ?
Somewhat. N30 has a special syntax for saying "this variable lives at this specific location in memory" that gcc doesn't support. GCC uses linker tricks to do the equivalent, although it's possible to write a perl script that converts one to the other. However, I'm attaching a simpler perl script I use to manually enter the I/O definitions myself, and a sample (r8c-1b) definitions file. Run on on the other, it creates a stand-alone .h (for C source) and a usable .S (for ASM sources). -------------------- mkports -------------------- #!/usr/bin/perl # -*- perl -*- open(S, ">r8c-ports.S"); open(H, ">r8c-ports.h"); print H "typedef unsigned char byte;\n\n"; print H "typedef unsigned short word;\n\n"; while (<>) { s/\#.*//; s/[\r\n]+$//; ($name, $addr, $bits) = split(' ', $_, 3); next unless $name =~ /\S/; $type = "byte"; if ($bits =~ /^\.HI\s*(.*)/) { $type = "word"; $bits = $1; } if ($bits) { print S "\n"; print H "\n"; $nl = "\n"; } else { print S $nl; print H $nl; $nl = ''; } print S "$name\t= 0x$addr\n"; if ($bits) { $bitf = 0; $unspec = 0; $type = "${name}_type"; print H "typedef union {\n"; print H " struct {\n"; $sbits = ''; for $field (reverse split(' ', $bits)) { if ($field eq ":") { print H " byte unspec_$unspec:1;\n"; $unspec ++; $bitf ++; } elsif ($field =~ /(.*):(\d)/) { print H " byte $1:$2;\n"; printf S " ${name}_$1\t= 0x%02x\n", ((1 << $2) - 1) << $bitf; $bitf += $2; } else { print H " byte $field:1;\n"; printf S " ${name}_$field\t= 0x%02x\n", 1 << $bitf; $sbits .= sprintf " _$field\t= %d\n", $bitf; $bitf ++; } } print S $sbits; print H " };\n"; print H " byte b;\n"; print H "} $type;\n"; } print H "#define $name (*(volatile $type *)0x$addr)\n"; } -------------------- r8c-ports.def -------------------- pd0 e2 pd1 e3 pd3 e7 pd4 ea p0 e0 p1 e1 p3 e5 p4 e8 drr fe prcr 0a : : : : prc3 prc2 prc1 prc0 pm0 04 : : : : pm03 : : : pm1 05 : : : : : pm12 : : cm0 06 cm1 07 ocd 0c iccr1 b8 ice rcvd mst trs cks:4 iccr2 b9 bbsy scp sdao sdaop sclo : iicrst : icmr ba mls wait : : bcwp bc:3 icier bb tie teit rie makie stie acke ackbr ackbt icsr bc tdre tend rdrf nackf stop al aas adz # CPU control sar bd : : : : : : : fsb icdrt be icdrr bf pinsr1 f5 : : : : : : uart1sel:2 pinsr2 f6 : trb0sel0 : : : : : : pinsr3 f7 : : : trciodsel trciocsel : : pmr f8 iicsel txd2en txd2sel u2pinsel ssesel : : int1sel # interrupt control inten f9 int3pl int3en : : int1pl int1en int0pl int0en intf fa int3f:2 : : int1f:2 int0f:2 kupic 4d adic 4e ssuaic 4f iic2aic 4f # i2c cmp1ic 50 s0tic 51 # serial 0 transmit s1tic 53 # serial 1 transmit s0ric 52 # serial 0 receive s1ric 54 # serial 1 receive txic 56 # Timer X traic 56 # Timer A tzic 58 # Timer Z trbic 58 # Timer B int1ic 59 int3ic 5a tcic 5b # Timer C cmp0ic 5c int0ic 5d # UARTs u0mr a0 : prye pry stps ckdir smd:3 u0brg a1 u0tb a2 u0c0 a4 uform ckpol nch : txept : clk:2 u0c1 a5 : : : : ri re ti te u0rb a6 .HI u1mr a8 : prye pry stps ckdir smd:3 u1brg a9 u1tb aa u1c0 ac uform ckpol nch : txept : clk:2 u1c1 ad : : : : ri re ti te u1rb ae .HI ucon b0 cntrsel : u1sel:2 : u0rrm u1irs u0irs # Timer X (r8x-1b) txmr 8b txund txedg txmod2 txocnt txs r0edg txmod:2 prex 8c tx 8d # Timer Z (r8c-1b) tzmr 80 tzs tzwc tzmod:2 : : : : pum 84 inosec inostg tzopl : : : : prez 85 tzsc 86 tzpr 87 tzoc 8a : : : : : : : tzos tcss 8e : : tzck:2 : : txck:2 # Timer A (r8c-26) tracr 100 : : tundf tedgf : tstop tcstr tstart traioc 101 : : tipf:2 tiosel toena topcr tedgsel tramr 102 tckcut tck:3 : tmod:3 trapre 103 tra 104 # Timer B (r8c-26) trbcr 108 : : : : : tstop tcstr tstart trbocr 109 : : : : : tosstf tossp tosst trbioc 10a : : : : inoseg inostg tocnt topl trbmr 10b tckcut : tck:2 twrc : tmod:2 trbpre 10c trbsc 10d trbpr 10e # Timer C (r8c-1b) tc 90 .HI tm0 9c .HI tm1 9e .HI tcc0 9a tc0iisb tc0int3 : tc0icp:2 tc0ssb:2 tc0sb tcc1 9b tc10oms:2 tc11oms:2 tc10csb tc1rs tc1if:2 tcout ff