Sida 1 av 1

Fusk-kretsar? Atmega328P

Postat: 18 februari 2019, 22:40:14
av Shimonu
Har köpt en del av dessa Atmega328P från Kjell: https://www.kjell.com/se/sortiment/el-v ... ler-p87909

Däremot får jag bekymmer så snart mina program börjar närma sig 8 KB i storlek. Jag får konstiga problem som att programmen inte verkar starta ordentligt eller står och startar om vilket är konstigt då jag har initiering och sen en evighetsloop för huvudprogrammet. Det här är beteende som verkar helt beroende på storleken på programmet. Är det möjligt att jag missat något tricks för att utnyttja hela 32 KB som påstås finnas?

Re: Fusk-kretsar? Atmega328P

Postat: 18 februari 2019, 22:42:29
av Zkronk
Det är inte så att du får slut på SRAM i mikrokontrollern, om du har mycket stora variabler som lagras där, eller kör malloc och begär mycket minne?

Re: Fusk-kretsar? Atmega328P

Postat: 18 februari 2019, 23:41:07
av Shimonu
Nope. Ingen större mängd SRAM som används. Absolut inte 2 KB på en gång. Jag kan dubbelkolla däremot.

Re: Fusk-kretsar? Atmega328P

Postat: 19 februari 2019, 00:08:31
av Swech
Det är nog mycket större sannoliket att ditt program har problem än att det är fuskkretsar

Swech

Re: Fusk-kretsar? Atmega328P

Postat: 19 februari 2019, 00:19:49
av sodjan
Det kan inte vara så att antingen din utvecklingsmiljö eller din programmerare
är inställd för en av de mindre modellerna 48, 88 eller 168? Så att t.ex
programmeraren "wrappar" runt med adresserna?

Re: Fusk-kretsar? Atmega328P

Postat: 19 februari 2019, 00:34:08
av Henry
Denna krets är sedan så billig att det knappast lönar sig för kineserna att pirattillverka den.

Det måste tjäna på det och rätt bra med. Det finns tex en typ av en OSD bildkrets som är rätt dyr och där det visade sig finnas lite långsammare pirattillverkade sådan i form av en förtäckt programmerad 328, då tjänar de på det.

Re: Fusk-kretsar? Atmega328P

Postat: 19 februari 2019, 10:09:01
av guckrum
Kollat att matningen är stabil?

Re: Fusk-kretsar? Atmega328P

Postat: 19 februari 2019, 10:45:48
av Shimonu
sodjan skrev:Det kan inte vara så att antingen din utvecklingsmiljö eller din programmerare
är inställd för en av de mindre modellerna 48, 88 eller 168? Så att t.ex
programmeraren "wrappar" runt med adresserna?
Jag kikade men det var korrekt.
Jag kör med Raspberry Pi Zero som programmerare och använder avrdude med Makefiler.

Henry: Bra poäng. Har svårt att få huvudet runt det bara.

guckrum:
Kan det vara så känsligt att det skiljer mellan program? För jag kan ladda ena programmet som går felfritt medan ett annat går bajs, konsekvent.
Jag har oscilloscop, vad bör jag leta efter då? Pratar vi stora svängningar och dippar eller kan det vara för mycket rippel bara?

Hittade en snutt kod för att läsa ut hur mycket RAM man har kvar. Får köra det med något fungerande program och se om jag ligger på gränsen.

Re: Fusk-kretsar? Atmega328P

Postat: 19 februari 2019, 14:35:14
av guckrum
Sannolikt skriver ditt program över sig själv. Men jag har varit med om ett par gånger att matningsspänningen varit boven. En gång en Pentium150 som kunde boota och ladda linuxkärnan men kraschade vid dekompression av densamma. Byte av nätagg löste problemet. En annan gång en FPGA som dök bara när jag la till extra funktionalitet. Tjockare sladdar till matningen löste det. Så det är ju värt att kolla. Du tittar efter spänningsnivå och rippel. Såklart har du ordentligt med avkopplingskapacitans?

Re: Fusk-kretsar? Atmega328P

Postat: 19 februari 2019, 15:08:04
av bearing
Swech skrev:Det är nog mycket större sannoliket att ditt program har problem än att det är fuskkretsar

Swech
Det tror jag också.

Ju större och komplexare program, ju större sannolikhet för fel.
Går det att använda Raspberry Pi Zero som debugger också?
jag kan ladda ena programmet som går felfritt medan ett annat går bajs, konsekvent
Det tyder väl först och främst på att programmet har buggar. Sen kan det så klart vara annan elektronik som det andra programmet aktiverar som ger dippar i spänningsmatningen eller liknande, men det kommer du ju hitta med ditt oscilloskop.

Re: Fusk-kretsar? Atmega328P

Postat: 19 februari 2019, 16:17:05
av Shimonu
Jag har försökt kika lite på om man kan använda en RPi för att debugga men jag har inte hittat något som visar på det än. Men om någon vet hur man kan göra det så hade jag tyckt det vore perfekt!

Jag har väl fastnat för mycket i att det börjar bugga nära 8k och litat för mycket på koden. Jag har försökt att vara säker och ha väl definierade minnesareor och varit försiktig med pekare men det har väl säkert bitit mig i ändan ändå. Jag har en stor fil som jag fortfarande behöver bryta ner, jag får nog börja där. Jag har nyligen sett ett beteende dyka fram som jag inte förstått, som händer när jag kör en längre tid. Det kanske är relaterat.

Uppskattar alla tankar och tips. Ska kika på matningen också.

Re: Fusk-kretsar? Atmega328P

Postat: 19 februari 2019, 17:16:27
av jockysoft
visst finns det kopior/kompatibla till atmega328.
den heter logicgreen LGT8F328P
ska tydligen vara 99% kompatibel.

om det är fallet här vet jag inte men det finns iaf och billigare är den med.

Re: Fusk-kretsar? Atmega328P

Postat: 19 februari 2019, 17:28:44
av Swech
Det här är en tråd med mycket spekulation.
Hur ser alla interruptvektorer ut?
Hur initieras RAM , Register, Portar etc.
Hur ser programmet ut?
Listan är lång innan kopia på krets dyker upp. ESD skada kommer före i kön.....
Har du fler än 1 krets från Kjell som beter sig så?

Swech

Re: Fusk-kretsar? Atmega328P

Postat: 19 februari 2019, 18:49:59
av Shimonu
Jag börjar misstänka nu att det var rätt redan på första gissningen. SRAM var mer använt än jag trodde. När jag körde ett program som fungerar hade jag omkring 150 byte kvar. Jag insåg då att jag har en global variabel jag inte riktigt tänkt på. Den är dessutom överdimensionerad för mina nuvarande behov så jag testar att minska den så får vi se vad som händer :)

Uppskattar igen all hjälp!

Re: Fusk-kretsar? Atmega328P

Postat: 19 februari 2019, 21:54:40
av Shimonu
Ja, det löste sig! Åh vad härligt! Hade helt tappat lusten för det här projektet för att jag inte förstod var det här problemet kom ifrån. Nu ska det kodas!