Gathering of Tweakers

IJnte

dummy@example.com (IJnte) — Thu, 20 Mar 2008 19:43:51 GMT

donderdag 20 maart 2008 20:43
Klein schoolprojectje dat uit de hand gelopen is:

Via een ARM7TDMI een VGA monitor aangestuurd. Heb gebruikt gemaakt van de Fast I/O pinnen en de FIQ Strakke H-sync puls van 31.5kHz en V-sync van 60Hz. Hiermee genereer ik een resolutie van 640 * 480 maar in werkelijkheid maak ik 64 x 64 pixels (3 bits kleuren).. Dit gaat natuurlijk nog wat meer worden, maar dan moet ik ff de ASM nog wat tunen

Sprite_tm

dummy@example.com (Sprite_tm) — Thu, 20 Mar 2008 20:42:22 GMT

donderdag 20 maart 2008 21:42
Doet me denken aan iets wat ik ooit voor een EL-demo gemaakt heb:

De hardware:

Da's een LPC2103 onder de 2 dioden; ik neem aan dat jij ook zoiets gebruikt?

Which reminds me: dat demo-contest was eigenlijk wel enorm veel fun... Misschien es een mini-demo-contest opzetten? En dan wat beperkter dan wat in het verleden gebeurd is: naar mijn ervaring zorgt dat iig voor snellere demo's omdat mensen niet meer everything but the kitchen sink erin willen gooien, en bovendien is het makkelijker te jureren omdat je geen appels met peren meer hoeft te vergelijken.

Zou er bijvoorbeeld iemand mee willen doen met een contestje om uit te vogelen wie de mooiste effecten of het mooiste verhaal of whatever kan vertellen mbv een random (single-chip) uC, een HD44780-uC en een speakertje?

IJnte

dummy@example.com (IJnte) — Thu, 20 Mar 2008 20:54:50 GMT

donderdag 20 maart 2008 21:54

quote:
Sprite_tm schreef op donderdag 20 maart 2008 @ 21:42:
Doet me denken aan iets wat ik ooit voor een EL-demo gemaakt heb:
[afbeelding]

De hardware:
[afbeelding]
Da's een LPC2103 onder de 2 dioden; ik neem aan dat jij ook zoiets gebruikt?

Gebruikt een LPC2148 middels de fast i/o pinnen, waarop middels een paar weerstandjes gewoon bot het signaal op de VGA pinnen aangesloten wordt. VGA is immers een analoog signaal, maar ik gooi gewoon 3.3V via een 270r weerstand op de pootjes.
Timer1 draait via de FIQ op de H-sync time (31.5kHz) en die genereert netjes de H-sync puls en elke 60Hz komt er ook nog es een V-sync bij. ARM draait overigens op 60MHz instruction CCLK en de PCLK op 30MHz. Ik kan het beeld denk ik nog wel 2x of 3x zo groot krijgen, of iig "faken".
Verder is een mogelijkheid om meer pinnen te gebruiken voor het uitsturen en zo 6 bits kleuren te maken
Zat er eerst aan de denken om gewoon de UART te gebruiken om tekst naar het beeld te schrijven, maar ik moet eerst eens even gaan kijken hoeveel resources de CPU nu gebruikt om het VGA beeld weg te schrijven. Als mijn interrupt te lang duurt, en ik dus te weinig tijd heb voor andere zaken dat gaat het niet lukken. Dan moet ik mijn beeldformaat verkleinen om zo meer tijd over te houden voor andere zaken.

Sprite_tm

dummy@example.com (Sprite_tm) — Thu, 20 Mar 2008 21:02:34 GMT

donderdag 20 maart 2008 22:02
Hint: Duik goed in den ARM assembly, en onderschat geintjes als flags conditioneel setten en instructies conditional kunnen maken absoluut niet: iirc kan je bijvoorbeeld beter een 6-tal instructies conditioneel maken dan eroverheenspringen ivm pipelining-issues. Combineer dat met goed gebruik van de barrel-shifter en je kan je code erg compact maken, maar let dus wel goed op: als je de arm gaat behandelen als een pic, avr of x86-processor gaat je code 2x zo groot worden.

Ow, en om die extra procent snelheid eruit te trekken: Schop je FIQ-code naar RAM toe. NXP/Philips is erg goed geweest in het een rot-eind versnellen van het flash, maar ram is nog steeds sneller.

IJnte

dummy@example.com (IJnte) — Thu, 20 Mar 2008 21:34:13 GMT

donderdag 20 maart 2008 22:34

quote:
Sprite_tm schreef op donderdag 20 maart 2008 @ 22:02:
Hint: Duik goed in den ARM assembly, en onderschat geintjes als flags conditioneel setten en instructies conditional kunnen maken absoluut niet: iirc kan je bijvoorbeeld beter een 6-tal instructies conditioneel maken dan eroverheenspringen ivm pipelining-issues. Combineer dat met goed gebruik van de barrel-shifter en je kan je code erg compact maken, maar let dus wel goed op: als je de arm gaat behandelen als een pic, avr of x86-processor gaat je code 2x zo groot worden.

Ow, en om die extra procent snelheid eruit te trekken: Schop je FIQ-code naar RAM toe. NXP/Philips is erg goed geweest in het een rot-eind versnellen van het flash, maar ram is nog steeds sneller.

Ik gebruik de onchip static RAM en het linkerscript wat aangepast zodat ik een bak "video" geheugen over heb. Ik kan denk ik nog wel wat aan de FIQ code doen, en ik denk ook nog dat ik die moet remappen nu ik het zo even bekijk. Heb al wel de MAM anders ingesteld maar wellicht valt daar nog wat te halen.
Wat betreft de pipeline issue's, heb je helemaal gelijk in. Als ie zijn instructies netjes gaat fetchen, decoden en executen en je gaat netjes je pipeline volstampen, en je hebt dan ineens een conditionele instructie dan moet mag je je pipeline gaan legen voordat verder kan. Nu scheelt het dat de ARM7 een 3-stage pipeline heeft (meen ik) maar het kost je inderdaad veel nutteloze tijd. Soms ontkom je er helaas niet aan
Ik heb een speciaal boek over de ARM opbouw en de instructieset etc, genaamd "ARM System-on-chip architecture" van Steve Furber. Enorme aanrader wanneer je bezig bent met deze processor.
Heb zelfs al wat leuke instructies gevonden waarmee je de CPSR en LR kan terug zetten, doormiddel van zo'n ldmfd met de PC en een leuk dakje

Sprite_tm

dummy@example.com (Sprite_tm) — Thu, 20 Mar 2008 22:18:21 GMT

donderdag 20 maart 2008 23:18

quote:
IJnte schreef op donderdag 20 maart 2008 @ 22:34:
[...]
Wat betreft de pipeline issue's, heb je helemaal gelijk in. Als ie zijn instructies netjes gaat fetchen, decoden en executen en je gaat netjes je pipeline volstampen, en je hebt dan ineens een conditionele instructie dan moet mag je je pipeline gaan legen voordat verder kan.

Even voor de volledigheid: ik neem aan dat je 'branch' ipv 'conditionele instructie' bedoelt?
En arm is mijn favo soort assembly. Tis net perl: het is redelijk doordacht en snel maar je kan zo enorm veel functionaliteit in een instructie stoppen... tis bijna een spelletje om de meest doordachte assembly mogelijk te bedenken.

wacco

dummy@example.com (wacco) — Thu, 20 Mar 2008 23:27:13 GMT

vrijdag 21 maart 2008 00:27
Heh, met al die schermen hier moet ik ook even

Maar de hardware is waarschijnlijk iets te heftig voor het meedoen van een demo contest

IJnte

dummy@example.com (IJnte) — Fri, 21 Mar 2008 09:56:24 GMT

vrijdag 21 maart 2008 10:56

quote:
wacco schreef op vrijdag 21 maart 2008 @ 00:27:
Heh, met al die schermen hier moet ik ook even
[afbeelding]

Maar de hardware is waarschijnlijk iets te heftig voor het meedoen van een demo contest

FPGA oid

wacco

dummy@example.com (wacco) — Fri, 21 Mar 2008 10:10:21 GMT

vrijdag 21 maart 2008 11:10
Zie de link in m'n signature. Een flinke FPGA plus een lading chips eromheen ja

Als we weer zo'n '250 punten' limiet doen ben ik er al doorheen met alleen de fpga

IJnte

dummy@example.com (IJnte) — Fri, 21 Mar 2008 10:12:08 GMT

vrijdag 21 maart 2008 11:12

quote:
wacco schreef op vrijdag 21 maart 2008 @ 11:10:
Zie de link in m'n signature. Een flinke FPGA plus een lading chips eromheen ja

Als we weer zo'n '250 punten' limiet doen ben ik er al doorheen met alleen de fpga

Owja daar heb ik wat van meegekregen ja Idd, dan is je limiet al verpeeld

IJnte

dummy@example.com (IJnte) — Fri, 21 Mar 2008 10:44:59 GMT

vrijdag 21 maart 2008 11:44

quote:
Sprite_tm schreef op donderdag 20 maart 2008 @ 23:18:
[...]

Even voor de volledigheid: ik neem aan dat je 'branch' ipv 'conditionele instructie' bedoelt?
En arm is mijn favo soort assembly. Tis net perl: het is redelijk doordacht en snel maar je kan zo enorm veel functionaliteit in een instructie stoppen... tis bijna een spelletje om de meest doordachte assembly mogelijk te bedenken.

Ja, branch instructies legen, en vullen vervolgens weer de hele pipeline. Dit kost je dus extra clockslagen (3) wat niet altijd wenselijk is maar waar ook niet altijd onderuit te komen is. Met conditionele instructies is het ook mogelijk dat je je pipeline omzeep helpt omdat hij al de volgende instructie fetched en vervolgens niet tot uitvoeren komt omdat de conditie niet klopt. Dan zal de PC vehoogt moeten worden en daarna kan de pipeline verder met fetch, decode execute.

Maar idd de ARM assembly is erg goed te begrijpen en extreem krachtig. Er komen soms hele mooie instructies voorbij die gewoon in 1 cclk kunnen worden afgehandeld. Mooie code b.v. is
asm:

1	orr r9, r9, r10, LSL #6

Vindt het wel lache dat je dat allemaal in 1 regel kan gooien
of code besparing:
asm:

1 2	ldrb r10, [r9] add r9, r9, #1

Wordt gewoon
asm:

1	ldrb r10, [r9], #1

Welke overigens (als ik het goed heb) niet in 1 maar gewoon in 2 instructies uitgevoerd wordt.
Maar juist vanwege de krachtige instructieset is het gewoon een krachtige processor.

Invisible_man

dummy@example.com (Invisible_man) — Fri, 21 Mar 2008 13:37:34 GMT

vrijdag 21 maart 2008 14:37
Ik ben de laatste tijd weer wat meer bezig met microcontrollers en heb nu bij futurlec.com twee pic bordjes besteld (pic16F877a en pic18f8720) welke ik via de paralele poort programeer. Met het pic 16F877a bordje gaat dit perfect, maar de pic18f8720 heeft er heel wat meer moeite mee. Dit begint al met herkennen van de pic vanuit de programeersoftware (WinPic800), maar ook als hij hem eindelijk herkent bij het laden van het programma. Ik heb zelf het idee dat dit kan liggen aan de zwevende poorten die nu van alles opvangen en zo de uC in de war gooien. Nou kan ik aan alle poorten pulldown weerstanden zetten, maar dat is een flink karwei. Kan ik dit ook anders oplossen (heb al iets gelezen dat je alle poorten als uitgang moet programeren, maar dan moet je wel eerst iets kunnen programeren) en hoe doen jullie dit met jullie dev-bordjes.

Het gaat overigens om dit bordje.

nick_haak

dummy@example.com (nick_haak) — Sun, 23 Mar 2008 07:07:21 GMT

zondag 23 maart 2008 08:07
Hallo allemaal,

ik ben een pulsgenerator aan het maken met een atmega8.
het bereik moet 100 hz tot 100Khz zijn, met 50% duty cycle.

de basis heb ik werkend, met timer1 in CTC mode.

het frequentiebereik is meer dan genoeg, gaat makkelijk over de 100Khz heen, maar ik heb een probleem met het regelen van de frequentie.

als ik hem op 100hz laat lopen, kan ik zonder problemen in stappen van 1hz verhogen of verlagen.
zodra de timer op 100Khz loopt, zijn die stappen gigantisch (als ik de frequentie in stappen van 1Khz laat zakken, gebeurt er de eerste paar keer niets, om vervolgens naar 90Khz te zakken)

iemand een idee hoe ik de frequentie met een beetje constante stapgrootte kan regelen?

mijn code is het volgende (GCC)
C:

#define F_CPU 8000000UL

#include <avr/io.h>





int main (void)

{



uint32_t freq;

freq = 50000;



   DDRB |= (1 << 1); // Set LED as output



   TCCR1B |= (1 << WGM12); // Configure timer 1 for CTC mode



   TCCR1A |= (1 << COM1A0); // Enable timer 1 Compare Output channel A in toggle mode



   OCR1A   = (8000000 / freq -1) / 2; // Set CTC compare value to clockspeed / frequency /2 (50% dutycycle)



   TCCR1B |= (1 << CS10); // Start timer



   for (;;)

   {

    

   }



}

de code om de frequentie te verhogen of verlagen staat er niet bij, dat bestaat uit een paar IF statements in de for loop, die kijken of een knop is ingedrukt, en daarna de frequentie verhogen / verlagen

alvast bedankt

Invisible_man

dummy@example.com (Invisible_man) — Sun, 23 Mar 2008 13:49:24 GMT

zondag 23 maart 2008 14:49

quote:
Invisible_man schreef op vrijdag 21 maart 2008 @ 14:37:
Ik ben de laatste tijd weer wat meer bezig met microcontrollers en heb nu bij futurlec.com twee pic bordjes besteld (pic16F877a en pic18f8720) welke ik via de paralele poort programeer. Met het pic 16F877a bordje gaat dit perfect, maar de pic18f8720 heeft er heel wat meer moeite mee. Dit begint al met herkennen van de pic vanuit de programeersoftware (WinPic800), maar ook als hij hem eindelijk herkent bij het laden van het programma. Ik heb zelf het idee dat dit kan liggen aan de zwevende poorten die nu van alles opvangen en zo de uC in de war gooien. Nou kan ik aan alle poorten pulldown weerstanden zetten, maar dat is een flink karwei. Kan ik dit ook anders oplossen (heb al iets gelezen dat je alle poorten als uitgang moet programeren, maar dan moet je wel eerst iets kunnen programeren) en hoe doen jullie dit met jullie dev-bordjes.

Het gaat overigens om dit bordje.

Heb gisteren op alle vrije poorten pulldown weerstanden gezet (4k7 naar gnd), maar is nog steeds het zelfde, af en toe pakt hij hem wel, maar is bij lange na niet stabiel. Een maat van mij heeft het zelfde probleem met het zelfde bordje. Iemand nog andere ideeën?

Atlas

dummy@example.com (Atlas) — Sun, 23 Mar 2008 14:07:36 GMT

zondag 23 maart 2008 15:07
Zwevende ground?

Invisible_man

dummy@example.com (Invisible_man) — Sun, 23 Mar 2008 16:44:46 GMT

zondag 23 maart 2008 17:44

quote:
Atlas schreef op zondag 23 maart 2008 @ 15:07:
Zwevende ground?

Volgens mij niet (zit overal aan elkaar genkoopt).

Zjosh

dummy@example.com (Zjosh) — Sun, 23 Mar 2008 17:32:04 GMT

zondag 23 maart 2008 18:32
Mijn PIC had last van het feit dat ik LVP perongeluk nog aan had staan. Dit gaf echt de meest vreemde symptomen en de brut viel om de haverklap uit enzo. Misschien dat eens aanpassen.

Invisible_man

dummy@example.com (Invisible_man) — Sun, 23 Mar 2008 20:26:01 GMT

zondag 23 maart 2008 21:26

quote:
Zjosh schreef op zondag 23 maart 2008 @ 18:32:
Mijn PIC had last van het feit dat ik LVP perongeluk nog aan had staan. Dit gaf echt de meest vreemde symptomen en de brut viel om de haverklap uit enzo. Misschien dat eens aanpassen.

Heb het even geprobeerd op HVP, maar volgens de handleiding die bij het bordje zit moet het juist met LVP.

Iemand mischien nog tips voor een programmer voor linux die via de parallele poort kan programeren?

Edit: Heb nu tussen het programeer printje en het pic18F8720 bordje een korter kabeltje gezet (15cm) ipv de meegeleverde kabel van een meter, maar ook dat lost niets op. Knap irritant wordt dit .

nick_haak

dummy@example.com (nick_haak) — Mon, 24 Mar 2008 07:33:00 GMT

maandag 24 maart 2008 08:33

quote:
nick_haak schreef op zondag 23 maart 2008 @ 08:07:
Hallo allemaal,

ik ben een pulsgenerator aan het maken met een atmega8.
het bereik moet 100 hz tot 100Khz zijn, met 50% duty cycle.

de basis heb ik werkend, met timer1 in CTC mode.

het frequentiebereik is meer dan genoeg, gaat makkelijk over de 100Khz heen, maar ik heb een probleem met het regelen van de frequentie.

als ik hem op 100hz laat lopen, kan ik zonder problemen in stappen van 1hz verhogen of verlagen.
zodra de timer op 100Khz loopt, zijn die stappen gigantisch (als ik de frequentie in stappen van 1Khz laat zakken, gebeurt er de eerste paar keer niets, om vervolgens naar 90Khz te zakken)

iemand een idee hoe ik de frequentie met een beetje constante stapgrootte kan regelen?

mijn code is als volgt:
[knip]

de code om de frequentie te verhogen of verlagen staat er niet bij, dat bestaat uit een paar IF statements in de for loop, die kijken of een knop is ingedrukt, en daarna de frequentie verhogen / verlagen

alvast bedankt

iemand nog een idee? zit zelf al dagen te zoeken, maar kom er niet meer uit

Springuin

dummy@example.com (Springuin) — Mon, 24 Mar 2008 08:25:51 GMT

maandag 24 maart 2008 09:25
Het heeft er denk ik mee te maken dat het verschil tussen 100KHz en 90KHz maar een stapje is voor je atmega. Ik neem aan dat je een formule gebruikt om uit te rekenen wat je in je timercontrolregisters schrijft. Reken die formule eens met de hand na voor verschillende waarden, dan zul je zien dat er het een en ander afgerond wordt.

IJnte

dummy@example.com (IJnte) — Mon, 24 Mar 2008 08:48:52 GMT

maandag 24 maart 2008 09:48

quote:
nick_haak schreef op maandag 24 maart 2008 @ 08:33:
[...]

iemand nog een idee? zit zelf al dagen te zoeken, maar kom er niet meer uit

Wellicht kan die timer maar alleen "even" waarden gebruiken, of wellicht alleen maar waarden waarvan de basis 2^x is. Anders kan de processor wellicht de deling niet uitvoeren. Je zou eens moeten kijken hoe de timer is opgebouwd. Telt de timer gewoon door met stapjes van 1 totdat de waarde is bereikt, en geeft ie dan een match

nick_haak

dummy@example.com (nick_haak) — Mon, 24 Mar 2008 09:22:41 GMT

maandag 24 maart 2008 10:22

quote:
Springuin schreef op maandag 24 maart 2008 @ 09:25:
Het heeft er denk ik mee te maken dat het verschil tussen 100KHz en 90KHz maar een stapje is voor je atmega. Ik neem aan dat je een formule gebruikt om uit te rekenen wat je in je timercontrolregisters schrijft. Reken die formule eens met de hand na voor verschillende waarden, dan zul je zien dat er het een en ander afgerond wordt.

voor 100khz geeft deze formule 39,5
voor 90khz is het 43,9444444444444
ik denk inderdaad dat je gelijk hebt, het verschil tussen 100khz en 99khz bijvoorbeeld is erg klein.

99khz geeft 39,904040404

nu eens kijken of ik het op kan lossen, lijkt best lastig te zijn zeg

Zjosh

dummy@example.com (Zjosh) — Mon, 24 Mar 2008 11:53:03 GMT

maandag 24 maart 2008 12:53
Ik denk dat je de oplossing voor het probleem moet zoeken in het maken van een heel veel bits timer, die je dan met een lage prescaler laat draaien. Zo kan je ook op de hoge frequenties een goede resolutie halen. Je kan bijvoorbeeld met een 16 bit timer + wat code een 24 bit timer maken.

nick_haak

dummy@example.com (nick_haak) — Mon, 24 Mar 2008 17:07:35 GMT

maandag 24 maart 2008 18:07
hmm, klinkt goed, kijken of ik daar meer over kan vinden

thnx

HammerT

dummy@example.com (HammerT) — Tue, 25 Mar 2008 12:25:46 GMT

dinsdag 25 maart 2008 13:25
Weten jullie of het mogelijk is om in een Atmel 128 een 40-bits type te declareren? Ik wil namelijk een struct van 5 bytes in 1 keer schrijven.