Svenska ElektronikForumet

det är var juh spännande......aha 2 veckor säger ni
Hoppas att det kommer nåt till mig också

Fagge skrev:Nu har jag drunknat i alla manualer.
Används 32khz kristallen till för att kunna bestäma tid i milisekunder i programmet eller?.
Varför har de satt dit en 8Mhz kristall i stället för 32Mhz som MCUn klarar?.
Kan det bil konfilkter mellan programeraren & kortet om man ändrar klockfrekvensen?. Eller hade inte Kretsen en inbygd ställbar oscilator?.

Det stod väl nåt om PLL nånstans, kanske är så att den kan multiplicera 8MHz kristall till 32MHz internt?

Förresten: Jag vill också ha!

*sucka*
Den är dum, den laddar ner kod.. påstår den i alla fall...
men debuggern säger bara "ERROR 16230: communication protocol error.(Argument error)"
EDIT:
Nu funkar den.. detta är ju FUSK...

Fagge: Jag har för mig att det finns en intern clock-dubblare så den internt knaller iväg på 32MHz, en ganska standart feature på "upper class" processorer, det minskat EMI-utstrålning.

Å tusan, de låter ju smart!.

Hmm, den här processorn var allt annat än min gamla 68HC11.
Med den hade man 2 accumulatorer A & B som man kunde ladda med ett tal & bearbeta & sedan välja STAA eller STAB & klistra in värdet i ram minnet eller direkt till en ports adress.
Men med denna processorn vetefan hur di har laggt upp det hela, det yras om massa R0/R01/R0H & ja jag vetefan hur di menar.
Någon som kan beskriva lite enkelt hur det är tänkt & visa upp en enkel asembler kod som får en LED att blinka, så att man har en grund att bygga runt?.

Hur är det för er som har programerat i C förut?, är det fortfarande samma språk (dialekt) som med andra processorer?.

E du galen? ska du koda den i ASM?
Har bara lekt lite lite lite med den nu. Men C är alltid C

Det är ju inte som alla basicvarianter till div uC som alla är olika eftersom språket inte är så bra på hårdvarunära programering...

Ett tips till alla som ska leka med den, i en standard tool chain är inte "load module converter" iclickad... det SKA den vara för att kunna ladda ner den

Fagge skrev:Å tusan, de låter ju smart!.

Hmm, den här processorn var allt annat än min gamla 68HC11.
Med den hade man 2 accumulatorer A & B som man kunde ladda med ett tal & bearbeta & sedan välja STAA eller STAB & klistra in värdet i ram minnet eller direkt till en ports adress.
Men med denna processorn vetefan hur di har laggt upp det hela, det yras om massa R0/R01/R0H & ja jag vetefan hur di menar.
Någon som kan beskriva lite enkelt hur det är tänkt & visa upp en enkel asembler kod som får en LED att blinka, så att man har en grund att bygga runt?.

Hur är det för er som har programerat i C förut?, är det fortfarande samma språk (dialekt) som med andra processorer?.

R0, R01 är nog register antar jag

Jag har skummat igenom hårdvaru manualen på knappt 500sidor & min hårfärg har ändrats till grått .
Far åt helvete vad många register, kombinationer av inställningar & funktioner det finns!.
Menar du att det är dö fött att försöka göra mer avancerade program med ASM för denna MCUn?.
I så fall med vad lär man sig snabbast C, helst en manual på SV.?

Jag skulle säga att det är döfött att göra avancerade program i ASM för något.... Visst kan man väll vid extrem tidskritiska applikationer behöva klämma in lite ASM, men till stor del kan man skriva allt i C och tappa rätt lite i hastighet.
Nu är det ju iof så att vi får en kompilator som optimerar mindre än möjligt. Men du har GOTT om krut under huven på denna uC

Alla styrregister för AD osv får du ju leka med endå från C

Har ingen aning om hur man lär sig C, jag hade turen att ha en polare som tvingade mig att lära mig C++ i högstadiet...

Och jo den rullar på i 32 MHz

Nu är min klocka snart klar... den går snart tom att ställa

Hur mycket mer finns det i SKP32C84 jämfört med SKP16C62P. Funderar på vilken jag ska kryssa i.

Wow, det här verkar ju lovande

Får försöka fixa en dator med java så jag kan boka en tid och också få ett kit

Hur många MIPS är dom på? 32? Klarar de multiplikation/division och andra komplicerade grejer direkt i hårdvara?

Hmm, allt är ju relativt med att säga avancerat.
Det här bygget knacka de jag ihop med 5000 rader ASM, & själva programeringen var ju inte så krabbig ändå tycker jag!.
Bygget är nu uppdaterat med fri kumunikation med RS232 & lagrar alla värden i 2 dyng med klockslag som kommer från en RTC & under menyer för å göra inställningar mm.
http://www.geekjoan.com/forum/viewtopic ... sc&start=0

"Alla styrregister för AD osv får du ju leka med endå från C"
Eee, varför skulle jag inte kunna ändra i registren ifrån ASM?.

danei: RTFM

chlle: den snabbaste klarar 32 DMIPS under vissa förutsättningar

fagge: vad jag menade var att om du kodar i C måste du endå ha koll på alla register för att ställa AD/PWM osv Det är ju inte så att C har direkt support för det via en standard set_ad() funktion.

Imponerand av att du ger dig på så pass stora ASM projekt!!! Jag hade aldrig ens fått iden Fast sen brukar ju iof mina C projekt sluta med några 1000 rader C kod istället....

Jag har gjort enstaka ASM-rutiner till den 16-bitar vi använder här på jobbet. Jag var faktisk så fräck att jag gjorde rutinen i C (såklart) och saxade ur .LST-filen och snyggade till det. Den ena var en word-copy á la memcpy(...) som behövde snabbas på ordentligt och det gick bra och de andra var FLASH-programmering/raderings rutiner som måste exekveras från RAM (eller hur AndLi ).

Jag skulle aldrig ge mig på att göra så mycket assembler om jag har C tillgängeligt, jag tycker att funktionen är roligare än kodandet men visst, då jag började med min första hemdator under CP/M knåpade jag ihop väldig stora program i ASM, min tyngsta källkod till ett menysystem fyllde ca: 250K och var den direkta anledning till att jag skaffade diskdrive.

Men jag vill heller använda tiden till att åstakomma något numera fast innan jag fick C till PIC knåpade jag ihop ett styrprogram till vår LED-matris drivkort på 2982 rader......och det fungerar perfekt.

Jag har fyllt en PIC (4k words) med assembler. Det var ethernet, TCP/IP, simpel webserver, lcd-menyer, compact-flash och rs485 och lite av varje.

Dock så tror jag inte jag vill göra om det

Håller med om att C fungerar utmärkt för det mesta, om man har lite koll på hur processorn och kompilatorn fungerar så kan man skriva C-kod som blir nästan optimal i slutändan. Assembler reserveras bäst till saker som behöver vara väldigt små, snabba eller extra hårdvarunära.