Merci pour vos remarques pertinentes.
@Steve
j'ai fait ces choix par expérience car on a une carte de controle d'acces plutot similaire au boulot.
-flash plutot que SD: les filesystems PC sont une catastrophe de fiabilité, tu coupes l'alim au milieu ca nique ta FAT. voir la fusex alpharocket... et ca peut arriver, si le bidule est par exemple sur une alim solaire ou tout seul perdu dans un shack au pied d'un pylone.
Une flash série SLC avec un filesystem flash dédié est plus résistante, SI ET SEULEMENT SI le filesystem est bien foutu. Ca devrait etre le cas avec ce qui est prévu (NuttX SmartFS) Et puis FAT=patents, non, ou elles ont expiré? et exfat c'est pire... Et pour finir j'avais pas imaginé devoir stocker des giga-octets. Niveau solidité c'est aussi plus résistant mécaniquement même si je m'attends pas a 10g d'accélération sur ce montage
-eeprom externe: plusieurs raisons:
D'abord ca supporte plus de writes que de la flash, ca peut s'écrire et s'effacer byte par byte alors que la flash du stm32 vient par erase block d'au moins 16k.
Ensuite, si tu veux reprogrammer ton STM32 via JTAG, faut faire gaffe de pas péter ta zone de flash qui sert d'EEPROM. C'est ultra relou, encore subi au boulot sur un PIC18 qui n'a que de la flash et pas d'EEPROM interne, on s'est dit plus jamais ca.
Une EE externe, ca prend peu de place, le bus I2C est super simple, les avantages en tranquilité et maintenabilité sont énormes par rapport a un bout de flash interne.
En plus ce composant vient avec une adresse MAC unique en ROM, cadeau. C'est la raison principale de ce choix, en fait.
Cette carte n'a pas d'USB direct: relou, la stack usb prend de la place, ca demande connexion a un PC. Le port USB présent est hooké a un FTDI sur la carte (ca évite d'en trainer un externe) via une UART. C'est donc pour du debug/devel. Donc oui, on pourrait pousser le firmware par la, mais en un truc genre ZMODEM. Je prévois plutot un upload "utilisateur" via ethernet (interface web d'admin). Ce bidule est imaginé comme un AP wifi, donc autonome, sans PC de commande en permanence.
La RTC externe est pas con, j'ai déja un bus I2C cablé et j'ai la place. La CR2032 sera surement connectée via 2 ptits fils, ca prend une place débile sur le PCB. Il est prévu d'avoir de la synchro NTP mais garder l'heure dans les périodes déconnectées peut être utile. Niveau précision ca dépend surtout du XTAL 32 kHz, pas de la RTC elle même. D'autre part c'est ptet même plus précis en interne, car celle ci est recalable a quelques ppm près, y compris sa dérive a long terme. c'est pas forcément le cas d'une RTC I2C. je pense avoir la place de mettre un petit XTAL tubulaire, en fait.
Ce qui manque pour finir, très con, mais: des LEDs. je sais pas quoi faire afficher de plus que l'état de link ethernet sur le RJ45.
-Power on?
-Runtime status? (mode normal, dégradé, etc)
-???
(cross)
@F4HDK: Quitte a faire un PCB autant y intégrer un max de choses utiles.
Oui tu pourras continuer le bare metal si ca te chante. le schéma complet est fourni bien entendu. tu pourras faire tout pareil qu'avant. j'ai juste remplacé le wiznet par un vrai MAC/PHY. ca reste gérable je pense, tu dois trouver des codes exemples pour l'ethernet stm32
Partager les dévs soft est évidemment un bon objectif, t'es au courant des specs que j'ai commencé? t'en penses quoi? Faudrait un topic a part, en fait.
ACK pour la ligne SDN, mais je ne vais en mettre qu'une seule pour tous les modules. vu qu'en gros y'a DEUX transceivers y a til un intéret a avoir deux SDN? genre, piloter les SDN avec une ligne multiplexée par des mosfets? je vais publier un schéma PDF ce soir, tu pourras regarder. Note, mon RFM26 démarre tres bien sans et son driver n'en a pas besoin! mais bon, ok!
je pense que c'est une carte de dev utilisable en "pilote", y'aura des bugs, mais on corrigera pour une v2 éventuellement.
je vais voir si la RTC est intégrable facilement. en grosc'est un XTAL de montre et deux pins a souder pour mettre une pile 3V quelconque. Pas la place de coller un monstrueux socket CR2032.
