Programmering af Microchip eller Atmel.

Til Atmel'en kan jeg anbefale

som en generel intro. Programmering kan laves med avr-gcc, både C og C++ kan bruges (har jeg hørt, har aldrig selv prøvet med C++)... :-) Der er både Linux og Windows-versioner, kan begge findes på AVRfreaks. I windows-distributionen er der desuden en masse nyttige gratis tools. Der findes nogle gode test filer her:

Med venlig hilsen Preben

Hvis du vil kaste dig ud i assembler til AVR kan du finde inspiration her:

Der er iøvrigt også lidt andre måske nyttige informationer for ikke-assembler programmøre.

- Lars

at

til

microchip har næsten alt hvad du kan tænke dig ang. pic'erne. tag et kig i deres applicationnotes. de gør det dog mest i assembler men det er også nemmere end C...

- patrick

" Manse" skrev i en meddelelse news:3f728e68$0$126$ snipped-for-privacy@dread11.news.tele.dk...

pic's

resten

at

til

Hej

Prøv

de har en masse prototype boards til picog vist også til AVR processoren.

Benny

Kig på

og på Det er gode steder at starte, hvis du vil bruge pic´en. Desuden er databladet på 16F84´eren nok heller ikke en dårlig ide at ligge på. Der finder du også instruktionssættet i assembler. Der er kun 32 (eller er det 35?) instruktioner, så det er meget nemt at gå igang med.

God fornøjelse.

helt

noget

Hej René,

Trykt på en rullemadras ? ;)

Bliver det lettere af at instruktionerne er "overloadede" frem for mange og specifikke ? Jeg ville tro at det bare forvirrede en nybegynder.

--
Venlig hilsen,
Søren
              * If it puzzles you dear... Reverse engineer *
LM317-PSU-Designer v1,0b

-snip-

-Snap-

HEHE! Man skriver hvad hovedet flyder over med og jeg trængte tilsyneladende til at ligge ned. :o) Der skulle naturligvis stå "Kigge".

-Snip-

-snap-

Jeg synes nu ikke at de er overloadede. Instruktionssættet er nemt at overskue og man kommer aldrig i tvivl om hvilken instruktion man skal bruge. Der er nemlig ikke problemet med at der er 3-4 instruktioner der næsten er ens og hvilken er så den rigtige at bruge!? Jeg har som begynder været utrolig glad for pic´erne. Dermed ikke sagt at Atmel-processorerne er crap, de er utrolig gode. Jeg synes bare at de er betydeligt mere komplicerede at gå igang med. Det er en smagssag og det er formålsløst at diskutere den slags, så lad os undlade det. ;o)

Mvh.

René Kirstein

Hej René,

:)

Jeg mente det sådan i stil med overloading i C++, for du bruger jo den samme instruktion til vidt forskellige ting.

Sådan kan man selvfølgelig godt se på det, men hvad tror du er hurtigst at læse efter et år (eller bare en hektisk måned), den kilde der har specifikke instruktioner til hver ting eller den hvor en given instruktion kan gøre flere ting ? :)

OK.

Jeps, det var ikke meningen at starte en hellig krig... Den bedste processor er den der, for en given person/organisation løser den givne opgave hurtigst/bedst/billigst/etc. (Og det er også min foretrukne processor ;)

Hvis man vil lære at assemblerprogrammere kan man jo i øvrigt bare starte med sin PC, det kræver ikke yderligere investeringer :)

--
Venlig hilsen,
Søren
              * If it puzzles you dear... Reverse engineer *
LM317-PSU-Designer v1,0b

hvad mener du? der er ingen instruktioner der er "overloadede" som du kalder det. De er derimod ret entydige og meget simple. Kan du komme med et eksempel?

- patrick

Det aner jeg intet om, for jeg skriver kun i assembler. ;o)

Det er der et simpelt svar på: den kode der er nemmest at læse efter et år, er den hvor man kommenterer de fleste kode linier. Så er det ligegyldigt hvad sprog man skriver i. :o)

Altid dejligt at kunne komme over ens på en civiliseret måde. Det er ikke så tit det sker i denne NG. HEHE! ;o)

Mvh.

René Kirstein

år,

Der er jeg ikke enig, det er ikke mængden af kommentarer der styrer læsbarheden, men kvaliteten af kommentarer og programmering (især variabel og label navne).

Kommentarer som: Sæt carry flag Nulstil variabel Er total overflødige

Bedre er: Signal negativ værdi Nulstil antal Men den sidste er stadig overflødig, hvis variablen har et fornuftigt navn.

Få* men gode kommentarer er det bedste, for mange ligegyldige kommentarer vil gøre det væsentlig sværere at læse programmet.

*Når jeg programmere AVR MPU'er er det vel 3-10 assembler linier per kommentar.

-snip-

-snap-

Essensen er stadig den samme. Det er ligegyldigt hvilket sprog man skriver i, bare man kommenterer sin kode, så kan man også læse og forstå den et år senere.

Det er nu heller ikke fordi jeg kommenterer hver kodelinie. Jeg blev bare lidt ivrig med skriveriet. :o)

Mvh.

René Kirstein

Det er vi enige i, men mængden af kommentarer afhænger meget af sproget og skrivestilen. Når jeg skriver i højsprog plejer jeg at bruge forholdvis lange variable navne, så navnet fortæller entydig, hvad variablen gør (Dette gælder dog ikke lokale arbejdesvariable, som har MEGET korte navne).

Hej Patrick,

Det var blot i mangel af et bedre ord for det, derfor citationstegnene :)

Det med entydighed afhænger nok af de øjne der ser ;) Jeg synes fx. at det er mere entydigt og simpelt, at have et væld af præcise instruktioner der så kun kan en "ting", som fx. JA, JB, JC, JE, JL etc. og deres komplementære (i x86), men det er vel et spørgsmål om personlige præferencer.

--
Venlig hilsen,
Søren
              * If it puzzles you dear... Reverse engineer *
LM317-PSU-Designer v1,0b

Hej René,

Assemblerkode er da selvforklarende, der står jo direkte hvad der sker ;) (men OK, de overordnede strukturer bør kommenteres).

Åhh, her er da meget fredeligt, når man ser bort fra dem der bevidst misforstår ;)

--
Venlig hilsen,
Søren
              * If it puzzles you dear... Reverse engineer *
LM317-PSU-Designer v1,0b

det er jo også netop tilfældet med pic instruktionerne. der er bare ikke så mange af dem, så man er nogengange nød til at lave lidt krumspring (læs: flere instruktioner) for at opnå den ønskede effekt. det bliver endnu bedre af at en instruktion ikke er afhængig af hvilke registre den bruges på (bortset dem der inkluderer brug af W registret). de letteste er dog nok AVR'erne - de har et helt symetrisk instruktionsset.

- patrick

Hej Patrick,

Ahemmm, enten er det præcise enkeltinstruktioner eller også er det noget andet - kan ikke være begge dele på en gang ;)

Ikke bedre set ud fra et ønske om præcise enkeltinstruktioner - det tager jo yderligere fra det at de er entydige.

Dybest set er det nok sådan, at nogle bedst kan starte på en processor mens andre bedre fanger en anden processors virkemåde...

Når man har programmeret længe nok har man nået hjulets nav og spekulerer ikke så meget på forskellighederne, men lægger i stedet kræfterne i algoritmens løsning og det er IMO vigtigere at mestre den logiske tankegang der er nødvendig, så kan man bruge enhver kerne, man skal jo alligevel slå op fra tid til anden livet ud :)

--
Venlig hilsen,
Søren
              * If it puzzles you dear... Reverse engineer *
LM317-PSU-Designer v1,0b