DIY GnuVario : variomètre opensource - openhardware Arduino

[prunkdump]

@Van Hurlu

Si le GPS clignotte avec un intervalle du genre 1s c'est qu'il fait le fix. Si tu ne l'a pas sur le vario c'est :
-> Soit que le GPS n'est pas activé dans le code
-> Soit que la connection entre le GPS et l'arduino n'est pas bonne.

1) Donc vérifies que tu utilises bien un firmware qui marche avec le GPS. Tu as mon dernier "FIRM.HEX" que j'ai envoyé dans les messages précédents.
2) Testes la connexion entre la pin "TX" du GPS en la pin "RX" de l'arduino.

Tiens nous au jus.

@Xiboard

Ok je suis en train de faire au plus simple. Voilà ce que j'ai prévu :

AXXX vario model name
HFDTE010100  (la date)
HFPLTPILOTINCHARGE: pilot name
HFGTYGLIDERTYPE: glider type
HFDTM100GPSDATUM: WGS-1984
HFFTYFRTYPE: vario model name
...
+ Les trâmes B


Et oui du coup le dernier code tourne correctement avec tout activé !    Mais il n'y a pas encore l'entête pour l'instant.

[Van Hurlu]

@Van Hurlu

Si le GPS clignotte avec un intervalle du genre 1s c'est qu'il fait le fix. Si tu ne l'a pas sur le vario c'est :
-> Soit que le GPS n'est pas activé dans le code
-> Soit que la connection entre le GPS et l'arduino n'est pas bonne.

1) Donc vérifies que tu utilises bien un firmware qui marche avec le GPS. Tu as mon dernier "FIRM.HEX" que j'ai envoyé dans les messages précédents.
2) Testes la connexion entre la pin "TX" du GPS en la pin "RX" de l'arduino.

je ne peux pas me servir de ton FIRM, j'ai un FIRM spécial avec la correction
#define MS5611_INTERRUPT_COMPARE 71

J'ai regardé le code variometer.ino et je trouve bien
#define HAVE_GPS
#define HAVE_SDCARD
//#define HAVE_BLUETOOTH


la connexion entre la pin "TX" du GPS en la pin "RX" de l'arduino est bonne


je trouve que le buzzer chauffe sacrément beaucoup, la plaque et la soudure (juste sous le buz) sont brulantes

[prunkdump]

Si si tu peux prendre ce Firmware ! J'ai fais cette modif pour tout le monde.

C'est vrai qu'elles sont très grosses tes deux soudures sous le buzzer. Vérifies si tu n'as pas fait de court circuit. Sur la photo précédente que tu as envoyé (sans le bluetooth) :

1) Vérifies que la soudure de la pin gauche du buzzer ne fait pas contact avec le chemin qui passe entre les deux pins. Tu testes entre la pin gauche du buzzer et les deux pins centrales bas du L9110.

2) Vérifies la même chose pour la pin de droite.

3) Vérifies que la pin de droite du buzzer ne fait pas contact avec la masse (à droite)

4) J'ai aussi quelques doutes sur toutes les pins centrales de la carte. Vérifie qu'elles ne font pas contact avec les voisines.

Bon courage. 

[vmath54]

Salut à tous,

Je reviens avec mes soucis de sdcard.
Je résume :
c'est une micro SD samsung 32Go, insérée dans un adaptateur SDcard. Elle est partitionnée comme l'a indiqué prunkdup :
une seule partition primaire, de 1 Go, formatée fat16.

Le vario arrive bien à charger des firms depuis cette carte ; ca marche à tous les coups. Mais si je démarre le vario avec une carte insérée, il se bloque dans la minute qui suit le fix GPS ; il écrit un fichier de 0 octets (GPS000.txt).
C'est systématique.

J'ai essayé de valider ma sdcard avec un arduino sur une breadbord ; je dispose d'un module lecteur de micro sd.

J'ai fait des lectures/écritures avec la librairie "standard" SD.H , avec la lib I2Cdev.h  ; ca marche systématiquement.


J'ai ensuite fait un bout de programme qui inclue les libs SdCard.h et LightFat16.h, toujours avec la lib I2Cdev.h

- l'appel de file.init() échoue de temps en temps, de manière aléatoire.

- lorsque le file.init() s'est bien déroulé, j'essaie d'envoyer un petit message : appels à file.write() avec à chaque fois un caractère en uint8_t, séparé par un délai de 100 ms

- je termine avec un file.sync()

Ca écrit bien un fichier GPS000.txt sur la sdcard, mais toujours avec 0 octets.

Je joins le fichier .ino correspondant

@prunkdump, j'oublie qq chose, ou bien ca confirme l'incompatibilité de la lib LightFat16.h avec ma sdcard ?
Peut-être parceque celle-ci est trop grosse (32 Go) ?

Comme je te l'ai dit, ce n'est pas vital pour moi ; je voulais juste creuser un peu.

Si tu vois d'autres essais à faire, pas de problème.

[jpg63]

En vacances pour 1 semaine à Annecy, je vais pouvoir vous faire des retours et des tests en vols

Les conditions n'ont pas permis un grand vol, les gouttes m'ont obligé à poser, mais vous pourrait regarder la trace.

Mes impressions, très réactif, un peu trop présent avec le zerotage, un petit changement de son. Avec un son qui gregreute et non qui bip ce serait super.

voici le fritzing modifier

si le code avec igc est terminé dans la semaine, je pourrais le tester en vol et vous retourner des traces

[Van Hurlu]

Si si tu peux prendre ce Firmware ! J'ai fais cette modif pour tout le monde.

Il doit y avoir une différence, car avec ton Firm (de la page 29) l'affichage part en live si je bouge trop le vario
une 3 ième ligne s'affiche avec des valeurs qui défilent sans arrêt (comme avant la correction)
pas avec le firm que j'avais compilé.

Dans les 2 cas le fix se fait en moins de 3 min (lampe bleue clignote)
dans les 2 cas : la valeur de vitesse ne s'affiche pas.

Pour la chauffe :
j'ai refait pleins de soudures, sans résultat
le buzzer fonctionne, mais il chauffe toujours au niveau des soudures
ça ne doit pas être un court jus ... ça ne fonctionnerait pas ???

Je pense plutôt que j'ai trop limé mes soudures après le premier montage.
que les pattes des composants sont trop courtes et que certaines connexions sont résistives ???

je vais essayer de gratter le circuit entre les soudures pour être sur qu'il n'y ai pas de contacts non-voulus.

Je commence a penser que mes gros doigts et ma vue qui baisse commence à être de vrais handicap  

Je tourne en rond   mais c'est une dégueulante que j'enroule  

[Van Hurlu]

avec mon firm à moi aussi , ça part en live 

[prunkdump]

Ouai c'est presque sûr qu'il y a une fuite de courant quelque part.... 

En fait ce symptôme survient quand le baromètre n'a plus assez de courant. Il y a donc autre chose qui "pompe" très fort sur la batterie et qui empêche de l'alimenter correctement. Le fait que ça chauffe semble comfirmer cette hypothèse.

Le fait que le buzzer fonctionne ne signifie pas qu'il n'y a pas de court circuit. Par exemple si ses deux pins sont en permanence sur : (pinA; pinB)

(+3.3V ; GND )

Il ne fait pas de son mais du courant passe sans arrêt à l'intérieur (et le fait chauffer).  Puis le son est généré avec une alternance de :

(+3.3V ; +3.3V)
(+3.3V ; GND )
(+3.3V ; +3.3V)
(+3.3V ; GND )
(+3.3V ; +3.3V)
(+3.3V ; GND )

Au lieu d'être à l'arrêt sur :

(GND; GND)

et de faire du son avec en alternance :

(GND ; +3.3V)
(+3.3V ; GND )
(GND; +3.3V)
(+3.3V ; GND )
(GND; +3.3V)
(+3.3V ; GND )

Ici ça serait le cas si la pinA est en contact avec le 3.3V  (RAW_V).

Tu as testé si il n'y a pas de contacts aux alentour des deux pins du buzzer ? Vérifies aussi le L9110.

Je ne pense pas que ce soit un mauvais contact sur les soudures. Je penche plutôt pour un court circuit. Regarde toutes les soudures un peu "grosses" et testes si ça ne fait pas contact avec les chemins voisins.

Non je pense pas que tu soit loin de trouver le problème    ! Mais du coup si ça se trouve le GPS précédent ne démarrait pas parcequ'il n'avait pas assez de courant à cause du même problème.

A+

[prunkdump]

Super les tests Vmath54  

En fait il va falloir déterminer d'abord si le problème vient de la bibliothèque de la carte SD ou de la bibliothèque du Fat16.

Je te donnes différent tuyaux mais bien sur, si j'ai le temps, je t'enverrais plus tard des morceaux de code tout fait.

1) D'abord dans mon code, pour des raisons d'optimization, la méthode "sync()" ne fonctionne pas. Le code écrit les données sur la carte SD lorsque un bloc est prêt. En gros il faut écrire au moins 512 octets avant que des données apparaissent sur le fichier. Assure toi donc d'écrire 512 octet + quelques octets pour vérifier les problèmes. Et enlèves les "sync()".

2) Inutile de copier la librairie I2Cdev. La connexion se fait en SPI (un autre protocole).

3) Il y une erreur dans mon code que je n'ai pas encore corrigé. Dans le fichier "LightFat16/SdCard.cpp" ligne 207. Il fait changer :

Code:

 chipSelectHigh();
  SPI.setClockDivider(SPI_SCK_INIT_DIVISOR);
  return true;

 fail:
  chipSelectHigh();
  return false;

en

Code:

 chipSelectHigh();
  SPI.setClockDivider(sckDivisor);
  return true;

 fail:
  chipSelectHigh();
  return false;

Essayes alors avec différentes vitesses "SPI_CLOCK_DIV2" ou "SPI_CLOCK_DIV4" lorsque tu initialise :

Code:

file.init(SDCARD_CS_PIN, SPI_CLOCK_DIV2);

Après il faudrait essayer de remplacer ma librairie "SdCard.h" par celle de https://github.com/greiman/SdFat/tree/master/src pour voir si le problème vient de code de la carte SD ou du FAT16. Mais là ça se complique nettement.

A suivre.

Je fini l'histoire des trâces IGC, l'intégration du boulot de jpg63, et je m'y colle avec toi.

[Van Hurlu]

Ouai c'est presque sûr qu'il y a une fuite de courant quelque part.... 

Plus si sur 
au testeur je ne voyais rien de bizarre
en désespoir de cause j'ai dessoudé le buzzer
plus de point chaud sous le buzzer, c'est le buzzer qui chauffe (au point de ne pas pouvoir garder le doigt dessus (en fait dessous) après qq minutes ??? Je ne sais pas si je pourrai le remonter, ses pattes sont très courtes
le fix se fait sans problème, mais la vitesse ne s'affiche toujours pas 

pourrais tu me redonner la photo du circuit nu? pour re-tester au mieux

[prunkdump]

Salut à tous !  

Bon ça y est j'ai publié la dernière version du code avec toutes les fonctions "de bases" !! Voici les nouveautés (avec mes tirets encore une fois    ) :

-> Les données sont envoyées simultanément sur la carte SD et sur le bluetooth.
-> Le format de sortie sur la carte SD est en IGC. L'entête est paramétrable (voir "SetVarioParameters.ino").
-> La date du jour est lue dans les trâmes RMC et inscrite dans l'entête IGC.
-> Les fichiers sur la carte SD ne sont plus créé au démarrage mais uniquement lorsque des données arrivent.
-> Possibilité d'enregistrer la trâce lorsque le GPS fixe (suffisamment précisément) ou lorsque le début du vol est détecté.
-> Réglage du déclenchement du calibrage (selon la précision du GPS).
-> Possibilité d'envoyer sur le bluetooth et la carte SD : soit l'altitude en atmosphère normalisée soit l'altitude calibrée. (Pour faire plaisir à Vmath54   )
-> Le vario analyse l'heure et le nombre de satellites dans les trâmes GGA : nmeaParser.time et nmeaParser.stelliteCount (Pour faire plaisir à Jpg63 )

Voilà ...

Il reste quelques bugs...

-> Lorsque l'on coupe le vario on peut se retrouver avec des "boutx" de trâme "B" à la fin du fichier IGC.
-> Pour l'instant si on désactive le GPS cela désactive aussi l'envois des trâmes LXNav sur le bluetooth.

Plus qu'à tester ! (Je vous met mon firmware).

A+

Edit : Vmath54. J'ai changé un peu la bibliothèque de la carte SD. Essaye de voir si ça marche pour toi maintenant.

[GtD73]

AAHHHHH bonne nouvelle !
Je teste ca demain normalement
Pour moi la version précédente n'a pas bien fonctionné aujourd'hui. J'ai même cru qu'il était briqué, j'ai réussi à le rattraper en faisant un reboot avec le bouton reset (que j'ai dessoudé )
C'est possible de planter le bootloader ??
euh moi les tirets ca me va bien, c'est bien lisible !

[vmath54]

...
-> Possibilité d'envoyer sur le bluetooth et la carte SD : soit l'altitude en atmosphère normalisée soit l'altitude calibrée. (Pour faire plaisir à Vmath54  très heureux )

Merci pour tout ce travail 
Je n'ai pas vu ou on pouvait paramétrer cela ...

Edit : Vmath54. J'ai changé un peu la bibliothèque de la carte SD. Essaye de voir si ça marche pour toi maintenant.

Avec le nouveau firm, le vario continue de bloquer dans la minute qui suit le fix GPS, lorsque la sdcard est insérée.

Ne perd pas de temps la-dessus : ce n'est pas essentiel, et je semble être le seul à rencontrer ce problème.
Je referais des tests quand j'aurais un peu de temps.
Je vais acheter une sdcard moins capacitive, pour voir.

[Xiboard]

[...]

Je n'ai pas vu ou on pouvait paramétrer cela ...

[...]

Avec : //#define VARIOMETER_SEND_CALIBRATED_ALTITUDE à commenter ou décommenter

[GtD73]

Test d'hier:impossible d'avoir un fix gps.
Je doute un peu de mon positionnement bt qui est pourtant ente l'antenne gps et la batterie, sous l'écran
Si le gitub est à jour je veux bien reessayer en désactivant le bt pour tester la partie enregistrement igc

[prunkdump]

Salut !

Oui il va falloir investiguer cette qualité de réception du GPS. Je n'arrive pas à comprendre ce qui joue la dedans    En tout cas activer ou non le bluetooth dans le code ne changera rien. Le GPS est autonôme. Il faut juste comprendre ce qui gène ou pas la réception.

La difficulté c'est qu'on ne peux pas tester facilement. Car une fois que le GPS a fait le fix, il fait les fixes suivants beaucoup plus rapidement (il mémorise les satellites). Donc il faudrait tester toujours avec des heures différentes dans la journée pour forcer des démarrages à froid. Je suis en train de me faire une feuille de tableur où je vais noter les temps. Je commence avec l'antenne à l'extérieur.

Dans la doc :

https://www.u-blox.com/sites/default/files/products/documents/GPS-Antenna_AppNote_%28GPS-X-08014%29.pdf?utm_source=en%2Fimages%2Fdownloads%2FProduct_Docs%2FGPS_Antennas_ApplicationNote%28GPS-X-08014%29.pdf

Il disent qu'il y a 3 facteurs essentiels :
-> Le plan de masse : La masse sous l'antenne réfléchit le signal. Il faut qu'elle soit un minimum grande.
-> L'angle "de vision" de l'antenne : Moins il y a d'obstacles autour de l'antenne meilleure est la réception.
-> Les interférences : Il ne faut normalement aucun signal à moins de 5mm de l'antenne.

Du coup voilà ce qui peut jouer à mon avis :

-> Le boîtier plastique ? Mais là il n'y a pas le choix.
-> Le contact de l'antenne GPS avec les contacts sur sa plaque de circuit imprimé. Il y a quatre contacteurs dont je ne connais pas l'utilité. Il faudrait essayer avec ou sans le contact avec l'antenne.
-> L'écran... Je n'ai pas testé son effet. Mais ça peut évidemment être un obstacle à la réception.
-> Le connecteur de l'écran. Il faut peut-être essayer de faire en sorte qu'il ne soit pas en contact avec l'antenne. Car le signal qui passe dedans pourrait faire des intéreférences.
-> Le bluetooth. Il ne faudrait pas qu'il soit à moins de 5mm de l'antenne ni au dessus.
-> La batterie ? Bien chargée ou non ?
-> Le fait de plier le câble de l'antenne ?

Ce matin, 9h30, antenne sortie. Le fix a pris 30 secondes à froid.

Pour ceux que ça interesserait. Il y a un logiciel pour se connecter à l'antenne :

https://www.u-blox.com/sites/default/files/u-center_UserGuide_%28UBX-13005250%29.pdf

Mais je sais pas si avec lui il y a moyen de mesurer la qualité de réception du GPS.

Faudrait que je fasse moins de code et plus de hardware/parapente/tests

A+

[fsgecko]

Ca y est j'ai enfin fini le mien ! enfin fini...  j'ai pas connecté le bluetooth. Et a l'allumage l'écran s'allume, mais au bout de quelques secondes il fait n'importe quoi! ca donne ca :

https://vimeo.com/217865184

 

[vmath54]

...
-> Possibilité d'envoyer sur le bluetooth et la carte SD : soit l'altitude en atmosphère normalisée soit l'altitude calibrée. (Pour faire plaisir à Vmath54  très heureux )

[...]

Je n'ai pas vu ou on pouvait paramétrer cela ...

[...]

Avec : //#define VARIOMETER_SEND_CALIBRATED_ALTITUDE à commenter ou décommenter

Merci à tous les deux. J'avais zappé ce paramètre.

Ce paramètre est "global" aux trames NMEA via bluetooth et aux trames IGC vers la sdcard ; je pense qu'il faut dissocier les deux fonctionnements.

C'est de l'enc.. de mouches, mais ca me parait plus logique.
A voir le code, ca serait très facile à faire, et ca ne consommerait pas de mémoire. Juste deux "#define#" au lieu d'un.

[prunkdump]

Salut Fsgecko !

Comment ça t'es pas content de faire des plafs à plus de 8000m !

Plus sérieusement en fait c'est plutôt bon signe. C'est juste que j'ai réglé la fréquence du baromètre le plus haut possible dans le programme. Et en fait selon les cartes, elles ne parviennent pas toujours à atteindre cette fréquence.

Bref tu n'as rien fais de mal il faut juste mettre à jour ton firmware !

Alors pour cela il faut que tu te trouves une carte SD (de préférence pas une micoSD avec adaptateur, elles peuvent poser problème). Et il faut que tu créé une partition FAT16 dessus. Si tu as le systême d'exploitation le plus commun Xiboard a fait un petit tuto pour créer la partition ici : (si ta carte fais 2Go ou moins, il n'y a rien à faire de particulier, c'est du FAT16).

http://www.parapentiste.info/forum/bons-plans/variometre-maison-a-base-darduino-t33538.0.html;msg595696#msg595696

Ensuite tu mets le dernier firmware sur la carte SD. Tu le trouvera ici en pièce jointe :

http://www.parapentiste.info/forum/bons-plans/variometre-maison-a-base-darduino-t33538.0.html;msg597720#msg597720

Pour finir :
-> Tu insères la carte SD dans le vario
-> Tu l'allumes
-> Tu appuis sur le bouton reset (le bouton rouge sur la carte arduino)
-> Il va redémarrer. Si ça ne marche pas tu refais un deuxième reset.

Et ça devrait être bon !

Et félicitation pour le montage   J'espère que ça t'as plu quand même !

[Xiboard]

Prunk, Je suis en train de faire quelques essais avec le dernier code.
J'attends le fix GPS depuis 10min (mais dans la maison et temps pourri et pas allumé depuis 1 semaine).
Par contre la transmission par Bluetooth marche bien.

Sauf que j'ai pas trouvé comment régler le délais entre 2 envois : tu semble envoyer toutes les secondes. De mon point de vue c'est trop peu pour être exploitable dans les logs sur tablette. C'est ajustable ? (surtout pour la trame LXWP0)

Sinon ça semble tout bon ! Et super taf pour avoir tout fait tenir en mémoire !!!    

Edit : Dans la véranda, j'ai eu le fix assez rapidement. On a bien choisi le bon protocole pour le Bluetooth sous XCSoar on a bien la posi GPS + données vario. Sous XCTrack idem. Je vais encore poursuivre quelques test en vol de toute façon pour valider tout ça. J'ai du des fois éteindre/rallumer le vario pour qu'il se connecte en Bluetooth.

Par contre j'ai eu qq chose de curieux : fichier gps000.igc bien créé, il fait 9,5Ko environ mais impossible de l'ouvrir ou le copier ! J'ai comme message "le fichier n'existe plus !". J'ai viré FIRM.HEX et je refais un essai.

[prunkdump]

Salut Xiboard  !

Je pense que passer les noms de fichiers en minuscule alors que j'utilise les "noms court" n'était pas une bonne idée. Ca marche sous Linux mais j'ai vérifié sur la doc du FAT16, ce n'est clairement pas recommandé. J'ai rechangé sur le GitHub. Les fichiers sont maintenant en :

GPS000.IGC

A vérifier si ça marche maintenant. (Attention Xiboard j'ai enlevé ton delai avant l'initialisation du baro du coup il faudra peut-être que tu le remettes. Il faut que je le rajoute dans le code.)

Pour ta question sur la fréquence des trâmes. La difficulté c'est qu'on ne peut pas envoyer en même temps les trâmes du GPS et celles du vario. Du coup j'ai fais en sorte que dès que la trâme GGA est envoyée (la dernière du GPS, "lastSentence") j'envois une trâme LxNav. Du coup la fréquence du LxNav est la même que celle des autres trâmes.

Il va falloir que je regarde à quelle vitesse les deux autres trâmes sont envoyés. Si ça va très vite on pourra peut être avoyer plusieurs LxNav entre les trâmes GPS. Mais je vais y réfléchir. Je sais pas s'il faudra augmenter la fréquence du GPS aussi ? C'est 2 secondes actuellement. Mais je comprends rien à la DOC sur les trâmes Ublox. Je sais pas si c'est volontairement flou...

Ouai Vmath je vais faire cette modif ! C'est pas bien compliqué effectivement !


Autrement j'ai fais 6 essais de GPS antenne sortie hier et ce matin et à chaque fois j'ai eut le fix en environ 30 secondes (de 29s à 36s). Il doit donc bien y avoir quelque chose qui gène le vario une fois monté.

-> Je vais faire maintenant des tests avec l'antenne dans son logement au contact du circuit. Mais sans boîtier du dessus , sans bluetooth et sans écran.

A+

[vmath54]

Arff ! A mon tour, je crois avoir foutu en l'air le bootloader.

Je récapitule ce que j'ai fait :
J'étais dans une phase de test, toujours autour de mon problème de blocage sdcard.

1) j'ai refait un essai d'écriture sur la sdcard, en utilisant un arduino externe, une breadbord et un lecteur de micro sdcard ; ceci avec la lib LightFat16 du début du projet (pas la toute dernière).
Je joins le sketch utilisé pour ce test.
Mes tests précédents n'étaient pas valides : j'envoyais une dizaines de caractère vers la sdcard ; or prunkdump m'a dit que c'était buffeurisé, et que l'écriture ne se déclenchait qu'après 255 caractères. Ceci expliquait pourquoi, lors des tests, j'avais bien création d'un fichier GPS000.TXT, mais de 0 octets.
Avec ce nouveau test, j'envoie 100 fois une chaine de caractères de 50 octets ; ca m'a bien créé le fichier GPS000.TXT, et ce coup-ci, il contenait les caractères envoyés.

2) J'ai voulu tester ce sketch avec le vario ; j'ai donc créé un FIRM.HEX, en adaptant le "Board" et le "Processor".
J'ai chargé ce firm avec la nouvelle procédure. Ca s'est à priori bien déroulé ; quoique, à l'écran, ca a affiché l'ancien écran, puis il s'est éteint complètement.
J'ai attendu un moment, pour que l'écriture éventuelle sur la sdcard puisse s'effectuer.
J'ai coupé l'interrupteur du vario, extrait la sdcard. Je l'ai lue : il y avait un fichier GPS000.TXT vide, et un fichier GPS001.TXT contenant les caractères envoyés.

Problème : depuis cette manip, plus moyen de redémarrer le vario.
Si je le redémarre retourné avec un nouveau FIRM.HEX, rien ne se passe ; plus de beep, ...
Je suis donc bloqué.

Je pense que le bootloader est mort, mais je voudrais être certain que c'est bien cela avant d'aller plus loin.
Quand je met l'interrupteur sur ON, la led rouge devant le controleur s'allume ; voir photo.
Si j'appuie sur le bouton reset, la led rouge à coté du bouton s'allume une première fois, puis s'éteint, puis s'allume une seconde fois, et s'éteint définitivement.

Votre avis, docteur ; c'est bien le bootloader qui est malade ?

Si oui ; j'ai repris dans ce forum les deux posts de prunkdump concernant une réinstallation du bootloader.
Mais si je veux le faire sur l'arduino pro mini du vario :
- je peux faire sans dessouder les différents modules ?
- on doit avoir accès aux pins 11, 12, 13, reset, 5V, GND ; il faut souder 'en volant', par dessus, des fils sur ces pins pour les raccorder à l'arduino qui va servir à la programmation ?



Enfin, je me demande pourquoi ce bootloader se serait bousillé ; je n'ai fait que charger un sketch ...
Je suis certain d'avoir pris le bon fichier .hex (je n'ai pas pris celui avec "with_bootloader")
Si je reprends le code du sketch, les choses qui ne sont pas "dans les clous" :
- il fait appel à la classe "Serial" pour écrire des infos sur l'interface série ; je ne pense pas que ca puisse provoquer un tel problème

- je n'ai pas pensé à décommenter le "#define SDCARD_CS_PIN 14" comme sur le vario ; il est resté à la valeur "4", celle de mon test sur l'arduino externe. Je ne pense pas non plus que ca puisse poser problème. Ce qui est étrange, c'est qu'il a quand même créé les fichiers GPS000.TXT sur la sdcard.

[Xiboard]

Non il n'est pas mort.

Il fallait inclure ça dans ton setup :

Code:

  /* launch firmware update if needed */
  Fastwire::setup(400,0);
  vertaccel_init();
  if( firmwareUpdateCond() ) {
   firmwareUpdate();
}

Tu ne peux donc pas faire avec la technique du retournement mais bien avec le reset.
ça doit marcher avec le bouton reset, il n'y a pas de raison...

[prunkdump]

Salut Vmath54 !

Alors effectivement ya aucune raison que le bootloader soit mort  

Mais c'est normal que tu n'arrives plus à lancer le bootloader en retounant le vario. Ce code "du retournement" n'est pas stocké dans le bootloader mais dans le programme. Si tu regardes tous les programmes du GitHub ya toujours un bout de code du genre :

Code:

   /* launch firmware update if needed */
  delay(1000);
  Fastwire::setup(400,0);
  vertaccel_init();
  if( firmwareUpdateCond() ) {
   firmwareUpdate();
}

qui permet le chargement du bootloader.

Alors il y a plusieurs possibilités pour ton problème :
-> Soit la carte dans les manip est corrompue : Reformates la et remet le dernier firmaware que j'ai donné.
-> Soit la carte est mal insérée.
-> Soit le firmaware n'est pas bien compilé : essayes avec le dernier du forum.
-> Soit (plus complexe) : ton code initialise la SdCard d'une façon qui ne permet par d'être réinitialisé derrrière par le bootloader. Donc allume le vario sans SDcard, puis après quelques secondes insère la sans éteindre le vario, puis appuis sur reset.

Autrement aucun danger à tester tes morceaux de code sur le vario !

Pas d'inquiétude ça doit pas être bien grâve Tu vas trouver sans souder !

Edit : Grillé par Xiboard Voilà très bon conseil !

[vmath54]

Ouff ! ca marche !
Vous etes trop forts 

En effet, j'aurais du penser qu'il y avait du code à insérer dans le programme pour "activer" le bootloader au retournement.

Je suis soulagé, je sentais mal l'opération fer à souder.

Merci à vous deux, je vous dois un pot