Le tout et rien, mais surtout n'importe quoi ! - Page 435

C'est parceque c'est dangeureux

oui, c'est du LITHIUM, malheureux! Et encore, ils auraient pu mettre ca dans un bain d'huile sur plate-forme stabilisée 3 axes.

^^

Avec sirene (over 9000 decibel) et gyrophare (over 9000 lumen, couleurs brunni) si par malheure le niveau d'huile baisse ou que la stabilisation ne fonctionne pas correctement !

En même temps s'ils font payer les frais de port, ils s'en foutent

Les frais de port sont fixes, et gratos à partir de 30 € de commande. Donc c'est pas très optimal pour eux ^^

annéfé

J'ai reçu un autre colis aujourd'hui, ils se sont surpassés : j'avais commandé 40 résistances. Ben ils m'ont expédié 40 sachets hermétiques contenant une résistance chacun, sauf un qui en contient deux (alors qu'il est marqué "Quantité 1").

Bon au moins cette fois, ils ont utilisé une enveloppe à bulles.

Serieux ? o_O

Franchement, est-ce que j'irais inventer un truc pareil ?

Je n'ai pas dit que tu inventais je reste juste abasourdit, il y a eu 40 personnes qui on package ton colis, chacune est partit chercher une resistance poru la mettre dans le sachet?

il n'est pas venue a l'idee du met qui a fait les sachets que c'etati debile?

Je ne sais pas. Peut-être que le process est automatisé, ou peut-être que quelqu'un s'est rendu compte que c'était débile mais comme "c'est la procédure" il n'a rien pu faire.

mort de rire

Tu devrais refuser la livraison à cause de ce doublon dans un sachet, c'est inadmissible

Si j'avais du temps et de l'argent à perdre, et que je n'avais pas de compassion pour les pauvres salariés qui doivent se taper le service clientèle, je le ferais ^^

Le but est de lire un compteur de RTC sur 32 bits, mais qui est dispo uniquement dans DEUX registres de 16 bits (merci ST, merci).

Le souci est que ca continue a s'incrémenter durant la lecture.

/*----------------------------------------------------------------------------*/
/* Return the 32-bit RTC value read from the two 16-bit regs */
uint32_t stm32f1_rtc_read(void)
{
  /* Read the HI register, then LOW */

  uint32_t hi = getreg32(STM32F1_REGBASE_RTC + STM32F1_RTC_CNTH);
  uint32_t lo = getreg32(STM32F1_REGBASE_RTC + STM32F1_RTC_CNTL);

  /* Read high again */
  uint32_t h2 = getreg32(STM32F1_REGBASE_RTC + STM32F1_RTC_CNTH);

  /* If HIGH register did not change, then LOW register is still ok */
  if(h2 != hi)
    {
      /* Else, the LOW reg has to be read again */
      lo = getreg32(STM32F1_REGBASE_RTC + STM32F1_RTC_CNTL);
    }

  return (hi<<16) + lo;
}

Ca vous parait marcher? Vraie question, hein, je crois que c'est bon mais je veux ben un avis.

cas sans pbm
HI 0x1234
LO 0x1000
H2 0x1234
-> Pas d'overflow la date valide est bien 0x12340000

cas problématique

HI 0x1234
LO 0xFFFF
H2 0x1235
-> y'a eu overflow et faut relire LO qui sera 0x0000 => RTC=0x12350000

Pas de latches pour s'assurer que les deux lectures soient cohérentes ? Même pas de bit indiquant qu'une mise à jour du compteur est imminente ? Je vois qu'ils sont toujours aussi doués chez ST...

Sinon ton code me paraît bon, n'oublie juste pas de désactiver les interruptions, sinon tu seras dans les choux si une int préempte ton code pendant un peu trop longtemps.

Non, pourtant même microchip y a pensé.

Merci pour les ints, effectivement.

autre truc marrant, je voulais diminuer le prescaler RTC pour accélérer le comptage et vérifier la cohérence, bah en fait j'ai un pbm d'écriture dans une registre protégé, ca semblait marcher a cause de la valeur par défaut du prescaler qui est a 0x8000 alors que la valeur correcte pour 32768 est 0x7FFF puisque CLKOUT = CLKIN/(PRESCALER+1)

abrutis...

La faute à un stagiaire qui a lu la doc en diagonale, probablement.

Comme celui du NUC

Mais complètement.

Ca doit être le même, après s'être fait virer

@goebish @f4grx actually, having worked a bunch with 8-bit PICs, I would say that "never" is definitely better

— whitequark (@whitequark) January 27, 2017

sure.

Godzil (./13045) :

Sinon, dans high, c'est le lsb ?je n'avais pas vu l'explication.
Et pourquoi ne pas plutôt boucler, qu'est-ce qui te garantit que ça marchera au deuxième cas si ça échoue au premier ?

Pour que ce soit le cas, il faudrait que l'exécution du code prenne plus de 2¹⁶ cycles d'horloge RTC, ce qui n'est pas réaliste si tu as les interruptions désactivées (et boucler dans ce cas créerait une boucle infinie, donc ça n'est pas une solution).

Et avec un changement de condensateur inadapté suite à un overclock raté, mmm ? Ou une horloge distante et accélérée à des vitesses relativistes ?
Sinon (un peu plus) sérieusement, rien n'empêche de mettre une limite à la boucle et d'émettre une exception si elle est dépassée

Comment dire...