eigen tb 303 kloon
- Thread starter Natural_Demon
- Start date
Twiki
Stamgast
Als bij encoder A, a en b hoog zijn. hoe detecteer je dan dat de toestand van 1 van de andere encoders verandert. De diodes vormen een of poort. Of mis ik iets.
De 74hc165 moet je de seriele data ook uit locken en de parallele data inclocken daar moeten dus nog meer lijntjes heen.
Bij lcd's is het fijn als je zo ook uit kan lezen dan kun je kijken of de lcd bezig voordat je data heenschrijft, das wel handig want die dingen zijn traag.
Wat betreft de stelling een pic is beter voor midi zou ik wel graag beargumenteerd zien, daar geloof ik namelijk niks van.
De 74hc165 moet je de seriele data ook uit locken en de parallele data inclocken daar moeten dus nog meer lijntjes heen.
Bij lcd's is het fijn als je zo ook uit kan lezen dan kun je kijken of de lcd bezig voordat je data heenschrijft, das wel handig want die dingen zijn traag.
Wat betreft de stelling een pic is beter voor midi zou ik wel graag beargumenteerd zien, daar geloof ik namelijk niks van.
Boemtsjak
tsjinge tsjinge boemtsjak
Inderdaad.
Dat is het nadeel van deze opzet: je kan maar één encoder tegelijk tweaken... Meerdere encoders op de interrupt pinnen van een AVR zetten gaat gewoon niet lukken. En dan blijft het softwarematig periodiek scannen van de encoders waarschijnlijk de meest eenvoudige oplossing. Net zoals ze bij Uucaps dus doen met die 74hc165's.
Boemtsjak
tsjinge tsjinge boemtsjak
Volgens mij ging dat verhaal oorspronkelijk niet zozeer over de PIC, maar eerder over de softwarematige UART (dat kan je met een AVR natuurlijk ook doen). Een hardware UART wacht op het stopbit en geeft daarna een interrupt. Bij een softwarematige UART hoef je niet op het stopbit te wachten, maar kun je meteen na de databits in aktie komen. Het scheelt 32 microseconden, als ik het goed heb berekend. Niet echt getallen om over wakker te liggen. Maar wel handig om als reclamemiddel te gebruiken, zoals bijvoorbeeld Synhouse doet: the note sounds while the MIDI message is still in the cable! T'is ongelooflijk Mike!
Wat je hoogstends zou kunnen doen als software UART is een constructie bedenken met een interrupt lijn op een externe pin, en een timer die ook een interrupt lijn heeft. (als die PIC beide heeft, lijkt me wel). De interrupt lijn op de externe pin moet configureerbaar zijn dat hij enkel reageert op een opgaande of neergaande flank. Je hebt een irq op neergaande flank nodig. Kan je PIC dat niet, biedt dan het MIDI signaal aan met een extra inverter bij wijze van spreken.
MIDI is 31250 baud, 32e-6 voor een enkele bit.
Je weet dat het startbit altijd een transitie is van hoog naar laag.
* Zet een interrupt (INT A) op die lijn, die reageert op neergaande flanken.
* Krijg je een interrupt binnen, zet die interrupt lijn vervolgens direkt uit, wacht 16e-6 seconden, maar start direkt na die 16e-6 seconden een timer die ook een interruptlijn heeft (INT T) die dan om de 32e-6 (**) een interrupt geeft. Zo precies timen is gewoon een kwestie van instructiecycles tellen vanuit de datasheet en dat kan best precies gaan. Zeker als je een kristal hebt van bv. een factor van de rekenrij 4, 8, 16, 32, ...
* Zet op die timer irq lijn een ISV die dan 9x (een MIDI frame is 10 bit dwz, startbit heb je al, 8 databits + stopbit nog te samplen) samplet. Barrelshift de sample naar links in een registertje ofzo. Op de 9e keer zet je de timer irq uit, verwerk je de ontvangen byte, en zet je INT A weer aan. Dan kan zo de volgende byte binnengeslorpt worden.
(**): 32e-6 is mischien nog te lang. Als je het echt precies wil doen, bepaal dan het aantal instructies dat het kost om de timer ISV aan te roepen, en de bit te samplen, en trek deze tijd van deze 32-e6 af, en reset dan stiekum even de timer om zo toch de 32e-6 te halen!
Zo sample je dus het exacte midden van een bit in de seriele datastroom, min of meer.
In de tussentijd kan je hoofdlus gewoon dingen doen die deze moet doen.
Met dezelfde truuk kan je natuurlijk ook verzenden.
Wat PIC versus Atmel betreft: je moet kijken in hoeverre je rekenkracht nodig hebt.
Afgezien van samples aanvragen: PIC's zijn belachelijk goedkoop, maar het aantal MIP's/Mhz is aanzienlijk lager dan die van een Atmel. Dwz, een Atmel is krachtiger.
MIDI is 31250 baud, 32e-6 voor een enkele bit.
Je weet dat het startbit altijd een transitie is van hoog naar laag.
* Zet een interrupt (INT A) op die lijn, die reageert op neergaande flanken.
* Krijg je een interrupt binnen, zet die interrupt lijn vervolgens direkt uit, wacht 16e-6 seconden, maar start direkt na die 16e-6 seconden een timer die ook een interruptlijn heeft (INT T) die dan om de 32e-6 (**) een interrupt geeft. Zo precies timen is gewoon een kwestie van instructiecycles tellen vanuit de datasheet en dat kan best precies gaan. Zeker als je een kristal hebt van bv. een factor van de rekenrij 4, 8, 16, 32, ...
* Zet op die timer irq lijn een ISV die dan 9x (een MIDI frame is 10 bit dwz, startbit heb je al, 8 databits + stopbit nog te samplen) samplet. Barrelshift de sample naar links in een registertje ofzo. Op de 9e keer zet je de timer irq uit, verwerk je de ontvangen byte, en zet je INT A weer aan. Dan kan zo de volgende byte binnengeslorpt worden.
(**): 32e-6 is mischien nog te lang. Als je het echt precies wil doen, bepaal dan het aantal instructies dat het kost om de timer ISV aan te roepen, en de bit te samplen, en trek deze tijd van deze 32-e6 af, en reset dan stiekum even de timer om zo toch de 32e-6 te halen!
Zo sample je dus het exacte midden van een bit in de seriele datastroom, min of meer.
In de tussentijd kan je hoofdlus gewoon dingen doen die deze moet doen.
Met dezelfde truuk kan je natuurlijk ook verzenden.
Wat PIC versus Atmel betreft: je moet kijken in hoeverre je rekenkracht nodig hebt.
Afgezien van samples aanvragen: PIC's zijn belachelijk goedkoop, maar het aantal MIP's/Mhz is aanzienlijk lager dan die van een Atmel. Dwz, een Atmel is krachtiger.
Twiki
Stamgast
Maar als je dan een flinke zwengel aan een encoder geeft is het onmogelijk om te achterhalen of je nou linksom of rechtsom draait. Daarom zei ik dus vergeet de encoders die kosten relatief veel tijd om goed uit te lezen.
Het eerder kunnen verwerken van je midi data bij een software uart levert naar mijn idee heel erg weinig voordeel op ten op zichte van de processortijd die je over hebt bij een hardware uart. Je hebt minimaal 300us de tijd om iets met de controller te doen tov 32us, bovendien kun je niks doen met interrupts en geen functies uitvoeren tijdens het ontvangen die niet een vast aantal instructies hebben.
@chromisx je beschrijft nu een standaard software uart zo uit het boekje.....
De reden dat ik gekozen heb voor Atmel zit niet alleen in het aantal MIPS. Ik vind de datasheets duiidelijker en de instructieset lijkt bijna een hogere programmeertaal tov de pic. Ook hoef ik voor ieder project niet lang te kijken naar welke controller ik nodig heb, er zijn inmiddels naar mijn idee teveel varianten van de pic, daar raak ik echt geen wijs meer uit. Die paar euro prijsverschil vind ik het wel waard, het kost me veel minder tijd om iets te ontwikkelen.
Natural_Demon
Stamgast
ik zal het eens uitzoeken.twiki schreef:
zoals ik al zei, ik ken tot nu toe alleen de instructies van de pic.
de meeste scemea die ik bezit van doe het zelfer hebben een pic.
ik ben aan het bieden op "PIC18LF4539".
mijn oplossing voor de encoders denk ik is ...
via de ic weet ik dus welke encoder bewogen wordt.
daarna kijken wie van a of b de eerste pulse geeft.
eerst A?
daarna gewoon de waarde in de file verhogen/verlagen op elke puls verkregen door A.
naar mijn mening zullen er dus nog kleine condensators ingebouwd moeten worden.
om een vertraging/verlenging te krijgen tegenover het verkregen signaal op de ic.
hmm, intressante disxussie hebben jullie daar.
heeft iemand van jullie source cde voor een pic, zodat ik het eens bestuderen kan.
groetjes
Natural_Demon
Stamgast
jammer, geen deal kunnen sluiten met die jongen van www.ultra303.de
grrrr
ik dacht, misschien toch nog een sequencer.
grrrr
ik dacht, misschien toch nog een sequencer.
Vergelijkbare discussies
- Gesloten
