Hat jemand diesen Code heruntergeladen?

[C. H. (hedie)]

Hallo zusammen

Ich habe dieses Video gefunden:
https://www.youtube.com/watch?v=wyuJ-dqS2to

Gerne hätte ich den Code dazu.
Leider funktioniert der Link dazu nicht mehr.


Eventuell hat ja jemand von euch den Code?

[Abble Bie (Gast)]

Ich habe den Code nicht heruntergeladen, aber hast du schonmal den 
Ersteller des Viedoes angeschrieben?

[C. H. (hedie)]

Abble Bie schrieb:
> Ich habe den Code nicht heruntergeladen, aber hast du schonmal den
> Ersteller des Viedoes angeschrieben?

Nein bisher noch nicht.
Meistens ist das Forum schneller :)

[Max D. (max_d)]

Stichwort: Multitasking

[C. H. (hedie)]

Max D. schrieb:
> Stichwort: Multitasking

Ja, ich hab inzwischen auch beim Autor des Videos angefragt...
Mein Bauchgefühl sagt mir jedoch, dass von dort keine Antwort kommen 
wird...

[Abble Bie (Gast)]

Dann schreib's halt noch in die Kommentare...

[eProfi (Gast)]

Auf archive.org findet man nichts!

Hast Du folgendes schon probiert?
https://www.youtube.com/user/DrunyaHimself    hat offensichtlich 
ebenfalls probiert, den Code zum laufen zu bringen.

http://www.serveurperso.com/?page=contact  --->
admin at serveurperso.com
Er hat vor ein paar Tagen noch etwas auf seinen temp-Ordner hochgeladen.

[Jojo S. (Gast)]

das kommt mir bekannt vor, gibt es auch als Demo für das LPC4088 Board 
von EA und läuft mit der mbed Umgebung:
http://developer.mbed.org/users/embeddedartists/code/app_lcdboard_demo_sphere/
http://developer.mbed.org/users/embeddedartists/notebook/lpc4088-quickstart-board---projects/

[Frank G. (frank_g53)]

Vielleicht hilft dir das weiter:
https://www.ghielectronics.com/community/forum/topic?id=11791

[C. H. (hedie)]

Genial!!! Vielen Dank!

Denkt ihr dass das ein STM32F1 mit 72MHz auch schaffen kann?

[Jojo S. (Gast)]

sicher wird der das schaffen, frage ist nur wie schnell das läuft... Der 
LPC17/4088 hat einen LCD Controller und dadurch ist die Grafik sehr fix, 
zeichnen geht direkt durch Schreiben in den Bildschirmspeicher.

[C. H. (hedie)]

Ich habe den Code kurz überflogen...
Wenn ich diesen richtig interpretiere, dann geschieht wohl das Befüllen 
des Buffers hier:

void SphereDemo::draw(int16_t xyz[3][N], uint8_t rgb[3][N]) {
// static uint16_t oldProjX[N] = {0};
// static uint16_t oldProjY[N] = {0};
// static uint8_t oldDotSize[N] = {0};
 uint16_t i;
 uint16_t projX;
 uint16_t projY;
 uint16_t projZ;
 uint16_t dotSize;
 static uint8_t cnt=0;
 
  if (cnt == 0)
  {
    cnt = 1;
    pFrmBuf = pFrmBuf1;
  }
  else if (cnt == 1)
  {
    cnt = 2;
    pFrmBuf = pFrmBuf2;
  }
  else
  {
    cnt = 0;
    pFrmBuf = pFrmBuf3;
  }
  
  graphics.setFrameBuffer(pFrmBuf);
 
  memset((void*)(pFrmBuf), 0x00, windowX * windowY * 2);
 
 for(i = 0; i < N; i++) {
  projZ   = SCALE - (xyz[2][i] + SCALE) / 4; //4;
  projX   = windowX / 2 + (xyz[0][i] * projZ / SCALE) / 40; //EA 25;
  projY   = windowY / 2 + (xyz[1][i] * projZ / SCALE) / 40; //EA 25;
  dotSize = 3 - (xyz[2][i] + SCALE) * 2 / SCALE;
//EA  put_circle(oldProjX[i], oldProjY[i], 0, dotSize, 1);
 
  if((projX > dotSize) &&
     (projY > dotSize) &&
     (projX < (windowX - dotSize)) &&
     (projY < (windowY - dotSize))) {
 
// HIER wird m.M.n der Buffer befüllt mit der Funktion circle----->>>>>>
   graphics.put_circle(projX, projY, (rgb[0][i] << REDSHIFT) + (rgb[1][i] << GREENSHIFT) + (rgb[2][i] << BLUESHIFT), dotSize, 1);
 
//   oldProjX[i] = projX;
//   oldProjY[i] = projY;
//   oldDotSize[i] = dotSize;
  }
 }
}

Seht ihr dies auch so?

Wenn ich das richtig gesehen habe, gibt es 3 DisplayBuffer.
Es wird nach und nach einer befüllt und beim nächsten Durchlauf wieder 
als haupt DisplayBuffer gesetzt.

Da ich nicht genügend Speicher für solche spielereien habe, müsste ich 
ja lediglich die

graphics.put_circle(...)

 durch eine ebengleiche von mir ersetzen.

Meine Funktion schreibt halt dann direkt aufs Display.
Dies wird wohl sehr sehr träge sein, aber für den Anfang genügts.

Dannach kann dann mit optimierungen gespielt werden :)



Die Hauptroutine sieht so aus:

    
    loops = 2*820;
  for(int32_t n=0;n<loops;n++) {
 
   matrix(xyz, rgb);
 
   rotate(xyz, rgb, angleX, angleY, angleZ);
 
   draw(xyz, rgb);

  //----> Dieser Teil entfällt dann bei mir, da ich ja keinen LCD Controller im STM habe... 

  //update framebuffer
  lcdBoard.setFrameBuffer((uint32_t)this->pFrmBuf);
....
}

[Jojo S. (Gast)]

ja, müsste so gehen. Allerdings werden in der Funktion matrix() noch 
zwei große Arrays mit den Kreispositionen und Farben vorberechnet. Das 
kostet bei N=1024 6k+3k RAM.

[C. H. (hedie)]

Jojo S. schrieb:
> Das
> kostet bei N=1024 6k+3k RAM.

Meinst du damit 1024 x 6k+3k oder einfach 6k+3k = 9k gesamt?

Mein verwendeter STM (STM32F105RBT6) hat 64k RAM... Sollte also reichen 
:)

[C. H. (hedie)]

Leider krieg ich nach dem portieren ein:

  region ram  overflowed with stack

Hat jemand eine schnelle Lösung parat?

[Jojo S. (Gast)]

die Array Argumente stören vielleicht:
void SphereDemo::matrix(int16_t xyz[3][N], uint8_t rgb[3][N]) {
Ich weiss nicht ob das in C++ anders ist als in C (byRef als Default?) 
oder eine Compilereinstellung, aber wenn hier wirklich die grossen 
Arrays über den Stack sollen kann es natürlich knallen. Eine Übergabe 
per Zeiger auf Element 0.0 sollte reichen.

[C. H. (hedie)]

Jojo S. schrieb:
> die Array Argumente stören vielleicht:
> void SphereDemo::matrix(int16_t xyz[3][N], uint8_t rgb[3][N]) {
> Ich weiss nicht ob das in C++ anders ist als in C (byRef als Default?)
> oder eine Compilereinstellung, aber wenn hier wirklich die grossen
> Arrays über den Stack sollen kann es natürlich knallen. Eine Übergabe
> per Zeiger auf Element 0.0 sollte reichen.

Danke! Das wird es wohl gewesen sein...
Werde ich noch Anpassen und nochmals testen...

Habe inzwischen den bestehenden Code (mit seinen Unschönheiten wie jene 
oben) portiert.

Das Ergebnis siehts du hier:

https://www.youtube.com/watch?v=nfX0YvVSM7w

[C. H. (hedie)]

Jojo S. schrieb:
> Eine Übergabe
> per Zeiger auf Element 0.0 sollte reichen.

Wie würdest du das dann umschreiben?

So?

void matrix(int16_t *xyz[][], uint8_t *rgb[][])

Und dann so aufrufen:

matrix(&xyz[0][0], &rgb[0][0]);

[Jojo S. (Gast)]

so ganz sieht dein Video ja nicht wie das Original aus, wird da zu oft 
gelöscht zwischen den Zeichenbefehlen?
Mit den Pointern war so wie ich meinte. Ich habe aber nochmal gesucht 
und eigentlich sollte in C die Array Übergabe auch automatisch in Zeiger 
umgewandelt werden. Ich habe das Projekt in mbed und LPCXpresso 
kompiliert, beide ohne Fehler (in der C++ Version). Die BSS Größe ist 
1876 Byte, da sind also die 9k nicht drin.

ok, Nachtrag:
.bss ist nicht das Stack Segment sondern die Null-Initialisierten 
Variablen. Also waren die statischen Arrays in Summe zu groß, hatte nix 
mit dem Stack zu tun.
Wenn dein Controller genug RAM hat sind die Linker Einstellungen/Linker 
Script eventuell falsch.

noch ein Nachtrag:
ich verwirre mich gerade glaube ich selber. Du hattest ja ein 'region 
ram overflowed with stack'. Ich habe versucht das nachzubauen, bekomme 
aber ein '.bss' will not fit in region', also doch etwas anderes 
(testarray als statische Variable zu groß).
Daher ist das große Array als Argument immer noch ein Rätsel, das 
schluckt mein gcc auch in C Quellen.

[C. H. (hedie)]

Jojo S. schrieb:
> so ganz sieht dein Video ja nicht wie das Original aus, wird da zu oft
> gelöscht zwischen den Zeichenbefehlen?

Ja dass ist richtig, ich lösche nach jedem zeichnen bzw. vor jedem 
zeichnen der Punkte den Bereich, bzw überschreibe diesen mit schwarz.

Dies deshalb, da ich ja nicht wie jener Controller im Beispiel mehrere 
Buffer habe sondern nur den Speicher des Displayscontrollers im TFT 
selbst nutzen kann. Somit muss ich zuerst die alten Punkte löschen.

Jojo S. schrieb:
> Ich habe versucht das nachzubauen, bekomme
> aber ein '.bss' will not fit in region',

Den hatte ich zusätzlich auch noch!

Jojo S. schrieb:
> Daher ist das große Array als Argument immer noch ein Rätsel, das
> schluckt mein gcc auch in C Quellen.

Das ist es wirklich.

Bei mir gibts noch das Problem, dass wenn ich "N" also die Anzahl Punkte 
zu gross wähle, dann geht mir der Controller in den DefaultFaultHandler 
(oder so ähnlich)

Vermutlich gibt es dann zur Laufzeit irgend einen overflow...

[gustav (Gast)]

Claudio H. schrieb:

>
> Habe inzwischen den bestehenden Code (mit seinen Unschönheiten wie jene
> oben) portiert.
>
> Das Ergebnis siehts du hier:
>
> Youtube-Video "Sphere STM32"

Könntest du deinen Code mal posten
bitte

[C.h. (Gast)]

Ist bereits

Beitrag "CPP Code nach C portieren. endet in Stackoverflow."