Problem bei Funktionsaufruf und unsigned long Übergabeparameter (SiLabs F500)

Mr Bean schrieb:

> wollte ich den Aufruf der Funktion einfach in:
>

1

> int8_t num2string(unsigned long num, int size, char *retbuffer){

2

>

> ändern.

Und alles erneut durchcompilieren.

> Dann läuft mein Controller aber nichteinmal mehr los.

Dann musst du rauskriegen woran das liegt.
Speicher voll?
An der Funktion selbst liegt es erst mal nicht.

> Alle angeschlossenen LED`s sowie jedliche Kommunikation
> bleiben/bleibt aus.

Das ist zwar ein eindeutiges Symptom, allerdings zur Fehlerdiagnose 
nicht ausreichend. Da musst du schon ein wenig mehr Aufwand reinstecken, 
bis aus dieser Symptombeschreibung die Diagnose 'Controller läuft nicht 
mehr los' abgeleitet werden kann. Was passiert denn am Anfan des 
Programms? Lass doch mal am Anfang des Programms eine LED aufleuchten, 
gleich als allererstes, noch ehe irgendwas anderes passiert. Wenn die 
auch nicht mehr kommt, dann kann man darüber nachdenken warum dein 
'Controller nicht mehr losläuft'.


PS:
Den Teil hier

1

  for ( i = 0; i < strlends(retbuffer); i++)

2

  {

3

    if (retbuffer[i] == ' ')

4

    {

5

      retbuffer[i] = '0';

6

    }

7

  }

kannst du dir sparen.
1) ist der strlends in der Abbruchbedingung nicht so glücklich, denn
   strlends wird dadurch bei jedem Schleifendurchlauf erneut
   aufgerufen. Die Länge des Strings ändert sich aber in der
   Schleife gar nicht.

2) kann die beabsichtigte Funktionalität (führende 0-en) auch das
   jeweilige sprintf übernehmen. Man muss es ihm im Formatstring nur
   sagen, dass es das tun soll:

1

      sprintf(retbuffer, "%02x",(unsigned int) (num & 0xff) );

   und schon macht sprintf anstelle der Leerzeichen da führende 0-en
   rein

Mr Bean schrieb:

> Allerdings hab ich das Problem mit dem nicht loslaufenden Code
> immernoch. Ich habe schon eine LED die zu allererst gesetzt wird (noch
> vor meiner whileschleife und den Initialisierungen). Auch diese LED
> macht keine Muckser.
> Werde jetzt mal das mit dem void* probieren.

Das wird nichts bringen.

Schau dir den Erstellprozess des Programms an.
Achte aucf Kennwerte wie Speicherauslastung. Alles was sich bedenklich 
den 90% nähert, sollte näher untersucht werden (Über 100% ist sowieso 
klar)

Mr Bean schrieb:
> Hallo Wo kann ich sowas sehen?
> In der *.l51 Datei!?
> Oder gibt es irgendwelche anderen Möglichkeiten die
> Codegröße/Speicherauslastung zu untersuchen? Arbeite mit dem Tasking
> Compiler und der Tasking EDE.

Gibts da keine Statistik am Ende des Vorgangs?
Normalerweise wird während des Buildens auch ein 'Map-File' erzeugt, in 
dem die interne Struktur des Programms genauer aufgeschlüsselt ist.

Da musst du jetzt suchen gehen.