Discussion :

[BYLS07]

Bonjour,

Ma configuration :

Lazarus : 1.6 ; FPC : 3.0 ; OS : Raspbian ; RaspberryPi : 3.0

Descriptif :

Le composant Timer me génère un événement tous les 10ms et effectue une action via une procédure sous condition.
Dès le début de l'événement je désactive le timer et après l'action je le réactive.
Le traitement de l'action(si condition réunis) se fait sans aucun problème pendant les quatre premières heures environ.
Passé ce délais l'action s'effectue correctement mais avec beaucoup de lenteur(cas identique en mode débogage ou pas).

Questions :

Quels sont les outils sous Lazarus pour contrôler la mémoire, pile... ?
Quels sont les options de compilation à adopter ?

En vous remerciant,

[Jipété]

Salut,

Quels sont les outils sous Lazarus pour contrôler la mémoire, pile... ?
Quelles sont les options de compilation à adopter ?

Àmhà ce n'est pas de ce côté qu'il faut chercher, je verrais plutôt un espace disque qui se remplit, de la mémoire allouée et non libérée, ce genre de choses...

Le traitement de l'action (si condition réunie) se fait sans aucun problème pendant les quatre premières heures environ.
Passé ce délai l'action s'effectue correctement mais avec beaucoup de lenteur (cas identique en mode débogage ou pas).

Parce qu'en général, un timer fera toujours la même chose, et c'est ce sur quoi il travaille qui va évoluer et éventuellement partir en vrille, au bout d'un certain temps ("quatre heures environ").

[BeanzMaster]

Salut pour une longue période il faut utiliser TIdleTimer

[BYLS07]

Merci pour vos pistes d'actions,
- J'ai contrôlé l'espace disque avec l'application en exécution -->sans changement
En ce qui concerne la mémoire allouée et non libérée :
- j'ai recontrôlé la définition de mes variables, rien de ce coté apriori.
- À l'aide d'un bouton et des fonctions ('FreeAndNil', 'free' et 'destroy'), j'ai contrôlé en libérant certains objets après 4heures, mais sans résultat.


Je vais essayer avec TIdleTimer et je vous tiens au courant.

[BYLS07]

J'ai essayé avec TIdleTimer, il semblerait qu'il y ait une légère amélioration, mais pas suffisante. Le problème réside effectivement dans la libération de la mémoire.
Je regarde sur le partage des variables/objets entre les unités, je vais aussi réviser sur le forum (un lien ?)

Du coup je rentre plus dans le détail mais sans vous inonder de code(ça viendra...;-) ) :

Au raspberry(RPI), j'ai associé une carte E/S MCP23S17 http://www.pridopia.co.uk/pi-23s17-8-v3.html.
Après plusieurs tentatives auprès d'autres librarys(PiGPIO, RPI_HAL, WiringPI), depuis le raspberry pour bien communiquer avec cette carte j'utilise la library PXL http://asphyre.net/products/pxl
L'utilisation de trois objets en cascade permet de faire la liaison entre la carte et le raspberry :

Objet1 -> Map du système RPI
Objet2 -> Gestion des ports GPIO RPI(en paramètre : Objet1)
Objet3 -> Gestion du bus SPI(en paramètre : Objet2)

L'Objet3 me permet aisément de lire ou d'écrire sur la carte E/S. C'est cet objet que je sollicite tous les 10ms.

Je crée l'objet3 au démarrage de l'application, je l'utilise dans le timer 10ms et je le libère en fin d'application.

Question :
Est-ce qu'il vaut mieux le créer à l'événement timer et le libérer en fin de l'événement timer (Test en cours) ?

[BeanzMaster]

Salut

Est-ce qu'il vaut mieux le créer à l'événement timer et le libérer en fin de l'événement timer (Test en cours) ?

Dur de répondre.

Qu'elles sont les classes de "Object1,2 et 3 " ?
Un petit bout de code de comment tu initialises, utilises et détruits ces objets serai le bienvenue.

Le problème vient peut-être de ces objets (je parles de leur code dans la librairie Pxl, et non de ton code).

[BYLS07]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
interface
 
uses
  Classes, SysUtils,PXL.Boards.RPi, PXL.Boards.Types;
{...}
implementation
var
  FSystemCore: TFastSystemCore;
  FRPI_GPIO: TFastGPIO;
  FRPI_BusSPI: TFastSPI;
 
procedure Proc_Init_MCP23S17x8extRPI;
begin
  {ouverture du bus SPI sur le RPI :
  Mode : 0
  Chip Select (CS): 0
  fréquence : 8000000Hz (8MHz) 10Mhz maximum supporté par les MCP23S17
  }
  FSystemCore:= TFastSystemCore.Create;
  FRPI_GPIO:= TFastGPIO.Create(FSystemCore);
  FRPI_BusSPI:=TFastSPI.Create(FRPI_GPIO,TFastSPI.DefaultChipSelect, 8000000, TFastSPI.DefaultMode);

Une des procédures que j'appelle dans mon timer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
function Fonc_LectureUx(Ux:integer):word;
var
  BufferE : longword;
  OctetsEcrit: integer;
begin
  BufferE:=  (REG_GPIOA)<< 8;
  BufferE:=  BufferE + (Ux_ADDRESS[Ux] or %00000001);  //lecture du registre 
  OctetsEcrit :=FRPI_BusSPI.Transfer(@BufferE,@BufferE,4);//4 ou sizeof(BufferE));
  result:=BufferE>>16;
end;

les constantes ou tableaux de constantes sont représentés en majuscule

[jurassic pork]

hello,
pour traquer les fuites mémoire, il faut utiliser heaprc voir ici

Ami calmant, J.P

[BeanzMaster]

Salut mis à part or %00000001 je ne vois rien. Cela ne serait pas plutôt or or $00000001Je te suggère également d'englober tes procs de lecture/écriture dans des block Try...Except...Finally

Petite question as-tu un message d'erreur qui s'affiche à moment X ?

Le problème vient peut-être de une des tes autres procédures que tu appels dans le timer.

EDIT : Petite question subsidiaire : Pourquoi n'avoir pas fais une application console comme dans les exemples de la librairie PXL ?

[BYLS07]

Salut,

Salut mis à part or %00000001 je ne vois rien. Cela ne serait pas plutôt or or $00000001

%--> pour me rappeler que je travaille sur le bit de lecture/écriture en l’occurrence le huitième sur la trame opcode du MCP23S17

Je te suggère également d'englober tes procs de lecture/écriture dans des block Try...Except...Finally

oui, je vais y travailler, mais je doute que ça amène un gain de rapidité, néanmoins ça peut mettre de la lumière sur certains éléments -> merci

Petite question as-tu un message d'erreur qui s'affiche à moment X ?

c'est également une piste que je suis en train d'explorer après avoir supprimer les filtres, j'ai quelques messages du compilateur :

Hint: Mixing signed expressions and longwords gives a 64bit result
Warning: "crtbegin.o" not found, this will probably cause a linking failure
Warning: "crtend.o" not found, this will probably cause a linking failure

Pour l'instant je fais l'impasse sur les deux "warning", car ils y sont depuis le début et même sur application vide, mais si quelqu'un peut me l'expliquer je suis preneur. Je me consacre plus sur le hint et le travail sur les mots binaires, car comme il l'indique il se peut que ça augmente les cases mémoires.

Le problème vient peut-être de une des tes autres procédures que tu appels dans le timer.

C'est ce que j'ai pensé au début, du coup j'ai limité mon timer sur l'appel de ces deux procédures voire de qu'une seule, avec le même résultat.

EDIT : Petite question subsidiaire : Pourquoi n'avoir pas fais une application console comme dans les exemples de la librairie PXL ?

pour une application domotique ce n'est pas très conviviale la console.

[BYLS07]

hello,
pour traquer les fuites mémoire, il faut utiliser heaprc voir ici

Ami calmant, J.P

Merci pour cette piste, après avoir paramétrer le compilateur, heaptrc me retourne :

Heap dump by heaptrc unit
0 memory blocks allocated : 0/0
0 memory blocks freed : 0/0
0 unfreed memory blocks : 0
True heap size : 0
True free heap : 0

apriori tout à l'air bien, non ?

Du coup j'ai essayé valgrind avec l'outil callgrind mais ça reste bloqué et l'application P_CarteESlibPXL ne se lance pas :

valgrind --tool=callgrind ./P_CarteESlibPXL
==4633== Callgrind, a call-graph generating cache profiler
==4633== Copyright (C) 2002-2011, and GNU GPL'd, by Josef Weidendorfer et al.
==4633== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==4633== Command: ./P_CarteESlibPXL
==4633==
==4633== For interactive control, run 'callgrind_control -h'.
--4633-- WARNING: Serious error when reading debug info
--4633-- When reading debug info from /lib/arm-linux-gnueabihf/ld-2.24.so:
--4633-- Ignoring non-Dwarf2/3/4 block in .debug_info
--4633-- WARNING: Serious error when reading debug info
--4633-- When reading debug info from /lib/arm-linux-gnueabihf/ld-2.24.so:
--4633-- Last block truncated in .debug_info; ignoring
--4633-- WARNING: Serious error when reading debug info
--4633-- When reading debug info from /lib/arm-linux-gnueabihf/libdl-2.24.so:
--4633-- Ignoring non-Dwarf2/3/4 block in .debug_info
--4633-- WARNING: Serious error when reading debug info
--4633-- When reading debug info from /lib/arm-linux-gnueabihf/libdl-2.24.so:
--4633-- Last block truncated in .debug_info; ignoring

Le fichier callgrind est bien créer mais avec rien dedans...dommage car j'avais installé KCachegrind.