Dank der Hilfe vor einiger Zeit hier im Forum hab ich es geschafft einen
Cortex M3 von ST zum laufen zu bekommen (STF32F103)
Ich kann bisher IO-Pins toggeln und auch die Unterhaltung über RS232
geht super.
Software ist Sourcery G++ Lite for ARM EABI von CodeSourcery, sowie PN.
Das Problem das ich hab ist, dass ich wenn ich wie in der Anleitung von
Sourcery... die stdlib.h include um die Funktion rand(); zu benutzen
kann dann bleibt der Code hängen. Eigendlich wollte ich kein Roulet mit
nichts geht mehr damit erzeugen ^^
Im Anhang ist erstmal der Code der geht. (Nicht wundern der ist etwas
komisch, da er nur zum durchtesten der versch. Hardware und so ist und
noch keinen Sinn erfüllt)
Wenn ich den Code dann um #include <stdlib.h> erweitere dann geht der
Code immernoch. (hab ich getestet, kann aber sein, dass der Code einfach
wegen fehlender Aufrufe nicht rein kommt)
Sobald ich aber srand(35); noch einfüge geht der Code schon nicht mehr.
Auch nur rand(); geht nicht. - Das merkwürdige daran ist, dass der
Compiler keinerlei Fehler ausspuckt. Ich versteh beim besten willen
nicht was der mit der Funktion hat.
Sry für den Langen Text jetzt: (Auszug über rand() aus dem Sourcery
Manual)
Synopsis
1
#include<stdlib.h>
2
intrand(void);
3
voidsrand(unsignedintseed);
4
intrand_r(unsignedint*seed);
Description
rand returns a different integer each time it is called; each integer is
chosen by an algorithm designed to be unpredictable, so that you can use
rand when you require a random number. The algorithm depends on a static
variable called the “random seed”; starting with a given value of the
random seed always produces the same sequence of numbers in successive
calls to rand.
You can set the random seed using srand; it does nothing beyond storing
its argument in the static variable used by rand. You can exploit this
to make the pseudo-random sequence less predictable, if you wish, by
using some other unpredictable value (often the least significant parts
of a time-varying value) as the random seed before beginning a sequence
of calls to rand; or, if you wish to ensure (for example, while
debugging) that successive runs of your program use the same “random”
numbers, you can use srand to set the same random seed at the outset.
Returns
rand returns the next pseudo-random integer in sequence; it is a number
between 0 and RAND_MAX (inclusive).
srand does not return a result.
Portability
rand is required by ANSI, but the algorithm for pseudo-random number
generation is not specified; therefore, even if you use the same random
seed, you cannot expect the same sequence of results on two different
systems.
rand requires no supporting OS subroutines.
Ich frag mich natürlich jetzt woran kann es liegen und so langsam hab
ich alles durch was mir eingefallen ist. (Ich habe auch einmal den
direkten Dateipfad angegeben { #include "c:\...\stdlib.h" } , da ich
auch WinArm, sowie WinAVR drauf hab und sicher gehen wollte das es der
richtige Pfad ist hat aber auch nichts gebracht.)
Bin für Hinweise Dankbar ^^ ich schätze es ist irgend ein total dummer
Fehler bzw ich hoffe es, dass es an meiner Blödheit liegt.
Gruß ErgoProxy
Schade ^^ scheint keiner eine "schnelle" Antwort drauf zu haben.
Einerseits ist das gut fürs Ego XD (ich bin wohl nicht der Einzige, der
es nicht weiß =) andererseits würd ich doch gerne wissen wo der verd....
Fehler liegt. Naja mach ich erstmal was anderes. Hat irgendwer eine
grobe ide woran es liegen könnte? Notfalls probier ich das halt durch
falls einer wissen will ob das in einer anderen
Schreibweise/Sonnstirgendwas geht. Nur mir gehen die Ideen aus wie ich
es probieren könnte.
Besonders seltsam ist auch das die #include <stdint.h> gehen. Ohne die
Datei würde das uint8_t ja nicht gehen. Die Datei liegt nur im selben
Pfad wie die andere. Deshalb schließ ich eigendlich auch einen
Pfad-Fehler aus.
Wenn noch irgendwas an Infos fehlt bitte sagen.
Gruß ErgoProxy
Wieviel Bit hat int auf dem Zielsystem und und wie groß wurde RAND_MAX
gewählt? Bei mismatch hätte der compiler aber auch meckern sollen.
Wie rufst Du die Funktion auf?
Andreas K. wrote:
> Einerseits ist das gut fürs Ego XD (ich bin wohl nicht der Einzige, der> es nicht weiß =)
Nö, es ist völlig normal, daß in einem überwiegend 8Bit-Forum
32Bit-Fragen wesentlich geringere Antwortchancen haben.
Die Notwendigkeit, immer gleich mit 32Bit-Boliden auf Steuerungsaufgaben
schießen zu müssen, wird kaum gesehen (zu recht).
> andererseits würd ich doch gerne wissen wo der verd....> Fehler liegt.
Such den Fehler doch einfach selber.
Stelle fest, ob die rand-Funktion überhaupt ausgeführt wird (vorher LED
ein, dahinter LED aus) oder ob nur der Rückgabewert für Dich unerwartet
ist und deshalb dahinter liegende Programme gegen die Wand laufen.
Es gibt bestimmt auch eine Doku zu der rand-Funktion, lies sie.
> Besonders seltsam ist auch das die #include <stdint.h> gehen.
Includes enthalten keinen Code, sondern erst die dazu gehörende Library.
Solange Du keine in den Includes bekannt gemachten Funktionen benutzt,
darf ein Include keinen Unterschied machen.
Peter
Also, ich habe das mal kurz bei mir ausprobiert.
Ich benutze Sourcery G++ Lite 2008q3-66 mit Luminary Controllern, in
diesem Fall ein 1968 mit Ausgabe über ein OLED, also nicht über RS232.
Funktioniert wunderbar und zeigt Zufallszahlen an.
Das Problem bei Dir muss also woanders liegen.
Danke erstmal für die vielen Antworten ^^
@Lutz - Eigendlich müsste int nach meiner schätzung bei 32Bit liegen ich
habs aber nicht getestet der µC hat allerdings 32Bit und da ist int
meißtens auch 32Bit. Werde mal gleich schauen. Noch eine Frage zu
RAND_MAX muss ich das irgendwo noch deffinieren? In der Doku der stdlib
stand dazu nix.
@Peter - Das mit dem Ego war ein Witz ;) natürlich dauert eine 32Bit
Frage hier wesentlich länger als eine nach nem Atmel AVR 8-Bit µC
besonders wenn das einer ist, der erst seit etwa nem Jahr wirklich
erhältlich ist ^^
Zur Notwendigkeit sei gesagt es gibt keine ^^ aber ich wollte doch auch
mal nen 32Bit µC verstehen und benutzen können. Außerdem finde ich die
72Mhz Takt und auch die 50Mhz-IO-Takt super und besonders die 20kb Ram
(naja 19,5kb nach Abzug des Bootloaders :)
Das mit den Includes stimmt ich muss mir mal ne andere Lib rauskramen
und schauen ob die Funktionen auch einen totalen Fehler verursachen. Zur
Doku nochmal: Ich hab mir die Doku angeschaut und du auch ^^ (Der
englische Text da oben ist alles was über die rand()-Funktion drinn
steht)
Leider kann ich nicht schauen was rand zurückliefert, da der Code
überhaupt nichts mehr macht nachdem es irgendwo drin steht. Leider finde
ich den Fehler nicht selbst sonnst würde ich das Forum auch ned bemühen.
Aber ich habe da geschlagene 4 Stunden dran gesessen.
Probiert hatte ich diese Konstrukte in der Main:
1.
1
srand(23);
2
intmeep=rand();
2.
1
srand(23);
2
uint8_tmeep=(rand()&0xFF);
3.
1
srand(23);
2
uint32_tmeep=rand();
4.
1
srand(23);
Nach allen Aufrufen wurde der dahinter liegende Code nicht mehr
ausgeführt.
Warum habe ich keine Ahnung.
Das include oben war entweder #include <stdlib.h> oder aber ich hab es
bei allen Versuchen nochmal durch den absoluten Pfad ersetzt. Wollte
auch nicht helfen.
@Spezialist - Jetzt bin ich erst recht ratlos ^^ Ohne den Aufruf von
srand(23); und/oder rand(); geht das Programm ja und schickt auch das
zur Schnittstelle was es soll ohne auch nur einen Fehler. Hast du das
RAND_MAX irgendwo deffiniert? Bzw wie benutzt du das rand und was genau
includest du? Vllt fehlt mir etwas.
P.s. Der Compiler hat bei mir nie auch nur irgendeinen Hinweis gebracht.
Ich benutze übrigends cs-make mit dem Parameter all.
Vielen Dank nochmal ich werde mir das gleich nochmal alles ansehn.
Gruß ErgoProxy
>@Lutz - Eigendlich müsste int nach meiner schätzung bei 32Bit liegen ich>habs aber nicht getestet der µC hat allerdings 32Bit und da ist int>meißtens auch 32Bit. Werde mal gleich schauen. Noch eine Frage zu>RAND_MAX muss ich das irgendwo noch deffinieren? In der Doku der stdlib>stand dazu nix.
int ist 32Bit:
1
define__INT_MAX__2147483647
Zu RAND_MAX:
1
#define RAND_MAX __RAND_MAX
2
3
#if __INT_MAX__ == 32767
4
#define __RAND_MAX 32767
5
#else
6
#define __RAND_MAX 0x7fffffff
7
#endif
Man muss das also nicht definieren.
Ich habe das bei mir einfach in einen simplen FreeRTOS Task geklatscht,
da ich den gerade zur Verfügung hatte. Ich habe das so wie Du gemacht,
damit das auch vergleichbar ist:
1
inttest;
2
charbuffer4[10];
3
test=rand();
4
itoa(test,buffer4,10);
5
RIT128x96x4StringDraw(buffer4,10,10,5);
Bei jedem Taskdurchlauf (1/s) kommt eine neue Zufallszahl.
Ich hab es eben grade nochmal ausprobiert:
Wenn ich eine LED anschalte bevor ich srand(25); aufrufe, dann geht
diese an. Nach srand wird sie wieder abgeschaltet. Sie leuchtet jedoch
dann dauerhaft.
Wenn ich die LED erst nach srand einschalte, dann leuchtet sie nie (das
ausschalten bleibt natürlich weg)
Also irgendwie ist bei mir da der Wurm drinn ich weiß nur nicht wo.
Integer kann ich normal benutzen und auch ausgeben. Ich hab z.B. grade
einem int eine Zahl zugewiesen und diesen dann über den Com-Port
ausgegeben. Es kommt auch genau die 32Bit Zahl wieder raus.
Gruß ErgoProxy
Ich bin jetzt noch mal alle Dateien usw durch gegangen und hab dann im
Makefile gesehn, dass da genaue Angaben zu den verwendeten Pfaden drinn
sind. Da er beim compilieren nie gemotzt hat hab ich eigendlich gedacht
da wäre alles in Ordnung. Es scheint aber so, dass er einfach die Pfade
nicht verwendet die nicht drinn stehen. Da ich bisher immer Pc und AVRs
ohne wirkliches Makefile erstellt hab hab ich das auch nicht gewusst.
Ich hab das Makefile mal im Anhang. Ich werde jetzt mal schauen wie man
einen weiteren Pfad dort einfügt. Oder falls mir das einer sagen könnte
ware auch super.
Gruß ErgoProxy
Hm ich glaub ich hab jetzt alles durch was mir dazu einfällt. Außer das
ich Alles nochmal deinstallieren könnte und danach nurnoch das von CS
wieder drauf.
Wollte das eigendlich vermeiden =/ aber da es wohl nix mit dem Kram hier
ist kann es nur etwas mit der Software sein. Oder hat jemand ne andere
Idee?
Gruß ErgoProxy
