atmega 64: "device signature" niet te lezen ?

Op zondag 4 augustus 2024 16:39:32 schreef trix:
what gebruiken julie voor een programmer ?

USBASP.

ik heb op AVRfreaks ook een topic gestart over dit probleem (not posible to read device signature).
en daar beweert iemand dat ik niet de verwacht MISO en MOSI pinnen moet gebruiken maar de PE0 (PD1) en PE1(PD0) pin. staat in de datasheet waar hij naar verwijst.
https://www.avrfreaks.net/s/topic/a5CV40000001qz3MAA/t397507

Klopt. Wel een instinker.
MOSI/MISO op PortB worden voor de ISP module gebruikt, maar niet voor programmeren. In mijn datasheet staat het wel vermeld:

De AtMega32 gebruikt trouwens wel gewoon de PORTB pinnen. Dus daar is geen verwarring mogelijk. 8)7

[Bericht gewijzigd door deKees op (23%)]

inderdaad, dat schijnt te kloppen............daar word je toch verdrietig van :'(
klopt mijn PCB niet meer :(

er word ook op AVR freaks vermeld dat de atmega 64 een oude controller is, nu ik toch mijn PCB moet wijzigen ga ik eens bekijken of ik een moderner versie kan vinden.
ik dacht dat micro chip daarvoor een "tool selector" had, maar die kan ik niet meer vinden.
ik heb niet zoveel eisen: min. 32 pinnen plus UART.

Dan kun je toch gewoon bij de atmega 64 blijven? Als je éénmalig bij de goede pinnen kunt komen, kun je er een bootloader in zetten, en daarna via de UART programmeren. Je kunt dan alleen niet debuggen, maar dat lijkt me bij zo'n simpele toepassing ook niet direct een probleem.

Volgens mij zijn alle ATMEGAxx nog 'oude' controllers.

Nieuwe modellen zie ik alleen bij de AtTinyxx. En die hebben dan belangrijke verbeteringen zoals 1-pin programmeren (UPDI), intelligente I/O poorten, en mappen van flash naar data-space.

Maar die hebben dan wel weer minder pinnen en flash tot max 32K.

Dus het lijkt erop dat je toch in de richting van ARM gestuurd wordt als je groter wilt...

Selectie guide : https://www.microchip.com/en-us/parametric-search.html/716

Voldoet de ATmega644 aan je wensen?

die heeft wel een hele mooie lay-out (plek van de pinnen)
kom net wat I/O te kort, maar ik kan de adresering b.v. niet met losse dipswitches doen maar "inbakken" in de code (deed ik met de atmega 32 ook).
ga ik eens bekijken.
bedankt.

Je kunt ook een analoge ingang met een spanningsdeler gebruiken om wat adres bitjes in te stellen, in plaats van dipswitches, of het in EEPROM opslaan.

Ik begrijp de voorliefde voor die (verouderde) ATMega processoren nooit zo erg.
Voor minder geld heb je bijv. een PIC24FJ1024GA606, met 16x zoveel flash, en 8x zoveel RAM.

[Bericht gewijzigd door Arco op (17%)]

Wel een mooie processor.

Maar voor-zover ik kan zien geen C++ compiler. En de XC8-compiler (alleen C, geen C++) zit achter een dure licensie. Dus dan valt die voor mijn af.

Voor de pic24 heb je een 16 bits compiler nodig (XC16 of MikroC/MikroBasic/MikroPascal for pic24).
Ik gebruik de MikroBasic compiler... (MikroE compilers zijn tot 4K code gratis)

[Bericht gewijzigd door Arco op (14%)]

Wat mij betreft doen ze wat ze moeten doen. Bij PIC is het, zoals deKees ook al aanhaald, extra betalen voor de compiler. Zo is je 'goedkoop' snel 'duurkoop'. Al zeker als je niet dagelijks ermee aan de slag gaat.

ATmega zit heel kort bij de arduino, momenteel toch 1 van de meest gebruikte ontwikkelborden en IDE. ATmega wordt dan ook ondersteund door de arduino IDE. Nog niet opgezocht, hoeveel libraries zijn er te vinden voor PIC? Vergelijk dat met het aantal voor arduino en ESP.

Nooit met PIC gewerkt en de kans dat dit snel gaat gebeuren is zeer klein.

Nooit met PIC gewerkt en de kans dat dit snel gaat gebeuren is zeer klein.

Je weet niet wat je mist... :)

Nadat ik van beperkte/betaalde PIC compilers op AVR-GCC ben overgestapt: Wat een verademing. Je weet niet wat je mist!

Edit: Maar.... Deze discussie gaat helemaal de verkeerde kant op.

TS heeft een printje gemaakt en hij krijgt dan van de software een melding dat zijn programmer geen verbinding kan krijgen met de CPU op de print. Wat is dan denk je het probleem? Nieuwe software installeren? Andere programmer kopen?

Onzin! De programmer heeft het eerder gewoon gedaan. De enige oorzaak kan zijn dat de CPU niet goed aangesloten is. Dus Trix: Laat je schema zien waar die print op gebaseerd is. Laat de layout zien. Maak een foto van de opstelling.

[Bericht gewijzigd door rew op (70%)]

Op maandag 5 augustus 2024 08:08:41 schreef rew:

Edit: Maar.... Deze discussie gaat helemaal de verkeerde kant op.

TS heeft een printje gemaakt en hij krijgt dan van de software een melding dat zijn programmer geen verbinding kan krijgen met de CPU op de print. Wat is dan denk je het probleem? Nieuwe software installeren? Andere programmer kopen?

Helemaal akkoord en een weer andere controller is nu de oplossing niet.

Wat mij ook altijd verbaast is dat de TS geen tijd neemt om de componenten uit te proberen, in dit geval een testbordje met enkele draadjes en programmeer maar.

Als ze echt niet te programmeren zijn kun je die terugsturen en inwisselen voor betere.

edit: het was al opgelost en had dat niet gelezen :z

Even lezen jongens, het probleem is al gevonden, hij heeft de verkeerde pinnen aangesloten.

Dat is op te lossen met een patch, ontwerp wijziging en nieuwe PCBs, of (wat mijn voorkeur zou hebben) eenmalig een bootloader te flashen, en daarna via de UART software te laden. De Arduino bootloader, bijvoorbeeld. Wel even checken of die de juiste UART gebruikt.

Voor de adressering zou je ook de device ID kunnen gebruiken, die is uniek per chip, maar wel 11 bits lang. Als je daar iets slims mee kunt doen, hoef je niet zelf een adres te programmeren.

Nouja.... Ik heb de STM32F303 ook pas "voor het eerst" gebruikt. Wel al eerder 64-pins STM32 gebruikt, maar nog niet deze. Direct print gemaakt. Maar goed. Dat doet het in keer. behalve dan dat ik 1 patchdraad nodig heb om USB werkend te krijgen.

Maar goed. Ik heb dus eerder 64 pins STM32's op een print gezet en dit is voor mij m'n "testprintje". Ik heb "slechts" 3 exemplaren van deze print gebakken omdat ik nog niet zeker wist of ie ging werken.

Op maandag 5 augustus 2024 11:58:57 schreef SparkyGSX:
Voor de adressering zou je ook de device ID kunnen gebruiken, die is uniek per chip, maar wel 11 bits lang.

Dat kan niet. Ik zou zomaar 2049 chips kunnen kopen en dan weet ik zeker dat daar niet-unieke device-ids tussen zitten. Bij Atmel is een deviceID denk ik een ID die de chip identificeert. Als in model-en-type. Dus alle ATmega64's zullen dezelfde deviceID hebben.

Op maandag 5 augustus 2024 11:58:57 schreef SparkyGSX:
Even lezen jongens, het probleem is al gevonden, hij heeft de verkeerde pinnen aangesloten.

OK. Gevonden.

Hier had ik ook zomaar in kunnen stinken: Ik heb tot nu toe alleen maar STM chips gebruikt die intern de 1.5k pullup op USBDP hadden en AVR chips waar de programmeer interface de gewone SPI pinnen gebruikt...

[Bericht gewijzigd door rew op (31%)]

Op maandag 5 augustus 2024 11:58:57 schreef SparkyGSX:
Even lezen jongens, het probleem is al gevonden, hij heeft de verkeerde pinnen aangesloten.

Sorry dat heb ik echt gemist...

....
Voor de adressering zou je ook de device ID kunnen gebruiken, die is uniek per chip, maar wel 11 bits lang. Als je daar iets slims mee kunt doen, hoef je niet zelf een adres te programmeren.

Is dat niet waar hij vanaf wilt ?
Met dipswitchen kun je zomaar de kaart verwisselen zonder de software aan te passen.

@TS in verband met die adressering, als je nu 1 byte gebruikt voor adres en je maakt gebruik van een RS485 zou het kunnen dat de data op de lijn aanzien wordt als het adres door anderen, hoe maak je het verschil..bytes tellen?

edit: achterhaald...RS485 half duplex werkt ook.

@rew: je hebt gelijk, ik had de datasheet niet goed genoeg gelezen. Ik ben gewend dat controllers een uniek serienummer hebben, maar dat blijkt hier niet het geval; alle velden van dit register zijn voor alle atmega64 chips hetzelfde.

@MGP: alleen het eerste byte na de frame delimiter lezen als adres? Die frame delimiter moet je wel beschermen, of je gebruikt een protocol waarbij dat byte nooit ergens anders voor kan komen.

Als je nog 2 pinnen beschikbaar hebt, zou je de devices kunnen daisy-chainen, de uitgang van het eerste apparaat naar een ingang van de tweede, waarbij je die uitgang pas hoog zet als het apparaat en adres heeft gekregen; op die manier deel je de adressen dus uit in de volgorde waarop de apparaten op de bus zijn aangesloten.

Dit is de reden dat ik al heel erg lang geen RS485 meer heb gebruikt, ik knoop alles met CAN aan elkaar.

[Bericht gewijzigd door SparkyGSX op (23%)]

Serienummers in een processor zie je bijna niet (meer).
(een van de laatsten was de Pentium III, en daar is veel tegenstand geweest om dat weer weg te krijgen wegens privacy)

Op maandag 5 augustus 2024 18:01:23 schreef SparkyGSX:
...
@MGP: alleen het eerste byte na de frame delimiter lezen als adres? Die frame delimiter moet je wel beschermen, of je gebruikt een protocol waarbij dat byte nooit ergens anders voor kan komen.

Dat wil zeggen... bytes tellen!

Volgens mij was er geen protocol en zijn data kan alle bytes vormen die mogelijk zijn dan is half duplex het veiligste volgens mij.

Dat zat in mijn gedachten omdat ik voor de sport eens andere hardware ga proberen.

@Arco: in x86 e.d. processors misschien niet, of misschien niet door elke applicatie uit te lezen, dat weet ik niet, maar in mijn beleving hebben veel modernere microcontrollers (STM32, LPC, etc.) dat juist wel.

Op maandag 5 augustus 2024 18:27:04 schreef Arco:
Serienummers in een processor zie je bijna niet (meer).

Mijn STM32 rapporteert:

> uid
My uid: WFY034.4-47.26

Van Batch WFY, lot 034 waver 4 is dit de chip die op x= -47 y=26 heeft gezeten. Dat is uniek voor deze chip.

(Van ST krijg ik de indruk dat ze daar in de loop van de tijd voor de "dure" processoren mee begonnen zijn en dat ze het na verloop van tijd ook voor de goedkopere zijn gaan doen.)