atmega 64: "device signature" niet te lezen ?

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.)