Yocto v1 MIDI-only firmware

Designer, in reactie op wat je zegt in https://www.synthforum.nl/forums/showthread.php?p=1977874#post1977874

Het kan inderdaad zijn dat mijn main loop te lang bezig is en dat de software ringbuffer volloopt. Het gekke is alleen dat de aanpak die ik nu gebruik _geen_ noten verliest in de officiële firmware. En je zou denken dat er toch veel tijd zit tussen twee MIDI bytes. 8 data bits, start bit, stop bit: 10 bits per midi byte. Met 31250 baud maakt dat 3125 midi bytes per secode, dus een nieuwe MIDI byte elke 320 microseconden. In 320 microseconden moet een main loop toch vrij veel kunnen doen?

Wat ik nu eerst ga proberen is een lampje aanzetten als er een UART error is, dan weet ik of dat überhaupt gebeurt of dat ik het probleem ergens anders moet zoeken.
 
De drums zitten achter een viertal 74HC595's. Dus het wordt bit banging of SPI. Is SPI langzamer dan?

SPI kan op 8MHz in de Yocto, dus 32 bits duurt dan 4 microseconden.
 
Je zei iets over het midi kanaal negeren om de parser sneller te maken. In mijn setup gaat dat niet werken, ik wil dat mijn Yocto op maar 1 kanaal luistert. Hij zit op een Kenton MIDI thru (dat is een splitter) met 4 andere drumbakken.

Ik moet er dus sowieso van uitgaan dat de meeste MIDI data weggegooid moet worden.
 
Natuurlijk reageert ie op 1 kanaal anders heb je niets aan de midi thru :
Interrupt checkt of het kanaal goed is, daarna sorteren in ring buffers.

Wat nu gebeurt is : alle 16 kanalen met alle commandos gaan in de ringbuffers.

Ja lampje aanzetten is slim.
Ik weet niet wat voor chip je gebruikt verder, maar het is niet goed om geen snelle interrupt te gebruiken ook al is de baud rate laag,
als je met lampjes slim plaatst kun je veel achter komen, ik weet nu al dat je het uiteindelijk op de juiste manier zal doen als je het eenmaal begrijpt.
 
Ja je hebt me wel aan het denken gezet.

De interrupt is nu supersnel (byte in de FIFO, klaar) maar zo gaat er veel data de FIFO in. Vier tot zes bytes (note on, note off) terwijl de zinvolle data in 5 bits past (4 bits om het instrument aan te wijzen, 1 bit voor accent on/off). Dus als ik dat in de interrupt al kan schiften kan dat een boel helpen.

Ga nu eerst het lampje proberen.
 
Nou dat bewijst meteen dat het geen UART error is. Ik kreeg het lampje aan door MIDI data te sturen tijdens het opstarten, dus ik weet dat het lampje werkt. Maar na normaal opstarten, tijdens het 'verslikken', gebeurt er niks met het lampje.

Terzijde, wat snelheid betreft. Ik gebruik een counter in de main loop om een pulse van 1ms op een trigger out te maken. Ik zet de counter op 160 en doe -- elke loop. Waneer ie op nul komt is de pulse afgelopen. D.m.v. de oscilloscoop weet ik dat dit een puls van 1ms maakt.

Dus de main loop duurt gemiddeld minder dan 7 microseconden.
 
Ja dat met 12 counters had ik al een keer geprobeerd maar (achteraf onterecht) weer weggehaald omdat iets niet goed werkte.

Ik denk nu dat het eigenlijk geen MIDI probleem kan zijn wat ik heb. Want de UART library zou dan een error geven, en daar heb ik nu een lampje voor. :)

Dus het moet wel een probleem zijn met de triggersignalen. Jouw suggestie van 12 counters zal helpen om de triggers strakker te krijgen. We gaan het zien.
 
Laatst gewijzigd:
Ik heb het stotteren er nu uit, het lijkt alsof het aan de trigger pulsen lag.

Omdat de main loop zo snel is heb ik de UART interrupt code er maar uit gehaald. Het duurt meer dan 300 microseconden om 1 byte te ontvangen met 31250 baud, en de main loop duurt gemiddeld 8 microseconden. Tijd genoeg om te pollen vanuit de main loop en het scheelt de overhead van de FIFO bijhouden en de interrupt handler ingaan / uitgaan.

https://gitlab.com/jacobvosmaer/yoc...4a88676364867c49867587f77cb79/midi.c#L190-212

Niet dat ik om ruimte verlegen zit, maar de binary is nu 2042 bytes groot. :)
 
Hey, het is een kleine moeite om het goed te doen,
ik begrijp dat het moeilijk is om over een drempel heen te gaan, omdat het nieuw voor je is.
Kleine moeite om even je projectje te kopieeren en met interrupt te proberen.

Trouwens je moet niet naar het gemiddelde kijken, maar naar de langste frame die mogelijk is.
 
Designer: ik denk dat we elkaar verkeerd begrijpen.

ik begrijp dat het moeilijk is om over een drempel heen te gaan
Zie meer...

Over welke drempel heb je het?

Kleine moeite om even je projectje te kopieeren en met interrupt te proberen.
Zie meer...

Het is andersom, ik heb het _met_ interrupt werkend gekregen, en daarna ook _zonder_. Waarom zou ik dan overnieuw beginnen en weer een interrupt toevoegen?

Ik begrijp helemaal wat je zegt over gemiddeldes. Het gaat om de 'worst case'. In de huidige code duurt het zelfs in de worst case minder dan 20 microseconden voordat de UART buffer opnieuw gepold wordt. Met de 31250 baud van MIDI kan ik dus nooit een UART overflow krijgen.
 
Je dient in te loggen of je te registreren om een bericht te kunnen plaatsen.

Vergelijkbare discussies

travelan
Sequencer/DAW ideeen en algemene discussie
2 3
Reacties
40
Bekeken
6K
The Untitled
The Untitled
travelan
Sequencer/DAW Development: Technische aspecten
Reacties
3
Bekeken
2K
travelan
travelan
ironfreq
Sequencer in Microsoft .NET ?
Reacties
9
Bekeken
2K
Hazes
Hazes
A
REVIEW: Yamaha 01x
Reacties
17
Bekeken
7K
gijs
gijs
Back
Top