You put it very clear. The question now is if the PIC would at least be able to represent a board and make some moves without committing suicide. Maybe it could be used for some purpose: for example, to control positions of the pieces on the board, and things like that, then, a more powerful processor would be used for computations. But to start, I would prefer a PIC, since it's easier to program than other, more complex, solutions.
Thanks!! If any more comments, please, let me know!! 2008/8/14 Raphael Neider <[EMAIL PROTECTED]>: >> BTW, I have realized that I was compiling for the default target, not >> PIC16. Now, I'm getting some linker errors. I'm attaching the sources, >> you can test it just with >> # make >> >> I have commented out "puts" and "#include <assert.h>" and two assertions. >> But I still get the following: >> >> [EMAIL PROTECTED]:~/Desktop/chess/firstchess/pic16$ make >> sdcc firstchess.c -mpic16 -o firstChess > > You are compiling for the default pic18f452, which may or not be what > you want. Select the desired target chip with -mpic16 -p18f6720 (replace > 6720 with your device code). > >> message: using default linker script "/usr/share/gputils/lkr/18f452.lkr" >> warning: relocation of section "udata_firstchess_7" failed, relocating >> to a shared memory location >> error: linker script has no definition that matches the type of >> section "udata_firstchess_7" >> make: *** [all] Error 1 >> >> Any idea?? Thanks! > > Yes: You are out of memory, and even if the device had enough memory, > you fail to respect the data banking scheme of the PICs (BSR register). > > 1) You allocate the HIST hist[6000] array of 48000 bytes; the 18f452 > only has 6 banks of 256 bytes ==> 1536 bytes of memory. > > 2) The 18f6720 has 15 banks of 256 bytes of memory ==> 3840 bytes, which > is all the PIC architecture can address (16 bank is split into access > bank and SFRs and not available for general use). > > 3) Even if your array was the only data structure and was only 257 bytes > in size, this error would occur still. The data memory is organized in > banks of 256 bytes; no single object can be longer than that (has to do > with BANKSEL directives and compiler internal assumptions about each > structure/array residing completely in a single bank). > In short, you must cut down the hist structure to (say) HIST hist[32], > or modify the .lkr file to create a huge bank to accommodate *only* this > array (you would have to make sure that other objects allocated to that > superbank do not cross 256-byte boundaries, which you cannot do ==> > problem in the linker rather than the compiler). Even then I cannot > guarantee that the array access works as expected in all cases (it > should, but such a setup is highly unusual and untested). > > Such problems caused my initial doubts on playing chess on a > microcontroller. Knowing that you want to use PICs, I cannot see how to > solve them: Other devices (8051-derivatives) have external memory, which > might be useful in this case (if they can address 64 kB of memory), but > with PICs I can only think of manually attached memory via 2 or more 8 > bit ports for addresses and data, SPI, ... > > Good luck, > Raphael > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Sdcc-user mailing list > Sdcc-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sdcc-user > -- Néstor +34 687 96 74 81 [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
