forum.zelfbouwaudio.nl

SuperR schreef:

Tjongejonge, wat een watjes mentaltieit, die studenten van tegenwoordig...

Een 88 op de post doen?

Is een oplossing maar zoiets simpels als wat Ray wil niet in 4K kunnen proppen? Tja, hier moet ik Anne bijvallen met die hogere programmeertalen

De altenatieven zijn een 168 of zijn grotere broertje waarvan ik altijd het nummer vergeet.

Pjotr schreef:

Is een oplossing maar zoiets simpels als wat Ray wil niet in 4K kunnen proppen? Tja, hier moet ik Anne bijvallen met die hogere programmeertalen

C is niet echt een hogere programmeertaal toch?
Ongemerkt moet er toch veel geregeld worden: Eeprom lezen/schrijven, spi, 1 wire, temp. sensors, button debouncen/uitlezen, menu, adc uitlezen, leds/relais aansturen, max7219 aansturen, stateful machine amp.status, diverse timers etc.

Ik denk dat je het in assembler niet veel kleiner krijgt, maar wel een stuk langer bezig bent.

Of zoals ik iemand hoorde zeggen;
Als je I/O's te kort komt, als je je best moet doen om code klein te houden of als je snelheid tekort komt, heb je de verkeerde uC gebruikt..

En inderdaad, met beschrijft een taal als "hoger" juist als het meer afstand neemt van de machinetaal.

knuisje schreef:

Pjotr schreef:

Is een oplossing maar zoiets simpels als wat Ray wil niet in 4K kunnen proppen? Tja, hier moet ik Anne bijvallen met die hogere programmeertalen

C is niet echt een hogere programmeertaal toch?
Ongemerkt moet er toch veel geregeld worden: Eeprom lezen/schrijven, spi, 1 wire, temp. sensors, button debouncen/uitlezen, menu, adc uitlezen, leds/relais aansturen, max7219 aansturen, stateful machine amp.status, diverse timers etc.

Ik denk dat je het in assembler niet veel kleiner krijgt, maar wel een stuk langer bezig bent.

C werkt een stuk gestructureerder dan assembler, dat is waar. Maar om die structuur consistent te houden kost dat flink overhead (flash geheugen) en snelheid. Is allemaal niet zo erg als je processor groot genoeg is.

SuperR schreef:

Een 88 op de post doen?

Burps, de Chinees is naar binnen gewerkt...
Okee, okee, bij deze mijn welgemeende en oprechte excuses.
Ik had niet zo'n generaliserende opmerking mogen maken.

Doet mijn maar eenmaal de Atmega88. ik zal je even een PBtje sturen.

Pjotr schreef:

C werkt een stuk gestructureerder dan assembler, dat is waar. Maar om die structuur consistent te houden kost dat flink overhead (flash geheugen) en snelheid. Is allemaal niet zo erg als je processor groot genoeg is.

Ben ik niet helemaal met je eens. De huidige C-compilers genereren vaak snellere of kleinere code dan met de hand geschreven assemblerroutines. Assembler biedt alleen in zeer specifieke toepassingen nog een snelheidsvoordeel. En zoals gezegd is het in C veel makkelijker om een wat grotere toepassing te ontwikkelen en debuggen. Maar ieder z'n voorkeur natuurlijk.

Tja, rubbish in rubbish out, geldt voor C net zo hard als voor assembler

knuisje schreef:

Ben ik niet helemaal met je eens. De huidige C-compilers genereren vaak snellere of kleinere code dan met de hand geschreven assemblerroutines. Assembler biedt alleen in zeer specifieke toepassingen nog een snelheidsvoordeel. En zoals gezegd is het in C veel makkelijker om een wat grotere toepassing te ontwikkelen en debuggen. Maar ieder z'n voorkeur natuurlijk.

Dat moet je nou niet zeggen tegen iemand die 20 jaar lang machinebesturingen en bijbehorende user interfaces heeft geschreven in assembler. Een C-compiler genereert uiteindelijk ook assembler code! C-compilers, of beter de optimizers, worden wel steeds beter maar halen echt nog lang niet de efficiëntie van direct in assembler programmeren. Laat staan dat ze kleinere code dan assembler genereren, dat kan namelijk niet

Ik heb het niet over cracks als jij die zeer ervaren zijn in Assembler programmeren.
Maar de gemiddelde ziel die in Assembler programmeert zal er nog een hele kluif aan hebben om net zo efficiente code te schrijven als een C-compiler genereert.

Ik ben blij dat ikzelf nu een beetje los ben op C en heb geen behoefte om over te stappen op Assembler.

In de bijlage nog de gegeneerde code zoals ik nu heb. Puur uit interesse: waar is nu vooral de winst te halen?

En je C code, zou je die ook willen uploaden, puur uit educatieve interesse? Ik ben nog niet echt serieus begonnen met C dus alle voorbeelden zijn prettig om door te spitten.

Ik zal vanavond of vanmiddag een 88 in een envelopje stoppen

SuperR schreef:

En je C code, zou je die ook willen uploaden, puur uit educatieve interesse? Ik ben nog niet echt serieus begonnen met C dus alle voorbeelden zijn prettig om door te spitten.

De huidige C-code vind je in de bijlage.

Om in deze tijd nog assembler te gaan schrijven is vanuit mijn optiek naïef. Als je ziet dat je voor een euro meer het dubbele geheugen hebt, waarom zou je dan gaan zweten op assembler? Daarnaast vind ik C veel beter te onderhouden. Als je na een jaar toch nog een wijziging wilt doorvoeren dan zit je zo weer in de code, mits de c gestructureerd geschreven is natuurlijk.

Natuurlijk is dat zo Fokko, voor het overgrote deel ben je natuurlijk niet bij als je nu nog in assembler programmeert. Al vind ik het zelf nog erg leuk, vooral als het op timing aan komt. Een goede kennis van assembler helpt af en toe wel als je C progje niet zo lekker lopen wil. Het hangt ook van de processor af. Sommige, zoals de PIC'jes, hebben zulke brakke beperkte opcodes dat assembler schrijven sowieso compleet onmogelijk is.

Gestructureerd programmeren? Zeker een must! Welke taal je ook gebruikt maakt niet uit. Helaas krijg ik knap wat code te zien van mensen die er duidelijk nog nooit van gehoord hebben

Pjotr schreef:

Sommige, zoals de PIC'jes, hebben zulke brakke beperkte opcodes dat assembler schrijven sowieso compleet onmogelijk is.

Ik doe niet anders (16F84/628A/88/whatever needed) voor beperkte besturingstoepassingen. Best te doen als je het eenmaal gewend bent. En een hoop re-use van eigen bestaande en internet code. Ieder zijn ding.

Nieuwe voeding en programmer is ook al aardig onderweg...
De USB aansluiting komt samen met de indicatie LED's op een apart printje te zitten, vlak onder het bovendeksel :

guido schreef:

Pjotr schreef:

Sommige, zoals de PIC'jes, hebben zulke brakke beperkte opcodes dat assembler schrijven sowieso compleet onmogelijk is.

Ik doe niet anders (16F84/628A/88/whatever needed) voor beperkte besturingstoepassingen. Best te doen als je het eenmaal gewend bent. En een hoop re-use van eigen bestaande en internet code. Ieder zijn ding.

Het kan natuurlijk altijd wel maar je moet toch wel licht masochistisch zijn Zijn er toch wel leukere MCU'tjes als je het in assembler wilt doen. Maar i.d.d. ieder zijn ding. Zo heb ik ooit eens een assembler schrijver ontmoet die zelf nog met de hand de adres calculatie deed en het met de hand naar bytes zat te vertalen. Hij was erg wel lang bezig...

Wat een oorverdovende stilte hier ineens.. jullie zijn dus klaar met bakkeleien over programmeertalen ?

Zojuist is er een Atmega88 controller gearriveerd, dus Knuisje kan zich weer uitleven op de code.
Zowaar ook nog een mazzeltje, na het slopen van de halve versterker blijkt dat de Amplimo relais dezelfde footprint hebben als die er al inzaten.
Ik hoef daar dus geen nieuwe printjes voor te tekenen en te etsen.
Kwestie van uitsolderen, en de nieuwe erin zetten.

Je mag ook weleens mazzel hebben toch?

Ik dacht ik ga even kijken hoe het met de Aleph is. Krijg ik pointers, arrays en linkers om mijn oren. Welke instelstroom gebruik je voor de MCU?

Volgens mij draait die Atmega in een klasse B instelling! Schande!!!!!!!

Ja, en de fadende led draait op een pwm signaal dus klasse D.

Ga jij eens gauw je mond spoelen met je smerige taal ! klasse d...tsss...
De letter geeft het al aan, er zitten er nog 3 boven...

RC filtertjes gemaakt, en deze parallel aan de diodes gezet. tevens de Amplimo relais gemonteerd.

Mooi man !

ray5150 schreef:

Ja, ik heb wel een paar ideetjes :
(ik weet niet of de volgende zaken mogelijk zijn, maar ik gooi gewoon een paar balletjes op.)

- De power LED, Als de spanning op de controller word gezet gaat de LED in en uit faden.
Indien binnen 1 minuut geen opstart sequentie plaatsvind zal de LED uitgaan.
Na het uitschakelen blijft de LED nog 1 minuut in en uit faden en gaat daarna uit.

- Voor de ruststroom weergave vroeg ik mij af of het mogelijk is om dat in het "menu" op te nemen.

Kun je iets verzinnen dat het in het menu opgenomen kan worden dat je kunt kiezen tussen omschakelen tussen continu temperatuur weergave, continu ruststroom weergave,
en een automatische omschakeling van de weergave, maar dan in plaats van om de 10 seconden, om de minuut ?

Nou, bovenstaande functionaliteit zit er in.

Het menu werkt als volgt:
Een korte druk op de knop wandelt door de menu-opties ht (High Temp - triptemperatuur), dP (DisPlay) en -- (Exit). Hierbij verschijnt in het rechterdisplay de ingestelde waarde. Bij de temperatuur is dit een waarde tussen 60 en 70. Bij display is dit tE (alleen temperatuur), cu (alleen current) of tc (elke minuut wisselen tussen temperatuur en current). Druk op de knop tot een punt achter de ingestelde waarde verschijnt, daarna kan met een korte druk de waarde worden veranderd. Hou de knop ingedrukt totdat de punt gaat knipperen. De waarde is nu ingesteld en er wordt weer teruggesprongen naar het menu.

Ik heb ook een visueel grapje ingebouwd dat verschijnt als de controller op standby wordt gezet.