[Dev] AlfaWise U20x-U30 : Marlin 2.x (firmware alternatif)

[Crzay]

il y a une heure, Hobi a dit :

LOL, Si tu parles du premier repo prive compile avec la lib STM 5.1.0, je l'ai aussi jete, mais il me semble que @CacaoTor ou @Crzay l'ont encore.... Je l'espere. En effet, dans celui la le DMA est present. Je crois meme que Cacaotor l'a envoye a clement directement. On croise le doigts. 

yes  j'ai encore laisse moi 5 min que je te l'upload

@Hobi @Epsylon3 j'ai  uploadé dans un dépot privé et vous ai invité

Modifié (le) Mai 5, 2019 par Crzay

[Epsylon3]

yep hmm, écran blanc mais ca compile... Marlin/src/HAL/HAL_STM32F1/u8g_com_stm32duino_fsmc.cpp

[wipeout85800]

@Epsylon3 m'étonnes pas aprés l'happy hour d'hier soir et la piste de dance .... tu dois voir trouble ....

[Epsylon3]

j'avoue lol, un peu mal au crane

[schragner.jgw@gmail.com]

Okay

[Epsylon3]

u8g_com_stm32duino_fsmc.cpp je remets le fichier unique ici a comparer...

[Hobi]

Je suis à nouveau connecte. Je regarde...

[Epsylon3]

le pire c'est qu'on a le code avec dma dans la calibration

il semble manquer ca deja

+  gpio_set_mode(GPIOD,  7, GPIO_AF_OUTPUT_PP);  // NE1
+  gpio_set_mode(GPIOD, 11, GPIO_AF_OUTPUT_PP);  // A16
 

hmm pt pas, semble etre remplacé par

  gpio_set_mode(PIN_MAP[cs].gpio_device, PIN_MAP[cs].gpio_bit, GPIO_AF_OUTPUT_PP);  //FSMC_CS_NEx
  gpio_set_mode(PIN_MAP[rs].gpio_device, PIN_MAP[rs].gpio_bit, GPIO_AF_OUTPUT_PP);  //FSMC_RS_Ax
 

Modifié (le) Mai 5, 2019 par Epsylon3

[Hobi]

@Epsylon3, oui, en effet. Ne pas toucher les lignes.

Le code DMA etait partout au debut! Et c'est dans la version finale, commitee dans Marlin 2.0.x bugfix, que pour des raisons de portabilite / compatibilite avec U8glib, que le code a ete modifie, et le DMA enleve. Ce qui m'a d'ailleurs gene pour remettre les fichus boutons du touch screen! 

Il y a pas mal de changements au niveau de Dogm dans U8g_dev_tft_320x240 aussi...! et c'est la qu'il y a le plus de choses a toucher. 

 

Edit : Le dernier code commite dans Marlin 2.0.X est donc buggé!

Modifié (le) Mai 5, 2019 par Hobi

[Hobi]

Remplacer en bas de la procedure : le trandfert DMA c'est : for (k = 0; k < 2; k++) lcd.writeSequence(buffer, 256);

case U8G_DEV_MSG_PAGE_NEXT:

OUT_WRITE(LA_TRIG,HIGH);

for (uint16_t y = 0; y < 8; y++) {

uint32_t k = 0;

for (i = 0; i < (uint32_t)pb->width; i++) {

const uint8_t b = *(((uint8_t *)pb->buf) + i);

const uint16_t c = TEST(b, y) ? TFT_MARLINUI_COLOR : TFT_MARLINBG_COLOR;

buffer[k++] = c; buffer[k++] = c;

}

for (k = 0; k < 2; k++) {

u8g_WriteSequence(u8g, dev, 128, (uint8_t*)buffer);

u8g_WriteSequence(u8g, dev, 128, (uint8_t*)&(buffer[64]));

u8g_WriteSequence(u8g, dev, 128, (uint8_t*)&(buffer[128]));

u8g_WriteSequence(u8g, dev, 128, (uint8_t*)&(buffer[192]));

}

}

OUT_WRITE(LA_TRIG,LOW);

break;

par : 

 

case U8G_DEV_MSG_PAGE_NEXT:

if (lcd.id == 0) break;

 

for (j = 0; j < 8; j++) {

k = 0;

for (i = 0; i < (uint32_t) pb->width; i++) {

byte = *(((uint8_t *)pb->buf) + i);

if (byte & (1 << j)) {

buffer[k++] = color;

buffer[k++] = color;

} else {

buffer[k++] = 0x0000;

buffer[k++] = 0x0000;

}

}

for (k = 0; k < 2; k++) lcd.writeSequence(buffer, 256);

}

break;

Modifié (le) Mai 5, 2019 par Hobi

[Hobi]

Bon, j'ai pas la board sous la main, je suis pas chez moi.... Pas avant demain soir... difficile de refaire le code, et je suis en famille. 

Une bonne nouvelle : Afin d’être sur de ne plus avoir de problèmes de buffer interne vide, et de mouvements saccadés, la condition de trigger sur l'analyseur logique est très simple :

Si (( Xclk + Yclk) = 0 pendant plus de 2ms ) > Trig. 

En effet, à partir du moment ou l'impression est en cours, la tete bouge en permanence. Sachant que la vitesse minimale correspond au jerk, sur une des deux directions, ne pas avoir de déplacement signifie pas de pulses pendant plus de 2ms. A priori, à partir du moment ou le buffer interne est vide, a chaque fois les trous ( absence de pulses)  duraient 16.2ms... 

Tous les autres defauts sont dus à la mécanique...  

Modifié (le) Mai 5, 2019 par Hobi

[Epsylon3]

ok, c'est pushé.. dma activé, il faudra que tu remesures tout ca demain...

[Hobi]

Youpiii merci! Bon ça explose pas? Je re mesure  demain deal! 

[Epsylon3]

Non par contre soucis de capteur de filament.... pendant l'impression... il faut que je débug...

Send: M119[...]Recv: Reporting endstop statusRecv: x_min: openRecv: y_min: openRecv: z_min: openRecv: filament: TRIGGERED

Tres bizarre... ce capteur lol va falloir mettre qq leds pour comprendre...

edit: ca semble un probleme mécanique... pt qu'il etait coincé...  à suivre

Modifié (le) Mai 5, 2019 par Epsylon3

[Oniric]

@Hobi @Epsylon3 la version est upload sur le git public pour test ou pas encore ?

ça sent bon en tout cas vos discussions meme si j'en comprend que 50% ...

[Hobi]

@Epsylon3 ca a l'air d'etre OK. 

Je pense que la procedure draw image pourrait beneficier du DMA pour les grosses icones, mais a priori cela ne sert qu'une fois au debut pour afficher les boutons...

Par contre, le clear screen, lui devrait aussi passer en DMA.. 

u8g_WriteEscSeqP(u8g, dev, clear_screen_sequence);

for (i = 0; i < 960; i++)

u8g_WriteSequence(u8g, dev, 160, (uint8_t *)buffer);

On a besoin de faire un clear screen sauf erreur de ma part a chaque changement de page, et la, ca peut fluidifier les choses. Si on change de page au cours d'un print, l'imprimante fait une pause actuellement, et une des causes doit etre encore une fois le CPU trop occupé à effacer l'ecran, sur toute la surface, 320x240, et ca prend encore plus de temps que le rafraichissement normal de 256x128... 

Et tu coup, a chaque changement de page, on est oblige de re afficher les boutons, ou pas? 

La machine devrait avoir un ecran, et etre moins capricieuse. Je passe tout ça a l'analyseur logique demain, et on verra bien si je vois des sauts ou pas. Manifestation du saut : le plateau bouge de maniere saccadée, et ca se sent tres bien à la main, en posant sa main sur le plateau ( si il n'est pas trop chaud!!!) . 

Si il reste des sauts, il faudra optimiser le code, et la plutot dans Dogm je pense. 

So far so good. Au moins on comprend un peu le problème maintenant. 

@3d.taze Vu que tu fais des jolis prints depuis le début, cette version doit maintenant marcher plutot très bien chez toi. J'espere que tu peux la compiler. 

@Oniric, tu peux compiler. Ca va pas te manger! 

Modifié (le) Mai 5, 2019 par Hobi

[CacaoTor]

Modération : Vu le travail que vous me donner, et les rappels effectués... Les doubles (triple et plus si affinité)-post sauf cas de force majeure et absolu (délais de 12h au moins ou information critique qui demande de la lisibilité), seront systématiquement supprimés et pourront conduire à une sanction  

[Hobi]

Ah, désolé, j'ai le post facile... pas la tete, Nooonnn.

Modifié (le) Mai 5, 2019 par Hobi

[CacaoTor]

il y a 2 minutes, Hobi a dit :

Ah, désolé, j'ai le post facile... pas la tete, Nooonnn.

Pas de souci, ça m'arrive aussi. C'est un peu plus ch**** d'éditer que re-poster  Mais faut prendre le bon réflexe.

[Oniric]

il y a une heure, Hobi a dit :

@Oniric, tu peux compiler. Ca va pas te manger! 

oui je m'en doute ! (quoique desfois ...)
mais ma question est surtout de savoir si les modifications sur l'écran que vous avez discuté sont déjà publié sur le git public ou uniquement le privé ? car je suis repassé sur le firmware d'origine en ce moment car j'ai des pieces importantes à print et j'en avais déjà raté 2
mais si vous avez publié les corrections, je suis joueur pour tester mes prints avec
j'ai retendu ma courroie Y (l'un des print important qui a foiré 2 fois )

Modifié (le) Mai 5, 2019 par Oniric

[Hobi]

@Oniric oui les modifications sont dans le repo public. Il n y a plus de git privé de mon côté. 

Édit : il va y avoir encore des changements d ici demain soir . Attends un peu . 

Modifié (le) Mai 5, 2019 par Hobi

[Oniric]

il y a 32 minutes, Hobi a dit :

@Oniric oui les modifications sont dans le repo public. Il n y a plus de git privé de mon côté 

ah ok j'ai mal compris alors ! cool je vais test ce soir je pense !

encore merci pour votre travail! j'aimerai pouvoir faire plus pour aider mais bon !

Modifié (le) Mai 5, 2019 par Oniric

[Hobi]

@Epsylon3 

j ai regardé les procédures dma et si je ne m abuse on lance le transfert dma, et on attend la fin du transfert afin de sortir de la procédure dma. 

void LCD_IO_WriteSequence(uint16_t *data, uint16_t length) {
	dma_setup_transfer(FSMC_DMA_DEV, FSMC_DMA_CHANNEL, data, DMA_SIZE_16BITS, &LCD->RAM, DMA_SIZE_16BITS, DMA_MEM_2_MEM | DMA_PINC_MODE);
	dma_set_num_transfers(FSMC_DMA_DEV, FSMC_DMA_CHANNEL, length);
	dma_clear_isr_bits(FSMC_DMA_DEV, FSMC_DMA_CHANNEL);
	dma_enable(FSMC_DMA_DEV, FSMC_DMA_CHANNEL);
	while ((dma_get_isr_bits(FSMC_DMA_DEV, FSMC_DMA_CHANNEL) & 0x0A) == 0) {};
	dma_disable(FSMC_DMA_DEV, FSMC_DMA_CHANNEL);
	}

C est dommage que jmz aie code comme ça. Grosso modo le transfert dma permet d aller 2 fois plus vite que si le transfert est effectué par le cpu. On gagne déjà. Par contre je pense qu avoir un sémaphore global serait mieux : 

1/ on vérifie si le dma est actif. Si oui on attend.. et c est le while en fin de procedure ci dessus

1 bis / on disable le dma une fois  le transfert terminé 

2/on lance le nouveau transfert Dma.

3/ on sort de la procedure dma immédiatement 

Avantage : le cpu part faire autre chose , comme du planning ou bien des calculs de steps, et pendant ce temps la, le dma continue à transférer les pixels sans ralentir le cpu. Le bus de la mémoire flash utilisé par le cpu pour exécuter le code est séparé du bus data utilisé par le dma. 

Si on relance un transfert dma, on vérifie que le dma est libre et on recommence. 

J ai un doute sur le fait de laisser le dma actif,  mais cela n a peut être aucune importance. 

Par contre il est clair que si un transfert dma vers le lcd est en cours.... il ne faut pas écrire avec le cpu dans le lcd car la on casse tout et le transfert dma finira avec les adresses envoyées par le cpu.... il faut peut être gérer la désactivation du sémaphore et du dma par une tâche d interruption. Il faudrait vérifier le sémaphore dma avant toute écriture par le cpu ( comme les icônes par exemple...) 

Qu en penses tu? Suis-je clair?

@Oniric on va encore améliorer les performances...

Modifié (le) Mai 5, 2019 par Hobi

[Epsylon3]

yep en effet, bonne idée... 

[Acidounet]

Hello,

Juste une petite question comment faire récupérer a git desktop les fichiers a jour ? j ai pas bien compris la doc press / pull  et autre désolé  sans compter que si on modifie un fichier le quelle il va garder ?

Bon c'est pas grave j y suis aller a la sauvage pour avancer suppression des fichiers puis Git desktop puis VS

Donc avec un Jerk a 10 ça ne passe pas, 4 decallages en Y, comme vous pouvez le voir sur ma machine le max est a 6. Désolé