Druckbare Version
Hallo,
ich würde dann bei Code der auf 8- und 32-Bit Arduino laufen soll, besser auf diese neuen Datentypnamen zurückgreifen:
http://en.cppreference.com/w/cpp/types/integer
Dann sieht man besser, was gemeint ist. Den int16_t hatten wir ja weiter oben schon.
int16 vers. int32 liegt auf der Hand, aber nachdem ein 8-bit AVR (int16) und auch ein 32 bit PC und ein 64 bit PC (beide int32) funktioniert haben, nur eben der 32bit ARM Cortex nicht, konnte es kaum daran gelegen haben. Trotzdem hatte ich es ntl bereits getestet.
(Und PeterTOO: char ist bei C doch immer 8 bit, nicht 32, zumindest bei gpp, Sketch, ToppersC, devcpp und CLANG und ntl auch hier in allen diesen angesprochenen Plattformen von AVR bis PC - wie kommst du darauf?)
Der hanebüchene Unsinn ist doch, dass Sketch mit demselben Sourcecode einmal für den Mega signed char und für den Due unsigned char compiliert, bloß weil es ARM und nicht AVR ist - welcher normal denkende Mensch, der nicht embedded C mit der Muttermilch aufgesogen hat, kommt denn auf diesen Mist ??
Zumal gerade Sketch für unsigned char einen eigenen Datentyp zur Verfügung stellt, nämlich byte ?!?!
Und Sketch ist schließlich für Arduino-Programmierer, die - behaupte ich mal - überwiegend KEINE Profi-Programmierer sind!
Und ich möchte mal wirklich gerne einen Querschnitt über alle hier jemals von Forumsmitgliedern prorgammierten Codes sehen, ob da wirklich "immer schon" explizit signed oder unsigned vor jedem char steht. Sicher nicht, warum auch?
Noch nicht einmal der Programmierer, sicher Profi, wenn auch nicht hauptberuflich, von dem der hier diskutierte Sourcecode ursprünglich stammt, hat es weder selber gemacht noch irgendwo in seinen über 30 Seiten langen Erklärungen auch nur andeutungsweise auf diese Plattformabhängigkeit hingewiesen.
Aber selbst hier im Forum mit seiner gesammelten Schwarmintelligenz hat NIEMAND vorher auch nur den VERDACHT geäußert, dass es daran liegen könnte.
HINTERHER ist es ntl einfach zu sagen: klar, hab ich gewusst, mache ich immer schon so. Toll.
Diese ARM-(C-Compiler-Programmier-) Leuchter die sich diese gequirlte signed/unsigned char- Schei*** auf derselben (Sketch-) IDE ausgedacht haben sollte man doch wirklich an die Wand stellen, also wirklich... :mad:
Immerhin sind wir jetzt alle klüger (zumindest die, die es seit 30 Jahren nicht sowieso immer schon so gemacht haben) und viele können sicher davon profitieren - auch sicher die, die hier tatkräftig mitgeholfen haben:
an euch dafür nochmal ausdrücklich einen herzlichen Dank ! :cool:
Bei diesen fundamentalen Diskussionen kann ich als kleines Licht in C ja wirklich nicht mitreden. Aber ich weiß ganz gewiss, dass im ANSI-Standard die Größe char als ein Byte bzw. die kleinste, adressierbare Größe einer Maschine definiert ist - und damit keine Festlegung auf eine bestimmte Bitanzahl existiert. In C11 wurden zur Unterstützung von Unicodes dann char16_t und char32_t eingeführt. Andererseits war in den Fünfzigern bei IBM das Byte zeitweise sogar nur sechs Bit groß *ggg*.Zitat:
... char ist bei C doch immer 8 bit, nicht 32, zumindest bei gpp, Sketch, ToppersC, devcpp und CLANG und ...
Da ich die oben aufgeführten Programmiersprachen nicht oder kaum und C nicht bis in die letzten Ecken kenne und da ich insbesondere mit Compilerbau nur sehr speziell beschäftig war, wundere ich mich jedenfalls nicht über die hier diskutierte Falschrechnerei.
Hallo,
Diese gibt es erst seit ANSI C 2011 als Standard.Zitat:
Zitat von Mxt
Ich bin mich ja auch am umgewöhnen.
1985 gab es noch Macro-Header, damit C wie Pascal aussieht :-(
Es gab da, vor allem in Deutschland, eine Gruppe, welche BEGIN und END besser fand als { und }.
MfG Peter(TOO)
- - - Aktualisiert - - -
Hallo,
Wie schon K&R macht auch ANSI keine konkreten Vorgaben dazu.Zitat:
Zitat von HaWe
Wie sich ein Compiler konkret verhält ist im Anhang "Compiler-Specific" des Compiler-Manuals beschrieben, dieses Kapitel wird von ANSI vorgeschrieben.
Leider ist auch der ANSI C Standard nicht frei verfügbar, ich zitiere deshalb, was ich so finden kann.
http://www.open-std.org/jtc1/sc22/wg...onaleV5.10.pdf
(Ist zwar C99, das hat sich aber nicht grundlegend geändert)
Seite 3:
The potential for efficient code generation is one of the most important strengths of C. To help ensure that no code explosion occurs for what
appears to be a very simple operation, many operations are defined to be how the target
machine’s hardware does it rather than by a general abstract rule. An example of this
willingness to live with what the machine does can be seen in the rules that govern the widening
of char objects for use in expressions: whether the values of char objects widen to signed or
unsigned quantities typically depends on which byte operation is more efficient on the target
machine.
signed oder unsiged hängt also davon ab, was die CPU effizienter verarbeiten kann. Gibt's da bei der CPU keinen Unterschied, kann der Compilerbauer frei wählen. Selbiges gilt für die Anzahl Bits in einem Byte.
Vielleicht muss ich noch einen Abstecher in die Geschichte machen.
Der Fachbegriff für 8-Bit Worte ist Oktett oder Octet. Wurde von CCITT, heute ITU, mal definiert.
Vor den 70er Jahren gab es nur Worte (Words), das war das was die CPU als kleinste Einheit transportieren konnte, das war praktisch Alles zwischen 8 und 48 Bit, je nach Registergrösse und Busbreite, also CPU abhängig.
Das Byte kam dann erst durch die Hobbycomputer-Scene und meinte damals noch 8-Bit, weil die meisten CPUs einen 8-Bit Bus hatten.
Byte kommt von Bite (Biss, Bissen), das war das was die CPU auf einmal vom Speicher "abbeissen" konnte, also ein Synonym für Wort.
Seite 11:
3. Terms and definitions
The definitions of object, bit, byte, and alignment reflect a strong consensus, reached after
considerable discussion, about the fundamental nature of the memory organization of a C
environment:
• All objects in C must be representable as a contiguous sequence of bytes, each of which
is at least 8 bits wide.
• A char whether signed or unsigned, occupies exactly one byte.
(Thus, for instance, on a machine with 36-bit words, a byte can be defined to consist of 9, 12, 18,
or 36 bits, these numbers being all the exact divisors of 36 which are not less than 8.) These
10 strictures codify the widespread presumption that any object can be treated as an array of
characters, the size of which is given by the sizeof operator with that object’s type as its
operand.
Ein Byte ist nur garantiert nicht kürzer als 8-Bit!
Seite 25:
The macro CHAR_BIT makes available the number of bits in a char object. The C89
Committee saw little utility in adding such macros for other data types.
Macht keinen Sinn, wenn char immer 8-Bit ist ;-)
Seite 65:
6.5.3.4 The sizeof operator
It is fundamental to the correct usage of functions such as malloc and fread that
sizeof(char) be exactly one. In practice, this means that a byte in C terms is the smallest
unit of storage, even if this unit is 36 bits wide; and all objects are composed of an integer
number of these smallest units. Also applies if memory is bit addressable.
Das sollte erst mal reichen.
Die Definition von Byte in C hat sich eigentlich nie geändert. Als C entwickelt wurde war es noch üblich, dass CPUs "komische Wortbreiten" verwendeten. Damals waren auch noch Sektorgrössen von 100 oder 200 Oktetts bei Plattenspeichern üblich.
Das CPUS einheitlich eine Busbreite basierend auf 2er Potenzen haben (8, 16, 32 ...) ist eine neuere Entwicklung, welche erst mit dem Mikroprozessoren begann.
Wie ich schon erwähne, sind davon abweichende Busbreiten vor allem bei DSP zu finden, da geht es rein um die Effizienz.
Allerdings haben z.B. die PICs teilweise auch Bus- und Wortbreiten von 12 Bit.
MfG Peter(TOO)
bleiben wir doch bitte mal auf dem Teppich.
Wir reden hier von gängigen Compilern (Sketch, gpp, Clang, devcpp) für AVR, Windows XP oder 7 PCs 32 oder 64 bit, ARM (Cortex) und Beaglebone Black.
Wo ist da bitteschön char mit mehr als 8 bit ??
Also jetzt bitte keine geschichtsträchtigen Dozentenvorträge über Annodazumal und Adam und Eva und irgendwelche Kolibriplattformen.
Es geht auch gar nicht um das, was definiert ist oder nicht oder 8-bit char oder nicht oder mehr oder hin oder her, sondern schlicht darum:
Der Sketch-Mist besteht darin, dass immer char als 8-bit und signed kompiliert wurde und wird (und übrigens auch für die Windows-Plattformen), woran man sich gewöhnt hat, gerade weil es für "unsigned char" ja auch "byte" verwendet (obwohl "byte" kein standardmäßiger C-Datentyp ist) -
jetzt aber wird char von Sketch im selben Sourcecode plötzlich, nur für den Due, mit unsigned übersetzt, und damit fällt auch plötzlich der Unterschied zu "byte".
Nimmt man genau diesen Sourcecode bei weiterhin geöffnetem Editor und wählt als Ziel wieder einen AVR, ist es aber wieder signed wie früher. Selber Code, beides Arduino-Sketch, beides dieselbe Version, beides Arduino-Boards, aber 2 verschiedene Rechenergebnisse.
Natürlich dürfen die (Arduino-) Entwickler mit ihrem Compiler, auf Deutsch gesagt, jeden Scheißdreck machen, gerade wenn es nicht fest definiert ist, und es trotzdem als C verkaufen.
Besser wird es dadurch aber nicht.
Allerdings scheine ich der einzige zu sein, der hier bisher darüber gestolpert ist.
Gut immerhin, dass wir alle es jetzt besser wissen.
Hallo,
Du hast mir widersprochen und behauptet, dass char in C immer 8-Bit hat.Zitat:
Zitat von HaWe
Dem ist aber, nach Norm, nicht so.
GCC ist da auch unterschiedlich, je nach verwendetem Prozessor.
Hinzu kommt noch, dass sich die unterschiedlichen CPU-Gemeinden auch an "ihren" Standard gewöhnt haben und sich die anderen Compilerhersteller danach richten.
Das erst was ich bei einem Compiler mache, ist ein Blick in das Kapitel "Compiler-Specific"
Da ist aber ein Problem der Arduino-Entwickler.Zitat:
Zitat von HaWe
Die müssten beim Aufruf des Compilers nur den passenden Toggle setzen.
Nun bekommst du aber Probleme, wenn du Sourcode direkt aus dem ARM-Pool übernimmst :-(
Du hast dich bisher nur noch nicht mit portierbarem Code beschäftigt.Zitat:
Zitat von HaWe
Sorry, dass ich nicht an signed/unsigned gedacht habe, aber dieses Problem hatte ich seit über 20 Jahren nicht mehr, wieso habe ich dir auch geschrieben.
Liegt vermutlich daran, dass ich seit je her immer mit unterschiedlichen CPUs/Mikrocontrollern zu tun hatte.
Ich habe sehr viel portablen Code geschrieben, hauptsächlich Übertragungsprotokolle. Da ist das Hauptproblem die Endian-Geschichte. Aber man kann die Umsetzung in C so schreiben, dass es portabel ist int in char zu verwandeln, allerdings darf man keine Union verwenden.
MfG Peter(TOO)
entschuldige bitte, ich mache doch niemanden einen Vorwurf daraus, dass er an diesen blödsinniges signed/unsigned char-Mist nicht gedacht hat!
Im Gegenteil!
Ich finde es nur absolut ärgerlich, dass innerhalb ein und derselben IDE ohne jeden Hinweis der Compiler aus negativen plötzlich positive Zahlen macht, nur weil man als Hobby-Programmierer ein anderes Board im Dropdown-Menü auswählt!!
so - zurück zum Code...
wer jetzt mal ein bisschen Schach spielen (testen) möchte auf einen Due mit wirklich akzeptabler Spielstärke bei erträglicher Denkzeit mit bis zu 400000 durchgerechneten Zügen für max 80000 Knoten (willkürlich) und bis zu 8 Halbzügen Denktiefe, etwas "grafisch" aufgepimpt, hier ist der Code:
erstaunlich schlau, die Chess Engine von Muller! :cool:Code:/***************************************************************************/
/* micro-Max, */
/* A chess program smaller than 2KB (of non-blank source), by H.G. Muller */
/***************************************************************************/
/* version 4.8.n Sketch (1953 characters) features: */
/* - recursive negamax search */
/* - all-capture MVV/LVA quiescence search */
/* - (internal) iterative deepening */
/* - best-move-first 'sorting' */
/* - a hash table storing score and best move */
/* - futility pruning */
/* - king safety through magnetic, frozen king in middle-game */
/* - R=2 null-move pruning */
/* - keep hash and repetition-draw detection */
/* - better defense against passers through gradual promotion */
/* - extend check evasions in inner nodes */
/* - reduction of all non-Pawn, non-capture moves except hash move (LMR) */
/* - full FIDE rules (expt under-promotion) and move-legality checking */
#define K(A,B) *(int*)(T+A+(B&8)+S*(B&7))
#define HTsize (1<<12) // wegen RAM, für PC: (1<<24)
struct HTab {
int K,
V;
int X,
Y,
D;
} HTarray[HTsize]; /* hash table, HTsize entries*/
#define MAXNODES 80000 // wegen Zugdauer; für PC: x10 = 800000 = 8e5
int K,
Q,
R,
J,
Z;
int32_t N,
I=80000; /* I=80000: "infinity score" */ ;
int
M=136, /* M=0x88 board system */
S=128, /* dummy square 0x80, highest valid square =127 */
turn=16; // 16=Weiss, 8=Schwarz; turn^=24 wechselt hin unnd her
signed char L,
pval[]={0,2,2,7,-1,8,12,23}, /* relative piece values */
vector[]={-16,-15,-17,0,1,16,0,1,16,15,17,0,14,18,31,33,0, /* step-vector lists */
7,-1,11,6,8,3,6}, /* 1st dir. in vector[] per piece*/
bsetup[]={6,3,5,7,4,5,3,6}, /* initial piece setup */
board[129], /* board: half of 16x8+dummy*/
T[1035]; /* hash translation table */
signed char psymbol[]= ".?+nkbrq?*?NKBRQ";
int mfrom, mto; // current ply from - to
int EPSQ, // e.p. square
RemP; // remove piece
/* recursive minimax search, turn=moving side, n=depth*/
int Minimax(int32_t q, int32_t l, int32_t score, int EPC, int prev, int32_t hashkey)
/* (q,l)=window, score, EnPass_sqr.*/
/* prev=prev.dest; J,Z=hashkeys; return score*/
{
int j,
r,
m,
v,
d,
h,
i,
F,
G,
V,
P,
f=J,
g=Z,
C,
s;
signed char t,
p,
upiece,
x,
y,
X,
Y,
H,
B;
struct HTab *a = HTarray + (J + turn * EPC & HTsize-1); /* lookup pos. in hash table*/
char sbuf[50];
q--; /* adj. window: delay bonus */
turn^=24; /* change sides */
d=a->D;
m=a->V;
X=a->X;
Y=a->Y; /* resume at stored depth */
if(a->K-Z|prev| /* miss: other pos. or empty*/
!(m<=q | X&8&&m>=l | X&S)) /* or window incompatible */
{ d=Y=0; } /* start iter. from scratch */
X&=~M; /* start at best-move hint */
while( d++ < hashkey || d<3 /* iterative deepening loop */
|| prev&K == I
&& ( N<60000 & d<98 /* root: deepen upto time */
|| (K=X, L=Y&~M, d=3)
)
) /* time's up: go do best */
{
x=B=X; /* start scan at prev. best */
h=Y&S; /* request try noncastl. 1st*/
P=d<3 ? I : Minimax(-l,1-l,-score,S,0,d-3); /* Search null move */
m = (-P<l | R>35) ? ( d>2 ? -I : score ) : -P; /* Prune or stand-pat */
N++; /* node count (for timing) */
do
{
upiece=board[x]; /* scan board looking for */
if(upiece & turn) /* own piece (inefficient!)*/
{
r = p = upiece&7; /* p = piece type (set r>0) */
j = vector[p+16]; /* first step vector f.piece*/
while(r = p>2 & r<0 ? -r : -vector[++j] ) /* loop over directions vector[] */
{
labelA: /* resume normal after best */
y=x; /* (x,y)=move */
F=G=S; /* (F,G)=castl.R */
do
{ /* y traverses ray, or: */
H=y=h?Y^h:y+r; /* sneak in prev. best move */
if(y&M)break; /* board edge hit */
m= EPC-S&board[EPC]&&y-EPC<2&EPC-y<2?I:m; /* bad castling */
if(p<3&y==EPC)H^=16; /* shift capt.sqr. H if e.p.*/
t=board[H];
if(t&turn|p<3&!(y-x&7)-!t)break; /* capt. own, bad pawn mode */
i=37*pval[t&7]+(t&192); /* value of capt. piece t */
m=i<0?I:m; /* K capture */
if(m>=l&d>1) goto labelC; /* abort on fail high */
v=d-1?score:i-p; /* MVV/LVA scoring */
if(d-!t>1) /* remaining depth */
{
v=p<6?board[x+8]-board[y+8]:0; /* center positional pts. */
board[G]=board[H]=board[x]=0;board[y]=upiece|32; /* do move, set non-virgin */
if(!(G&M))board[F]=turn+6,v+=50; /* castling: put R & score */
v-=p-4|R>29?0:20; /* penalize mid-game K move */
if(p<3) /* pawns: */
{
v-=9*((x-2&M||board[x-2]-upiece)+ /* structure, undefended */
(x+2&M||board[x+2]-upiece)-1 /* squares plus bias */
+(board[x^16]==turn+36)) /* kling to non-virgin King */
-(R>>2); /* end-game Pawn-push bonus */
V=y+r+1&S?647-p:2*(upiece&y+16&32); /* promotion or 6/7th bonus */
board[y]+=V;
i+=V; /* change piece, add score */
}
v+= score+i;
V=m>q ? m : q; /* new eval and alpha */
J+=K(y+0,board[y])-K(x+0,upiece)-K(H+0,t);
Z+=K(y+8,board[y])-K(x+8,upiece)-K(H+8,t)+G -S; /* update hash key */
C=d-1-(d>5&p>2&!t&!h);
C=R>29|d<3|P-I?C:d; /* extend 1 ply if in check */
do {
s=C>2|v>V?-Minimax(-l,-V,-v, /* recursive eval. of reply */
F,0,C):v; /* or fail low if futile */
} while( s>q & ++C<d );
v=s;
if(prev&&K-I&&v+I&&x==K&y==L) /* move pending & in root: */
{
Q=-score-i; EPSQ=F; /* exit if legal & found */
a->D=99;a->V=0; /* lock game in hash as draw*/
R+=i>>7;
return l; /* captured non-P material */
}
J=f;
Z=g; /* restore hash key */
board[G]=turn+6;
board[F]=board[y]=0;
board[x]=upiece;
board[H]=t; /* undo move,G can be dummy */
}
if(v>m) /* new best, update max,best*/
{
m=v,X=x,Y=y|S&F; /* mark double move with S */
}
if(h)
{
h=0;
goto labelA; /* redo after doing old best*/
}
if (
x+r-y|upiece&32| /* not 1st step,moved before*/
p>2 & (
p-4|j-7|| /* no P & no lateral K move,*/
board[G=x+3^r>>1&7]-turn-6 /* no virgin R in corner G, */
|| board[G^1] | board[G^2] ) /* no 2 empty sq. next to R */
)
{
t+=p<5;
} /* fake capt. for nonsliding*/
else F=y; /* enable e.p. */
} while(!t); /* if not capt. continue ray*/
}
} // (upiece & turn)
} while((x=x+9&~M)-B); /* next sqr. of board, wrap */
labelC:
if (m>I-M|m<M-I) d=98; /* mate holds to any depth */
m= m+I|P==I ? m : 0; /* best loses K: (stale)mate*/
if(a->D<99) { /* protect game history */
a->K=Z;
a->V=m;
a->D=d; /* always store in hash tab */
a->X=X|8*(m>q)|S*(m<l);
a->Y=Y; /* move, type (bound/exact),*/
}
/* uncomment for Kibitz */
//if(prev) sprintf(sbuf, "%2d ply, %9d searched, score=%6d by %c%c%c%c\n",
// d-1, N-S, m, 'a'+(X&7),'8'-(X>>4),'a'+(Y&7),'8'-(Y>>4&7));
if(prev && X!=Y) {
sprintf(sbuf, "\n%2d ply, searched: %9d ", d-1, N-S );
Serial.print(sbuf);
}
else
if( ((N-S)%10000)<1) Serial.print(".");
} // while (iterative deepening loop)
turn^=24; /* change sides back */
mfrom=K; mto=L;
return m+= m<score; /* delayed-loss bonus */
}
void chess()
{
int32_t score, i;
int16_t oldto, oldEPSQ;
char sbuf[50], sbuf2[50];
char cstring[20];
signed char oboard[129], spiece;
K=8;
while(K--)
{
board[K]=(board[K+112]=bsetup[K]+8)+8;
board[K+16]=18;
board[K+96]=9; /* initial board setup*/
L=8;
while(L--)board[16*L+K+8]=(K-4)*(K-4)+(L-3.5)*(L-3.5); /* center-pts table */
} /*(in unused half board[])*/
N=1035;
while(N-->M)T[N]=rand()>>9;
/* play loop */
while(1)
{
N=-1;
Serial.print("\n");
sprintf(sbuf," A B C D E F G H \n --------------- \n"); Serial.print(sbuf);
while(++N<121) { /* print board */
if(N&8 && (N+7!=0) ) {sprintf(sbuf,"%3d \n", 1+((120-N)>>4)); Serial.print(sbuf); N+=7; }
else {
if(N%8==0) {sprintf(sbuf, "%3d ", 1+((120-N)>>4)); Serial.print(sbuf); }
sprintf(sbuf," %c", psymbol[board[N]&15]); Serial.print(sbuf);
}
}
sprintf(sbuf," --------------- \n A B C D E F G H "); Serial.print(sbuf);
if(turn==16) sprintf(sbuf,"\n> WHITE: "); else sprintf(sbuf,"\n> BLACK: ");
Serial.print(sbuf);
i = 0;
strcpy(cstring,"");
do {
while (Serial.available()==0);
cstring[i] = Serial.read();
if(cstring[i]==13) {
cstring[i]=0;
break;
}
else i++;
} while(i < 10);
K=I;
if(cstring[0]!=0) { /* parse entered move */
K= cstring[0]-16*cstring[1]+799;
L= cstring[2]-16*cstring[3]+799;
}
/*
Serial.print("\n DEBUG cstring : "); Serial.print(cstring);
sprintf(sbuf,"\n DEBUG K: %d \n DEBUG L: %d \n", K, L);
Serial.print(sbuf);
*/
memcpy(oboard, board, sizeof(board));
oldto=mto;
oldEPSQ=EPSQ;
score=Minimax(-I, I, Q, EPSQ, 1, 3); /* think or check & do*/
if(score!=15) {
RemP=S;
if(oboard[mto]) RemP=mto;
if(mto==oldEPSQ) RemP=oldto;
spiece=psymbol[board[mto]&15];
if(spiece=='*' || spiece=='+') spiece=' ';
sprintf(sbuf,"\n\nmoved: >> %c %c%c", spiece,'a'+(mfrom&7),'8'-(mfrom>>4) );
if(oboard[mto]) strcat(sbuf," X ");
else strcat(sbuf,"-");
sprintf(sbuf2,"%c%c ", 'a'+(mto&7),'8'-(mto>>4&7));
strcat(sbuf, sbuf2);
Serial.print(sbuf);
sprintf(sbuf, " \nDEBUG: %d to %d \n", mfrom, mto);
Serial.print(sbuf);
sprintf(sbuf," EPsq: %c%c (%3d)\n",
'a'+(EPSQ&7), '8'-(EPSQ>>4&7), EPSQ); Serial.print(sbuf);
sprintf(sbuf," RemP: %c%c (%3d)\n\n",
'a'+(RemP&7), '8'-(RemP>>4&7), RemP); Serial.print(sbuf);
}
else printf("\n\nILLEGAL!\n");
}
}
void setup() {
Serial.begin(9600);
}
void loop() {
chess();
while(1);
}
nun kann mein Schachroboter https://www.youtube.com/watch?v=Cv-yzuebC7E schon fast mit Turnierspielstärke antreten... :)
Wo war denn nun das wirkliche Problem. Ob eine "kleine" Zahl nun als signed oder unsigned char gespeichert wird, ist doch wohl egal. Aber bei welcher Operation läuft das Programm denn falsch? Und sollte man das Programm dann nicht da anpassen, damit es einfach mit chars läuft.
MfG Klebwax
das Programm verlangt überwiegend "signed char", weil meist auch negative Werte vorkommen können (-128...+127),
das ist aber auch die Standardeinstellung für char auf AVR und für Windows-PC bzw. Konsole, und daher lief es dort auch problemlos von Anfang an.
Der Fehler war, dass Sketch für den Due "char" aber mit "unsigned char" (== "byte") übersetzt hat, daher bekamen negative Zahlen dann plötzlich positive Werte zugewiesen. Die Zahl "-1" wurde daher z.B. als "255" gelesen.
Daher musste man bei den chars aus dem Ursprungsprogramm überall "signed" davorschreiben.
Man darf es allerdings nicht dort davorschreiben, wo anschließend eine Typen-Konversion zu int oder long stattfindet, denn da steigt dann der Sketch-Compiler wieder aus.
Übrigens: wenn man per Serial Buchstaben-Zeichen ausgibt, kann es mit unsigned char (== "byte") ebenfalls Probleme geben (da wird dann der ASCII-Code des Buchstabens geschrieben, nicht der Buchstabe selber). Das habe ich aber schon sehr früh festgestellt, daher habe ich immer erst sprintf() benutzt bevor ich dann Serial aufgerufen habe. In diesen Fällen musste man jetzt kein "signed" mehr davorschreiben.