Attiny88, mlx90614 et Tm1637

International Français
1

Bonjour à tous ! Je me suis lancé dans un projet en apparence très simple qui consiste à afficher la température d'un objet à l'aide d'un capteur infra-rouge MLX90614 et la restituer sur un écran TM1637, le tout contrôlé par un Attiny85. L'attiny85 ne pouvant pas utiliser la librairie <Wire.h>, j'ai ajouté la librairie <TinyWireM.h>. J'ai donc testé d'afficher des nombres sur mon écran, ce qui marchais très bien mais quand j'ai rajouté le code pour le capteur de température sa ne marche plus.

Le code en question :

#include <TinyWireM.h>
#include <USI_TWI_Master.h>
#include <Adafruit_MiniMLX90614.h>
#include <TM1637Display.h>

#define CLK 4
#define DIO 3

TM1637Display display(CLK, DIO);
Adafruit_MiniMLX90614 mlx = Adafruit_MiniMLX90614();

void setup() {
  mlx.begin();
  display.setBrightness(0x02);
}

void loop() {
  display.showNumberDec(mlx.readObjectTempF()/10, false);
  delay(5);
}
  • Pour le branchement du TM1637 :

CLK => 4 (broche physique : 3)
DIO => 3 (broche physique : 2)

  • Et pour le MLX90614 :

SDA => 0 (broche physique : 5)
SCL => 2 (broche physique : 7)

Avec cette configuration, quand je branche mon attiny85, l'écran affiche d'abord :

-45

Puis au bout de quelques secondes :

189

Pouvez vous m'aider s'il vous plait ?
Merci d'avance !

2

bonjour
quel portage est utilisé pour l'attiny85 ? (gestionnaire de carte)

3

Bonjour, j'utilise le gestionnaire de carte suivant :

https://raw.githubusercontent.com/damellis/attiny/ide-1.6.x-boards-manager/package_damellis_attiny_index.json

4

J'ai abandonné "Damellis" qui a(vait ?) entre autres des problèmes de gestion des timers , je suis passé à çà qui me donne satisfaction

çà ne te coutera pas grand chose d'essayer

5

Merci pour votre réponse ! Je vient d'essayer et le résultat....est le même :sweat_smile:
Celas dit lors de mon choix d'attiny je ne savais pas vraiment quoi choisir entre "no bootloader", "Optiboot" et "Micronucleus/DigiSpark". J'ai donc pris "no bootloader", ce qui me semblais le plus simple.

6

Pourquoi s'imposer de pareilles contraintes ?
Une carte NANO ou PRO MINI pourrait faire le taf sans problème ...

7

Effectivement, mais si j'aimerais utiliser un Attiny c'est parce que sa me semble plus adapté pour ce projet étant donné que je n'est besoin que de 4 entrées/sorties.

8

No bootloader is the recommended option (you do still need to do "burn bootloader" to set the clock speed to what you selected - clock source is controlled by the "fusebytes" which are only written when you "burn bootloader" not on upload)

Micronucleus is used for the boards that have a USB port for direct upload, usually sold as "Digispark" (they are all chinese copies now). It uses VUSB (bitbang USB) to upload without an external programmer, but takes about 1/4th of the flash. VUSB doesn't work on all USB ports, but if it works at all, it is reliable.

Optiboot is only there for people who very much want to upload with a serial adapter. It takes about 8% of the flash. It works with any serial adapter, but is not 100% reliable, a power glitch or reset at the wrong time will break it. (I was going to say more, but it wouldn't survive google translate, and most people wouldn't understand it regardless of what language i wrote it in anyway!)

Re: t85 in general, a nano or pro mini is a little bit larger than an ATtiny85 >.> and all the Arduino boards have stuff like the power LED and regulator on board that waste power and are unsuitable for battery-operated projects. Besides, it's more fun to use a smaller processor. Throwing a nano at everything is boring!

On ATTinyCore as discussed, there's a version of Wire that should "just work" (though someone recently reported a bug that I do need to fix, Wire.readBytes · Issue #617 · SpenceKonde/ATTinyCore · GitHub ).

9

C'est une des bonnes raisons :grinning:
Bon , il semblerait que DrAzzi s’intéresse à ton problème

10

you do still need to do "burn bootloader" to set the clock speed to what you selected - clock source is controlled by the "fusebytes" which are only written when you "burn bootloader" not on upload

i never did this ... i will try, maybe by default the clock is set as external :face_with_raised_eyebrow: (which would be a problem because i want to use the internal clock!)?

(and sorry I don't speak English very well... :sweat_smile:)

11

tu programme ton at85 avec quoi , un usbasp ?

12

Avec une Arduino Uno grâce au programme "ArduinoISP" et au programmeur "Arduino as ISP"

13

ok
et tu regle les fuses comment ?
avec avrdude en ligne de commande ?

14

heuuu aucune idée !

15

comment actuellement procède tu pour uploader ton programme compilé dans l'at85 ?

basiquement le compilateur genere un .hex qui doit ensuite etre " injecté/flashé " dans l'at85
en general c'est le role d'avrdude

16

Je procède exactement comme dans cette vidéo :

17

Ok
je n'utilise pas ce systeme
(perso j'utilise avrude et avrdudess avec un usbasp)

comme tu ne touche pas aux fusibles
et si tes attiny sont neufs ils fonctionnent en horloge interne 1MHz
quelle valeur d'horloge a tu sélectionné dans ton gestionnaire de carte ?

image
image825×664 29.5 KB

image
image822×746 57.9 KB

18

il me semble que lorsqu'on utilise un programmateur externe, les fusibles sont programmés selon les options choisis tel qu'on voit sur la photo précédente.

Par contre, Si les attiny85 sont déjà dans les tiroirs, pourquoi pas.
Mais s'il faut acheter, il y a les nouveaux attinyx02 en 8 broches ou x14 en 14 broches utilisant l'interface de programmation UPDI.

Actuellement je joue avec ça associé aux portages de spenceKonde et c'est excellent.

19

Vu que j' ai des attiny8x à la pelle , je n'ai pas regardé ce qui ce faisait en x02, il, faudra que je songe à y regarder de plus prés (idem pour UPDI)

1 Like
20

What ever you use to upload your sketch to to a non-bootloader board, can also be used to write the fuses (burn bootloader). Default new-from-factory clock for all classic AVRs is 1 MHz internal (so sketches compiled for 8 MHz run at 1/8th the expected speed)

it's a separate option to prevent surprising and accidental bricking of boards from accidentally setting a fuse wrong when you don't intend to because that can brick the part (to "brick" a part means that it won't do anything more than a brick until a more complicated procedure is used to unbrick it)

Setting fuses for a a clock source that isn't present (external clock w/out external clock, or crystal without crystal or external clock) will brick the board (until you supply a suitable external clock signal), as will enabling brownout detection 4.3V on a 3.3v board or similar (unless it can be safely connected to 5v to reprogram, or disabling reset or ISP programming (ATTinyCore will never disable reset on non-bootloader board, and will never ever disable isp programming - I don't present that option and fixing either of those is a Big Deal). Since the wrong fuses can have such consequences, we don't ever want to set fuses if the user isn't expecting it. So ATTinyCore only sets fuses when doing "burn bootloader", so you will have to see the options selected (and hopefully will read them) before setting the fuses.

I don't think any classic AVRs like those supported by ATTinyCore have "safe fuses". Modern AVRs (megaTinyCore and DxCore) have several fuses that can't possibly brick the chip, and on those, I have it set the "safe" fuses on normal uploads to non-bootloader boards.