Python et Ethernet/UDP

Python est le langage de prédilection du Raspberry Pi

Modérateurs : Francois, Manfraid

Répondre
romaxx
Messages : 78
Enregistré le : lun. 24 oct. 2016 10:59

Re: Python et Ethernet/UDP

Message par romaxx » mer. 28 juin 2017 20:14

destroyedlolo a écrit :
Pinhapple a écrit :Je ne le prends pas mal, t'en fais pas ! ;) J'ai découvert les interruptions pendant ce projet de stage, on n'a jamais vu ça en cours, et ce n'était pas le but (pas "d'embarqué" au programme autre que d'un peu d'Arduino). Je fais de l'Arduino et du RPi chez moi, pour le plaisir et la bidouille, sans jamais avoir eu à utiliser d'interruptions. Je suis là pour apprendre aussi ! :D
Ha ???? Heu, peut être que t'on prof s'attendait à ce que tu te renseigne pas toi même alors, parce que si on souhaite faire de l'acquisition de signal comme dans ton projet, les techniques bas niveau sont quand même le B.A.-BA ...
Parce qu'il est évident que ca peut marcher (avec beaucoup de difficultés) en faisant du busy waiting mais bon ... c'est gaspiller les ressources pour rien et ca fait très amateur.
:o Bon ok je sais que ce sujet est déjà plein de trolls.. mais sérieux, je crois que la jeune génération Française a un problème..
Tu as 24a et tu te dis passionné.. une question, tu joue aux jeux vidéos ton temps libre ?.. à 15a je connaissait déjà les interruptions, et en auto-didacte, pas de papa ou de maman dans la technique
Alors ok, admettons, il n'est jamais trop tard pour s'y mettre (quoique), mais svp.. arrêtez de dire "on n'a jamais vu ça en cours", vous assumez, vous apprenez, et vous avancez.. sinon quoi, vous serez en train de réinventer un processeur 128bits lorsque tout le monde sera passé au processeur quantique ? allons..
--
Adhérent à l'A.F.S.T.L

Bud Spencer
Raspinaute
Messages : 1089
Enregistré le : lun. 15 août 2016 21:38

Re: Python et Ethernet/UDP

Message par Bud Spencer » mer. 28 juin 2017 21:39

Pinhapple a écrit :Habile. J'avais pas compris ça comme ça.
Je te rassure, tu n’es pas le seul a tout comprendre de travers ou à manquer de compétence ou d'expérience pour faire l’analyse concrète d’un besoin. D’un autre coté les forums comme celui-là sont justement là pour essayer de débattre sur les meilleurs choix à faire ou au moins à essayer.

La méthode n’est pas ‘habile’, elle est juste simple, optimisée, éprouvée, foutrement efficace et surtout concrète. Pas de problème de typage, de boutisme, de conversion, de taille, de surcouche protocolaire ou je ne sais quoi d’autre. Un tableau d’octet n’est pas une variable. Il ne contient que des octets qui n’ont ni type ni ordre autre que celui dans lequel ils ont volontairement été placé.

Compte tenu de la quantité de data que tu veux transférer, chaque octet économisé a son importance. C’est justement ça qui va te permettre de transmettre un maximum de données en un minimum d’envois (donc de temps). Il y a une autre chose qui a échappé a beaucoup d’intervenants y compris à toi : La liaison entre ton arduimachin et son shieldtruc est une liaison SPI. Même si c’est très performant dans beaucoup de cas, en ce qui concerne l’interfaçage d’un périphérique Ethernet, c’est avant tout un premier goulot d’étranglement (comme pour la SD). Pour limiter la casse tu dois donc transférer le strict minimum de données et surtout, juste le nécessaire. Apres il est très facile de trouver la limite de taille idéale de tes paquet /IP pour définir la bonne taille de buffer pour rester optimisé (un seul octet de plus ou de moins peut faire une différence énorme), mais ça, c’est l’étape suivante qui pourra peut-être faire l’objet d’une réflexion quand on sera sortie de toute cette ./mélasse.
romaxx a écrit :[.. arrêtez de dire "on n'a jamais vu ça en cours", vous assumez, vous apprenez, et vous avancez.. ..
J’aime bien cette pensée.

Perso, Je l’aurais dit de façon plus philosophique genre : Si Archimède c’était contenté de ses cours de physique, on en serait encore à se demander quoi faire d’un levier … Mais ça veut dire la même chose ;)
Le premier ennemi de la connaissance n’est pas l’ignorance, c’est l’illusion de la connaissance (S. Hawking).

destroyedlolo
Raspinaute
Messages : 1585
Enregistré le : dim. 10 mai 2015 18:44
Localisation : Dans la campagne à côté d'Annecy
Contact :

Re: Python et Ethernet/UDP

Message par destroyedlolo » mer. 28 juin 2017 22:32

romaxx a écrit :Tu as 24a et tu te dis passionné.. une question, tu joue aux jeux vidéos ton temps libre ?..
Ha ouai, j'avais pas vu :(
C'est une école de commerce alors, parce que c'est étonnant que dans une école d'ingé, surtout à visé "dev", le concept de chaine ou de binaire ne soit pas abordé. Ni d'ailleurs ce qu'est un réseau IP, une interruption, un DMA, ... il reste quoi ? On ne parle que de m$-windows et de java ou quoi ?
Sérieusement, en IUT, on avait des projets plus complexes (je ne dis pas que tous y arrivait non plus).

Pinhapple, si tu met dans ton rapport "ce n'est pas possible", ca va faire sourire : sur un Amiga à 8Mhz, on arrivait à suivre un signal à 8k avec un peu d'électronique ... alors avec les procs actuels !
Je ne dis pas non plus qu'un rPI seul peut le faire si la précision demandée est de l'ordre la uS, la gestion des interruptions n'étant pas ce qu'on fait de mieux sur ce proc, mais tu as des pistes sur une des solutions possibles dans ce que j'ai mis plus haut ... c'est vraiment un pb classique : mais c'est à toi de jouer.

Quand à la com, grosso mobo, il te faut un flux de moins de 100Ko/s avec ton model actuel si tu choisis le bon "encodage", ce qui n'a rien de transcendant ... ce qui peu même descendre à 32ko/s si tu optimise ton flux.
Pas besoin des théories fumeuses, des gesticulations, de l'enfumage, ou d'étalage d'un pseudo savoir de maitre yoda autoproclamé.
  • BananaPI : Gentoo, disque SATA de 2 To
  • Domotique : 1-wire, TéléInfo, Tablette passée sous Gentoo, ESP8266
  • Multimedia par DNLA
  • Et pleins d'idées ... et bien sûr, pas assez de temps.
Un descriptif de ma domotique 100% fait maison.

Pinhapple
Raspinaute
Messages : 125
Enregistré le : jeu. 23 févr. 2017 15:53
Localisation : Rouen

Re: Python et Ethernet/UDP

Message par Pinhapple » jeu. 29 juin 2017 09:36

destroyedlolo a écrit :Si tu envoie le nombre 125, ton print() va envoyer '1' puis '2' puis '5' donc 3 octets pour tes données : c'est donc une chaine de caractères.
Le write() envoie directement le nombre telle que le stock le microP, à savoir le chiffre 125 qui lui peut etre codé sur 1 octets : un nombre binaire.

A ce sujet, le caractère 'A', les valeurs 65, 0x41 ou 0b1000001 sont ... la même chose !
Ok je vois, ça n'était pas spécialement précisé dans la doc du write() : "Writes UDP data to the remote connection", sans plus de détail.
destroyedlolo a écrit :(heu, ca par contre devrait faire parti des cours).
C'est juste l'expression "structure binaire" qui me posait problème. J'aurais compris "représentation binaire d'un int ou d'un char" par exemple. ;)
destroyedlolo a écrit :Sauf que :
  • les trames sur ethernet ont une longueur minimum largement plus grande que tes quelques octets. Donc même si tu penses envoyer 5 octets, t'en envoie beaucoup plus (jam + padding) ... cherche "trame ethernet" ou MTU.
  • se rajoute les entetes qui prennent aussi de la place.
Les buffers te permettent de mutualiser ces "surcharges".
Bref, ton problème de bande passante est justement que tu n'envoie que des petits bouts :P
Je dois trouver le bon compromis pour la taille du buffer quoi.
destroyedlolo a écrit :Donc, l'un dans l'autre ca revient au meme : tu mesure la durée totale du cycle et la durée pendant qu'il est a l'état haut.
Même chose que précédemment : c'est pour être sûr qu'on parle bien de la même chose. ;)
destroyedlolo a écrit :Ha ???? Heu, peut être que t'on prof s'attendait à ce que tu te renseigne pas toi même alors, parce que si on souhaite faire de l'acquisition de signal comme dans ton projet, les techniques bas niveau sont quand même le B.A.-BA ...
Mon prof ne s'attendait à rien du tout puisque les microcontrôleurs n'étaient pas au programme dans mon école d'informatique. Un peu d'Arduino en première et en quatrième année, c'est tout, et ce n'était pas le but du programme, je serais allé en école d'électronique sinon (comme l'ISEN ou l'ESIGELEC).
destroyedlolo a écrit :Parce qu'il est évident que ca peut marcher (avec beaucoup de difficultés) en faisant du busy waiting mais bon ... c'est gaspiller les ressources pour rien et ca fait très amateur.
Je ne doute pas une seconde que ça puisse marcher. Ce dont je doute, c'est qu'avec mes compétences actuelles + le matériel à disposition, ça va me demander du temps et du travail.
romaxx a écrit : :o Bon ok je sais que ce sujet est déjà plein de trolls.. mais sérieux, je crois que la jeune génération Française a un problème..
Tu as 24a et tu te dis passionné.. une question, tu joue aux jeux vidéos ton temps libre ?.. à 15a je connaissait déjà les interruptions, et en auto-didacte, pas de papa ou de maman dans la technique
Alors ok, admettons, il n'est jamais trop tard pour s'y mettre (quoique), mais svp.. arrêtez de dire "on n'a jamais vu ça en cours", vous assumez, vous apprenez, et vous avancez.. sinon quoi, vous serez en train de réinventer un processeur 128bits lorsque tout le monde sera passé au processeur quantique ? allons..
Ce genre de message, j'adore. Quel rapport avec les jeux vidéo ? Quel rapport avec "papa-maman" ? Si t'essayais d'établir mon profil, c'est raté.
Donc, pour la énième fois : je n'ai pas fait de microcontrôleur ou d'électronique à l'école. Je me débrouille en C, je pense être plutôt bon en C# et en Java, je sais utiliser des SGBD, des systèmes Linux et Windows, etc. ; ce que je connais en électronique et consorts, c'est ce que j'ai appris moi-même de mon côté, avec d'autres choses comme le Python par exemple. Si je poste un message d'aide sur un forum, quel intérêt de me répondre "t'avais qu'à écouter en cours" ? Autant ne pas répondre, merci. Si j'avais su, je n'aurais pas dit que j'avais fait une école d'informatique, mais je me demande si ça t'aurait quand même empêché de sortir un message pareil. Comment dégoûter quelqu'un de s'intéresser à un nouveau sujet...
Allez, tant qu'on est dans la remarque gratuite, bête, et méchante : à 15 ans, je savais écrire correctement le français, et depuis un moment déjà. ;)
Désolé de ne pas être un passionné auto-didacte comme toi, mais juste un curieux ! :oops:
Bud Spencer a écrit :Je te rassure, tu n’es pas le seul a tout comprendre de travers ou à manquer de compétence ou d'expérience pour faire l’analyse concrète d’un besoin. D’un autre coté les forums comme celui-là sont justement là pour essayer de débattre sur les meilleurs choix à faire ou au moins à essayer.
Merci à toi.
Bud Spencer a écrit :La méthode n’est pas ‘habile’, elle est juste simple, optimisée, éprouvée, foutrement efficace et surtout concrète. Pas de problème de typage, de boutisme, de conversion, de taille, de surcouche protocolaire ou je ne sais quoi d’autre. Un tableau d’octet n’est pas une variable. Il ne contient que des octets qui n’ont ni type ni ordre autre que celui dans lequel ils ont volontairement été placé.
Je vois, ton explication d'un message précédent était claire et nette.
Bud Spencer a écrit :Compte tenu de la quantité de data que tu veux transférer, chaque octet économisé a son importance. C’est justement ça qui va te permettre de transmettre un maximum de données en un minimum d’envois (donc de temps). Il y a une autre chose qui a échappé a beaucoup d’intervenants y compris à toi : La liaison entre ton arduimachin et son shieldtruc est une liaison SPI. Même si c’est très performant dans beaucoup de cas, en ce qui concerne l’interfaçage d’un périphérique Ethernet, c’est avant tout un premier goulot d’étranglement (comme pour la SD). Pour limiter la casse tu dois donc transférer le strict minimum de données et surtout, juste le nécessaire. Apres il est très facile de trouver la limite de taille idéale de tes paquet /IP pour définir la bonne taille de buffer pour rester optimisé (un seul octet de plus ou de moins peut faire une différence énorme), mais ça, c’est l’étape suivante qui pourra peut-être faire l’objet d’une réflexion quand on sera sortie de toute cette ./mélasse.
Très bonne remarque pour le shield connecté en SPI, ça m'avait effectivement complètement échappé. Bon rappel de la ./confiture ! :lol:
Bud Spencer a écrit :J’aime bien cette pensée.
Moi aussi, à condition d'être pertinente et justifiée, ce qui n'étais pas le cas ici. ;)
destroyedlolo a écrit :C'est une école de commerce alors, parce que c'est étonnant que dans une école d'ingé, surtout à visé "dev", le concept de chaine ou de binaire ne soit pas abordé. Ni d'ailleurs ce qu'est un réseau IP, une interruption, un DMA, ... il reste quoi ? On ne parle que de m$-windows et de java ou quoi ?
Les concepts sont heureusement abordés ; comme précisé plus haut dans ce message, c'était surtout une question de vocabulaire utilisé, afin d'être sûr qu'on parle de la même chose.
destroyedlolo a écrit :Pinhapple, si tu met dans ton rapport "ce n'est pas possible", ca va faire sourire
C'était pas prévu, j'ai forcé le trait ! :D

Je tiens à tous (oui, tous) vous remercier pour l'aide apportée sur ce sujet. Je galère pas mal, y en a dans tous les sens, et vous savez tous de quoi vous parlez, donc désolé si j'ai l'air d'être à la ramasse !
  • RPi 3 + LibreELEC / RPi 3 + RetroPie / RPi B+ + Sense HAT ou Framboisedorf ou module caméra
  • Arduino Mega, Uno, Nano
  • Freescale FRDM KL25Z

romaxx
Messages : 78
Enregistré le : lun. 24 oct. 2016 10:59

Re: Python et Ethernet/UDP

Message par romaxx » jeu. 29 juin 2017 10:22

Mon prof ne s'attendait à rien du tout puisque les microcontrôleurs n'étaient pas au programme dans mon école d'informatique. Un peu d'Arduino en première et en quatrième année, c'est tout, et ce n'était pas le but du programme, je serais allé en école d'électronique sinon (comme l'ISEN ou l'ESIGELEC).
Un bon informaticien maitrise un minimum de bas-niveaux, sinon on peut lui vendre n'importe quoi.
ça va me demander du temps et du travail.
Sérieux, encore une phrase inutile.
Ce genre de message, j'adore. Quel rapport avec les jeux vidéo ? Quel rapport avec "papa-maman" ? Si t'essayais d'établir mon profil, c'est raté.
Alors tu fais la fête, mais il y a un truc, explique moi.
Donc, pour la énième fois : je n'ai pas fait de microcontrôleur ou d'électronique à l'école. Je me débrouille en C, je pense être plutôt bon en C# et en Java, je sais utiliser des SGBD, des systèmes Linux et Windows, etc. ; ce que je connais en électronique et consorts, c'est ce que j'ai appris moi-même de mon côté, avec d'autres choses comme le Python par exemple. Si je poste un message d'aide sur un forum, quel intérêt de me répondre "t'avais qu'à écouter en cours" ? Autant ne pas répondre, merci. Si j'avais su, je n'aurais pas dit que j'avais fait une école d'informatique, mais je me demande si ça t'aurait quand même empêché de sortir un message pareil. Comment dégoûter quelqu'un de s'intéresser à un nouveau sujet...

Je n'ai pas dis que t'avais qu'à écouter en cours, j'ai dit arrête de justifier que tu n'as pas vu ça en cours, car c'est pas constructif, si tu as cette attitude dans ta future boite, c'est merci et au revoir.
Allez, tant qu'on est dans la remarque gratuite, bête, et méchante : à 15 ans, je savais écrire correctement le français, et depuis un moment déjà. ;)
Je pense l'avoir été à une époque, mais c'est comme tout, il faut pratiquer pour entretenir, j'ai peut être passé trop de temps à programmer (tu devrais essayer), et puis ton attitude ne me donne pas envie de prendre du temps à me relire, je préfère te donner des tuyaux plutôt que de belles phrases stériles. On a proposé des solutions, la balle est dans ton camp.
Désolé de ne pas être un passionné auto-didacte comme toi, mais juste un curieux ! :oops:
Alors change de voie, l'info c'est un métier de passionné, tu va te retrouver avec des mecs comme moi qui vont te bouffer tout cru :twisted: ou alors tu arrêtes de jouer à pokémon et tu t'y met vraiment.
--
Adhérent à l'A.F.S.T.L

Pinhapple
Raspinaute
Messages : 125
Enregistré le : jeu. 23 févr. 2017 15:53
Localisation : Rouen

Re: Python et Ethernet/UDP

Message par Pinhapple » jeu. 29 juin 2017 10:29

romaxx a écrit :Alors change de voie, l'info c'est un métier de passionné, tu va te retrouver avec des mecs comme moi qui vont te bouffer tout cru :twisted: ou alors tu arrêtes de jouer à pokémon et tu t'y met vraiment.
Merci de ne plus m'apporter "d'aide" alors ! ;)
  • RPi 3 + LibreELEC / RPi 3 + RetroPie / RPi B+ + Sense HAT ou Framboisedorf ou module caméra
  • Arduino Mega, Uno, Nano
  • Freescale FRDM KL25Z

romaxx
Messages : 78
Enregistré le : lun. 24 oct. 2016 10:59

Re: Python et Ethernet/UDP

Message par romaxx » jeu. 29 juin 2017 10:39

Pinhapple a écrit :
romaxx a écrit :Alors change de voie, l'info c'est un métier de passionné, tu va te retrouver avec des mecs comme moi qui vont te bouffer tout cru :twisted: ou alors tu arrêtes de jouer à pokémon et tu t'y met vraiment.
Merci de ne plus m'apporter "d'aide" alors ! ;)
https://www.senscritique.com/Pinhapple bon bah voila, si, à la place des 462 films ou des 149 jeux vidéos tu avais consacré un peu plus de temps à tes problèmes...
Je veux aider les personnes qui font un minimum d'efforts, toi tu cherches une solution toute faite pour boucler ton projet d'étude.. et repartir te divertir...il y a un temps pour tout. alors bon courage.
--
Adhérent à l'A.F.S.T.L

Pinhapple
Raspinaute
Messages : 125
Enregistré le : jeu. 23 févr. 2017 15:53
Localisation : Rouen

Re: Python et Ethernet/UDP

Message par Pinhapple » jeu. 29 juin 2017 11:03

romaxx a écrit :https://www.senscritique.com/Pinhapple bon bah voila, si, à la place des 462 films ou des 149 jeux vidéos tu avais consacré un peu plus de temps à tes problèmes...
Je veux aider les personnes qui font un minimum d'efforts, toi tu cherches une solution toute faite pour boucler ton projet d'étude.. et repartir te divertir...il y a un temps pour tout. alors bon courage.
La démarche du mec, j'adore ! :lol: Une fois de plus, aucun rapport. Continue à parler sans savoir, ça ça me divertit !
Si je voulais vraiment qu'on me mâche le travail, je ne ferais pas autant traîner mes posts sur tant de pages et de messages, et je me serais vite lassé de ne pas avoir de solution toute crue qui me tombe dans la bouche. :roll:

Chaque jour j'avance un peu plus, notamment grâce à l'aide des membres de ce forum (ceux qui ne postent pas pour dire "t'est nul dégages"), et j'apprends beaucoup de trucs, même quand ça part un peu en cacahuète. Si tu juges que je ne suis pas digne de recevoir ton aide, passe ton chemin, je ne te force pas à poster.

Allez, arrêtons les frais, ignorons-nous mutuellement.
  • RPi 3 + LibreELEC / RPi 3 + RetroPie / RPi B+ + Sense HAT ou Framboisedorf ou module caméra
  • Arduino Mega, Uno, Nano
  • Freescale FRDM KL25Z

destroyedlolo
Raspinaute
Messages : 1585
Enregistré le : dim. 10 mai 2015 18:44
Localisation : Dans la campagne à côté d'Annecy
Contact :

Re: Python et Ethernet/UDP

Message par destroyedlolo » jeu. 29 juin 2017 11:43

Pinhapple a écrit :Ok je vois, ça n'était pas spécialement précisé dans la doc du write() : "Writes UDP data to the remote connection", sans plus de détail.
C'est la différence avec le print() où là, il est expressément indiqué qu'il envoie une chaîne :)
Pinhapple a écrit :C'est juste l'expression "structure binaire" qui me posait problème. J'aurais compris "représentation binaire d'un int ou d'un char" par exemple. ;)
Ben as-tu compris en quoi ca consiste ?
Car c'était le sujet du dialogue de sourd précédent :
  • D'un coté, tu utilises un buffer ou tu met toi-même les info a un emplacement que tu spécifies ... ce qui implique que tu t'amuses à placer à la mano les informations. C'est simple si tu as que des entiers tenant sur un octet, ca demande plus de réflexion avec des entiers "multi-octets".
  • De l'autre coté, tu utilises et envoie des structures C donc c'est le compilo qui fait tout ce travail pour toi ... mais tu as a faire attention à ce que les entiers "multi-octets" soient compris de la même facons des 2 cotés.
Comme tu l'auras compris, je suis partisan dans ton cas de la seconde méthode qui est très largement répendue : elle a l'avantage d'être une méthode banalisée (utilisable aussi ailleurs que dans des communications réseau), demandant moins de manipulations explicites et surtout, conserve la sémantique des données qui transitent. Si tu as la "chance" d'avoir le même boutisme des 2 côtés, c'est aussi la plus rapide.
Pinhapple a écrit :Je dois trouver le bon compromis pour la taille du buffer quoi.
Ainsi que la méthode pour les remplir et basculer de l'un à l'autre (ce qui est triviale).
Pinhapple a écrit :Mon prof ne s'attendait à rien du tout puisque les microcontrôleurs n'étaient pas au programme dans mon école d'informatique. Un peu d'Arduino en première et en quatrième année, c'est tout, et ce n'était pas le but du programme, je serais allé en école d'électronique sinon (comme l'ISEN ou l'ESIGELEC).
Heu, non la, je ne suis pas d'accord avec toi.
A moins que l'Education Nationale ait bien changé, ils s'attendent justement à ce que tu ailles plus loin que ce que tu as appris : la curiosité, l'envie d'aller plus loin, les méthodes de recherches, l'ouverture d'esprit ... voila tout ce qui fait la différence entre un bon ingénieur et un gars qui ne sera bon qu'a appliquer une procédure (ce qui n'a rien de péjoratif : c'est nécessaire aussi).
Les 3 projets de fin d'études que j'ai eu a faire ont toujours été relativement éloignés des bases enseignées : je doute que ca ait changé malgrés les décennies (du coup, je me sens ... vvvvviiiieeeeuuuuuxxxxx :oops: ).
Pinhapple a écrit :Je ne doute pas une seconde que ça puisse marcher. Ce dont je doute, c'est qu'avec mes compétences actuelles + le matériel à disposition, ça va me demander du temps et du travail.
Tout n'est pas négatif : tu as quand même résolue les pb de communication avec les échanges précédents (même si je t'avoue ne pas comprendre pourquoi tu n'es pas parti directement sur du différentiel ... si le radar te fourni ça, il y avait une raison ;) ).
Et tu arrive a mesurer les valeurs. Reste à le faire de manière efficace et à les envoyer.
Tu es aussi aller chercher de l'aide quand tu en avait besoin ce qui est aussi un plus.

On ne peut cacher non plus qu'il y a eu quelques errements qui t'on fait perdre du temps et tu as squizer la partie "étude de l'existant", "reflexion sur les méthodes" ... que qui t'as mis un peu (beaucoup ?) dans le gaz.
Combien de temps te reste-t-il ?
Pinhapple a écrit :Très bonne remarque pour le shield connecté en SPI, ça m'avait effectivement complètement échappé. Bon rappel de la ./confiture ! :lol:
C'est pourquoi j'avais indiqué qu'il restait une épée de Damoclès au niveau de la carte réseau ;) Il aurait été bien que cette réflexion (le goulet du au SPI) vienne de toi.
Comme indiqué, tu ne devrais transférer qu'un maximum de 100ko/s (je te laisse voir si ca passe avec tes technos :D ) et si tu te penche sur les données vraiment utiles, tu verras facilement que tu peux tomber à un peu plus que 32 ko/s.
  • BananaPI : Gentoo, disque SATA de 2 To
  • Domotique : 1-wire, TéléInfo, Tablette passée sous Gentoo, ESP8266
  • Multimedia par DNLA
  • Et pleins d'idées ... et bien sûr, pas assez de temps.
Un descriptif de ma domotique 100% fait maison.

Bud Spencer
Raspinaute
Messages : 1089
Enregistré le : lun. 15 août 2016 21:38

Re: Python et Ethernet/UDP

Message par Bud Spencer » jeu. 29 juin 2017 12:57

Pinhapple a écrit :
Bud Spencer a écrit :J’aime bien cette pensée.
Moi aussi, à condition d'être pertinente et justifiée, ce qui n'étais pas le cas ici. ;)
Prends ça comme un message de motivation (ce que c’est sans doute). Rassure-toi, en ce qui me concerne, je ne mets pas en doute ta volonté et ta capacité à apprendre de toi même. Je vois la pertinence de tes questions évoluées depuis 3 de tes sujets auxquels je participe, donc que ton projet soit un succès ou un échec ne change finalement pas grand-chose. L’important sera d’avoir appris et si il y a échec, d'être en mesure d'expliquer techniquement pourquoi.
Pinhapple a écrit :Très bonne remarque pour le shield connecté en SPI, ça m'avait effectivement complètement échappé
Tout ça fait partie d'une longue la liste de petits détails que l’on à vue totalement négligés au profit de grandes théories qui peuvent être parfois certes intéressantes, mais qui finalement offusque totalement la réalité des contraintes du projet et qui n’apporte rien de concret. Moi y’en a idiot, mais idiot a tout de suite comprit qu’avec 16384 cycles par tours, un seul octet de plus par cycle, c’est tout de suite 16384 octets de plus par tour à transférer mais aussi à gérer de l’autre coté (ça c’est pour les surprises qui t’attendent coté PI …). Pas besoin d’étaler des kilomètres² de mélasse ou d’avoir fait les grandes écoles pour comprendre ça.
Le premier ennemi de la connaissance n’est pas l’ignorance, c’est l’illusion de la connaissance (S. Hawking).

Répondre

Retourner vers « Python »