Svenska ElektronikForumet

Snyggt jobbat! Anledningen till att jag körde på 12-bits dac istället för PWM var att den hade inbyggd opamp på utgången, så att man fick en bra lösning från början. En fråga, vad kör du med för midiprogram?

Cakewalk Sonar 5 är midiprogrammet

Upptäckte en liten skum grej nu när jag hållt på att mekat med filtret, allt ljud skars av vid 8kHz.
Efter lite felsökande upptäckte jag att en bugg i i2s koden (jag försökte dela ner klockan som är på 16MHz till något större än 8MHz)
gjorde att samplingsfrekvensen till DACen hamnade på 16KHz.
Detta är åtgärdat nu så samplingsfrekvensen är nu 16MHz/256 => 62.5kHz.

Kan meddela att detta gjorde att ljudkvaliteten steg ganska nämnbart (vilket kanske inte är så konstigt )

Stekern, jag fick igång midi-kommunikationen häromdagen. Det blev Ken Chapmans uart (den som finns i picoblaze) till slut som jag använde. Den vill ha en 16xbaud_rate pulse rate för att takta bitarna. Eftersom jag skickar vidare data för felsökning ut på USB-uarten (115200 baud) har jag använt en DCM för att tripla 16MHz klockan till 48MHz för att klockningen av uarten ska funka fint. Med 48MHz fick jag 0% klockfel för midi-uarten (31250 baud) och 0.16% klockfel för usb-uarten (115200 baud). Vid 16MHz skulle jag fått -3.5% klockfel vid 115200 baud.

Är det någon som vet om värdet 0xFE som skickas titt som tätt över midi-interfacet har någon annan funktion än att visa att kommunikationslänken funkar?

Stekern:
"Kan meddela att detta gjorde att ljudkvaliteten steg ganska nämnbart"

Den klockökningen borde ha gjort lika stor nytta som tops, kan jag tänka mig...

Minns inte om någon har frågat tidigare, men är det här projektet något som du skulle kunna tänka dig att sälja byggsatser av när det är klart?
Det vore förresten kul att se någon form av blockschema på hård/mjukvaran såhär långt.

JA! Byggsatser vore ju gött!
Det ser så jäkla kul ut det här.
Synd att man inte kan koda själv.

JimmyAndersson skrev: Minns inte om någon har frågat tidigare, men är det här projektet något som du skulle kunna tänka dig att sälja byggsatser av när det är klart?
Det vore förresten kul att se någon form av blockschema på hård/mjukvaran såhär långt.

Visst skulle jag tänka mig att sälja de som byggsatser, men som sagt innan så är det baserat på avnets dev-bräda så det behöver man också. Om intresset är väldigt stort kan jag tänka mig att meka fullständiga kort som inte är beroende av dev-brädan.
Som jag också nämnt innan så har jag planer på att göra en "poor-mans" version som är tänkt att fungera med väldigt få kringkomponenter till dev-brädan, det var väl en hel del här på forumet som var med och samköpte de

Ska knåpa ihop nåra blockscheman, men just nu har ett annat projekt kommit ivägen som stjäl tid (inte lika roligt projekt, men ett sånt som man får betalt för). Så snart det är avslutat så kommer jag fortsätta med synthen.

Andax skrev:Stekern, jag fick igång midi-kommunikationen häromdagen. Det blev Ken Chapmans uart (den som finns i picoblaze) till slut som jag använde. Den vill ha en 16xbaud_rate pulse rate för att takta bitarna. Eftersom jag skickar vidare data för felsökning ut på USB-uarten (115200 baud) har jag använt en DCM för att tripla 16MHz klockan till 48MHz för att klockningen av uarten ska funka fint. Med 48MHz fick jag 0% klockfel för midi-uarten (31250 baud) och 0.16% klockfel för usb-uarten (115200 baud). Vid 16MHz skulle jag fått -3.5% klockfel vid 115200 baud.

Du kör alltså "extern" midi-port du med? Jag funderar på att använda usb-uarten till att skicka midi-datan med i "poor-mans" versionen.
Berätta mer om DCMen, en hel del grejer i synthen skulle må bra av upptrimmad klocka.

Andax skrev: Är det någon som vet om värdet 0xFE som skickas titt som tätt över midi-interfacet har någon annan funktion än att visa att kommunikationslänken funkar?

http://www.midi.org/techspecs/midimessages.php berättar

Active Sensing. Use of this message is optional. When initially sent, the receiver will expect to receive another Active Sensing message each 300ms (max), or it will be assume that the connection has been terminated. At termination, the receiver will turn off all voices and return to normal (non- active sensing) operation.

http://www.xilinx.com/support/documenta ... /ug331.pdf sidan 61 bekriver DCM (Digital Clock Managers). I korthet: evalkortets fpga har 4 st DCM. De kan användas för att multiplicera och dividera en klocka och på så vis skapa en annan klocka. Den kan också användas för att skapa en fasförkjuten klocka.
Har du använt Xilinx Core Generator något? Jag använde den för att skapa en instans av en DCM som tripplade en klocka. Det är kanska enkelt om man hittar runt i Core Generator. Jag kör med ISE Foundation och inte ISE Webpack, så jag vet inte om det är någon skillnad där.

Tack för länken ska kolla närmare på det där.
Core generatorn har jag tittat på, men inte använt.
Helst undviker jag att använda den så långt som möjligt eftersom en del av det här projektets syfte är att väcka upp
och hålla vid liv vad som var mina något slumrande vhdl-kunskaper (var en 5 år sen jag pillade vhdl/fpgas innan jag satte igång detta).

Man behöver inte använda Core Generator för att använda DCMer etc, det går att instansiera direkt. En mycket användbar sak i ISE är "Language Templates". Tryck på knappen som ser ut som en glödlampa uppe i toolbar (Om du har Language Template bar aktiverad) eller i Edit-menyn.
Där finns små kod-snippets hur man instantierar diverse saker. T.ex det du söker finns där under "VHDL/Device Primitive Instantiation/FPGA/Clock Components/Digital Clock Manager (DCM)".

Hoppas detta projekt blir open source - som sagt, vore kul att köra detta på mina MiniMig-kort...

Det ÄR open source, GPL-v3 för att vara exakt.

I första inlägget finns länk till svn repositoryt, men här kommer den igen:
http://www.sk-electronics.com/svn/repos/SK-Synth/trunk/
och här finns en websvn till den:
http://www.sk-electronics.com/websvn/li ... 2Ftrunk%2F

Här är ett blockschema så som den är uppbyggd för tillfället.


Ett problem är att filtret är kopplat efter att voiceserna är mixade, detta gör att filter envelopes inte är möjligt. Detta kommer givetvis åtgärdas framöver.

Har inte följt det här projektet så noga, men jag ville bara säga snyggt jobbat! Och kul att se lite FPGA-baserade projekt på forumet, alldeles för lite sånt...

Senast jag fick lite tid över att titta på min midi-controller så såg jag lite konstigheter (som kanske inte är konstigheter) i mididata. Jag skickar vidare midi-infon till USB-uarten för debugging. Vad jag såg var att det kunde komma flera tangentnedtryckningar i samma meddelande, dvs det kom i stil med (i hex) "90 38 50 2E 40" istället som jag hade förväntat mig "90 38 22 90 2E 22". Är detta standard?

Stekern, om jag tolkat din midi-kod rätt hanterar den inte denna typ av kompakt mididata. Följer deb kompakta versionen standarden till 100%?

Såg även att "B0 xx xx xx xx xx xx" var längre och innehöll fler settings i följd än vad jag förväntat mig.