Seite 4 von 7 ErsteErste 1234567 LetzteLetzte
Ergebnis 46 bis 60 von 97
Like Tree1Likes

Thema: für xorg1990

  1. #46
    tsseh ist offline Foren-Gott
    registriert
    19-05-2008
    Beiträge
    5.646
    Zitat Zitat von xorg1990 Beitrag anzeigen
    Wo warte ich denn?? Also wo warte ich absichtlich??
    du wartest mit dem senden, bis wieder daten angekommen sind, obwohl du sie schon losschicken könntest, wenn daten in deinem puffer sind


    Zitat Zitat von xorg1990 Beitrag anzeigen
    Da wäre ich mir nicht so sicher. Wenn man das bei einer ADC ISR macht hast du da eine Endlosschleife, weil die Wandlung bereits abgeschlossen ist wenn die ISR gefeuert wird.
    ??? was hat das mit dem adc zu tun?

    Zitat Zitat von xorg1990 Beitrag anzeigen
    Bei der usi ISR warte ich bis ein komplettes Byte übertragen wurde, da SPI immer nur bit's überträgt.
    genau dann kommt ja der interrupt, bei counter overflow, dann darauf zu warten, dass das counter overflow bit gesetzt ist macht keinen sinn.
    selbst wenn du den interrupt so konfiguriert hättest, das er nicht nur bei counter overflow kommt, wäre das warten auf counter overflow in der isr noch schlimmer

    Zitat Zitat von xorg1990 Beitrag anzeigen
    Den USI_OVF_vect feuert der ESP, da der Master ist.
    naja, sagen wir der master ist taktschläger

    Zitat Zitat von xorg1990 Beitrag anzeigen
    Und selbst wenn ich in der Haupt schleife eine Einzelmessung mache, also ISR(ADC_vect) komplett weg lasse habe ich immer noch das Problem.
    ok, dann ist das ein hardwareproblem. vielleicht nutzt der adc den timer1. wie kommst du eigentlich darauf, das die spi-übertragung betroffen ist?

    Zitat Zitat von xorg1990 Beitrag anzeigen
    ok, das while ((USISR & (1 << USIOIF)) == 0) { kann tatsächlich weggelassen werden.

    aber die LED an PB4 hat dennoch ein Eigenleben, Problem nicht behoben.
    ja, das waren auch nur die sachen die mir generell komisch vorkamen

    Zitat Zitat von xorg1990 Beitrag anzeigen
    Die ISR'S von adc und vom usi habe ich mal ausgeschalten und dafür das in die loop geschrieben:
    ... sehe ich mir später noch an

    - - - Aktualisiert - - -

    bei deinen timern stimmt mMn was nicht.
    Code:
    TCCR1 = 1 << CS10; //1<<PWM1A | 2<<COM1A0 | 1<<CS10; // PWM A, clear on match, 1:1 prescale
    ...
    TCCR0A = 3 << WGM00;                    // Fast PWM sets bits WGM00 and WGM01, which (when combined with WGM02 from TCCR0B below) enables Fast PWM mode
    TCCR0B = 1 << WGM02 | 2 << CS00;        // 1/8 prescale
    timer 0 ist doch der 8 bit timer und timer 1 der 16 bit
    damit sollte es TCCR1A und B geben und TCCR0????

  2. #47
    Avatar von xorg1990
    xorg1990 ist offline König
    registriert
    20-12-2013
    Beiträge
    851

    AW: für xorg1990

    Zitat Zitat von tsseh
    du wartest mit dem senden, bis wieder daten angekommen sind, obwohl du sie schon losschicken könntest, wenn daten in deinem puffer sind
    Naja, weil die Wlan Verbindung nicht Voll-Duplex fähig ist. Da geht immer nur eins von beiden.

    Zitat Zitat von tsseh
    ?? was hat das mit dem adc zu tun?
    War nur so erläutert.

    Zitat Zitat von tsseh
    genau dann kommt ja der interrupt, bei counter overflow, dann darauf zu warten, dass das counter overflow bit gesetzt ist macht keinen sinn.
    selbst wenn du den interrupt so konfiguriert hättest, das er nicht nur bei counter overflow kommt, wäre das warten auf counter overflow in der isr noch schlimmer
    ok.
    Zitat Zitat von tsseh
    wie kommst du eigentlich darauf, das die spi-übertragung betroffen ist?
    Ganz einfach, wenn ich statt incommingByte = USIDR; incommingByte = 0 schreib habe ich keine Probleme.

    Zitat Zitat von tsseh
    timer 0 ist doch der 8 bit timer und timer 1 der 16 bit
    damit sollte es TCCR1A und B geben und TCCR0????
    Doch das haut hin, der Attiny85 hat gar kein 16 bit Timer.
    http://www.atmel.com/images/atmel-25..._datasheet.pdf

    Wie gesagt, wenn der adc nix macht funzt alles.

    Habe ich schon erwähnt, dass wen ich den esp abschalte oder die Kabels abziehe für die SPI Verbindung auch alles seine Wege geht.

  3. #48
    tsseh ist offline Foren-Gott
    registriert
    19-05-2008
    Beiträge
    5.646

    AW: für xorg1990

    Zitat Zitat von xorg1990 Beitrag anzeigen
    Naja, weil die Wlan Verbindung nicht Voll-Duplex fähig ist. Da geht immer nur eins von beiden.
    das ist aber nichts was DU beachten musst. du übergibst deine daten an den ip-stack, der ist für den rest verantwortlich


    Zitat Zitat von xorg1990 Beitrag anzeigen
    Ganz einfach, wenn ich statt incommingByte = USIDR; incommingByte = 0 schreib habe ich keine Probleme.
    ok, dann würde ich als erstes testen ob tatsächlich werte != 0 ankommen, über ne LED die du anschaltest, wenn der 1. wert != 0 erkannt wird. das wird mit hoher wahrscheinlichkeit passieren.
    dann würde ich testen, ob es am avr oder esp liegt. einfach einen 2. avr verbinden der nichts anderes macht als 0 zu schicken.
    wenn dann das problem immer noch auftritt, hast du ein problem.

    Zitat Zitat von xorg1990 Beitrag anzeigen
    Doch das haut hin, der Attiny85 hat gar kein 16 bit Timer.
    ok

    Zitat Zitat von xorg1990 Beitrag anzeigen
    Habe ich schon erwähnt, dass wen ich den esp abschalte oder die Kabels abziehe für die SPI Verbindung auch alles seine Wege geht.
    naja, dann kommen ja auch keine werte über spi und die 0 die du einmal ausgegeben hast liegt weiter an dem gpio an

  4. #49
    Avatar von xorg1990
    xorg1990 ist offline König
    registriert
    20-12-2013
    Beiträge
    851

    AW: für xorg1990

    Zitat Zitat von tsseh
    das ist aber nichts was DU beachten musst. du übergibst deine daten an den ip-stack, der ist für den rest verantwortlich
    Wenn es doch nur so einfach wäre. Mache ich's wie von dir beschrieben, dann endet das mit einem Watchdog reset.


    Zitat Zitat von tsseh
    dann würde ich testen, ob es am avr oder esp liegt.
    Jep, denke auch das der ESP daran schuld ist.

  5. #50
    tsseh ist offline Foren-Gott
    registriert
    19-05-2008
    Beiträge
    5.646

    AW: für xorg1990

    Zitat Zitat von xorg1990 Beitrag anzeigen
    Wenn es doch nur so einfach wäre. Mache ich's wie von dir beschrieben, dann endet das mit einem Watchdog reset.
    das zeigt ja, dass der esp soviel daten nicht verarbeiten kann die du sendest.
    dann geht es zwar mit warten, aber die 100ms werden eben benötigt um die daten die der esp empfängt zu verarbeiten

  6. #51
    Avatar von xorg1990
    xorg1990 ist offline König
    registriert
    20-12-2013
    Beiträge
    851

    AW: für xorg1990

    Zitat Zitat von tsseh
    das zeigt ja, dass der esp soviel daten nicht verarbeiten kann die du sendest.
    dann geht es zwar mit warten, aber die 100ms werden eben benötigt um die daten die der esp empfängt zu verarbeiten
    Dann ist der esp aber echt lahm. Es macht auch kein Unterschied den esp mit 160 oder 80Mhz laufe zu lassen Die OFDM Modulation scheint separat in Hardware gegossen zu sein.

    Habe auch nochmal ausprobiert, wenn ich sende und empfange gleichzeitig, dann kommt gar kein onmessege event. Entweder kommt der Watchdog oder die WS Verbindung wird einfach so geschlossen.

    Beim avr habe ich das Problem gefunden es lag an dieser Zeile.
    USISR = (1 << USIOIF);
    Das ganz am ende der isr und schon geht's .... naja fast, diesmal ging der PWM output nicht nur geknarze und gerausche.

    Hab die USI ISR koplett deaktivert und alles in die While gepackt:
    Code:
    #define F_CPU 8000000UL
    #include "pins_arduino.h"
    
    
    #define bufferSize 128
    #define BUFFER_MASK (bufferSize-1)
    /*
      Pinmodes
      PB0 MOSI
      PB1 MISO
      PB2 Clock
      PB3 ADC Input
      PB4 PWM Out
    */
    static struct adc_FIFO {//ringBuffer als struct für pcm saples
      byte data[bufferSize];
      volatile byte read_ptr; // zeigt auf das Feld mit dem ältesten Inhalt
      volatile byte write_ptr; // zeigt immer auf leeres Feld
    } adc_buffer = {{}, 0, 0};
    
    static struct pcm_samples_buffer {//ringBuffer als struct für pcm saples
      byte data[bufferSize];
      volatile byte read_ptr; // zeigt auf das Feld mit dem ältesten Inhalt
      volatile byte write_ptr; // zeigt immer auf leeres Feld
    } pcm_buffer = {{}, 0, 0};
    
    void setup() {
      cli();
      // Enable 64 MHz PLL and use as source for Timer1
      PLLCSR = 1 << PCKE | 1 << PLLE;
      // Set up Timer/Counter1 for PWM output
      TIMSK = 0;                              // Timer interrupts OFF
      TCCR1 = 1 << CS10; //1<<PWM1A | 2<<COM1A0 | 1<<CS10; // PWM A, clear on match, 1:1 prescale
      GTCCR = 1 << PWM1B | 2 << COM1B0;       // PWM B, clear on match
      OCR1B = 128;               // 50% duty at start on pin PB4
      // Set up Timer/Counter0 for 44.1kHz interrupt to output samples.
      TCCR0A = 3 << WGM00;                    // Fast PWM sets bits WGM00 and WGM01, which (when combined with WGM02 from TCCR0B below) enables Fast PWM mode
      TCCR0B = 1 << WGM02 | 2 << CS00;        // 1/8 prescale
      TIMSK = 1 << OCIE0A;                    // Enable compare match
      OCR0A = 51;                            // 19kHz Fs
      //pinModes
      pinMode(0, INPUT);// initialize the MOSI Port (PIN 0)
      pinMode(1, OUTPUT);// initialize the MISO Port (PIN 1)
      pinMode(2, INPUT);// initialize the SCK Port (PIN 2)
      pinMode(4, OUTPUT);
      pinMode(3, INPUT);
    
      USICR = (1 << USIWM0) // SPI mode; Uses DO, DI, and USCK pins.
              //| (1 << USIOIE) // Enable interrupt
              | (1 << USICS1) // Clock is external postivie flanke
              | (0 << USICS0); // SPI Mode 0
    
      //ADC settings 8bit value
      ADMUX =   3 | //channel 3
                (1 << ADLAR) |     // left shift result
                (0 << REFS2) |     // Sets ref. voltage to internal 1.1V, bit 2
                (1 << REFS1) |     // Sets ref. voltage to internal 1.1V, bit 1
                (0 << REFS0) ;     // Sets ref. voltage to internal 1.1V, bit 0
    
      ADCSRA =
        (1 << ADEN)  |     // Enable ADC at 19230 Hz Samplerate
        (1 << ADSC)    | // start conversion
        (1 << ADATE)   | // free running
        (1 << ADPS2) |     // set prescaler to 8, bit 2
        (0 << ADPS1) |     // set prescaler to 8, bit 1
        (1 << ADPS0) |      // set prescaler to 8, bit 0
        (1 << ADIE); //enabel adc isr
      sei();  // enable interrupts
      /*
      ADCSRA |= (1 << ADSC);            // Start the first conversion
      while (ADCSRA & (1 << ADSC) )         // auf Abschluss der Konvertierung warten
      {
      }
      */
      /* ADCW muss einmal gelesen werden, sonst wird Ergebnis der nächsten
         Wandlung nicht übernommen. */
      (void) ADCH;
    }
    
    
    ISR(ADC_vect) { // interuppt each 38kHz
      byte adcValue = ADCH;
      byte next = ((adc_buffer.write_ptr + 1) & BUFFER_MASK);
      if (adc_buffer.read_ptr != next) {
        adc_buffer.data[adc_buffer.write_ptr] = adcValue;
        //buffer.data[buffer.write_ptr & BUFFER_MASK] = byte;
        adc_buffer.write_ptr = next;
      }
      //ADCSRA |= (1 << ADSC);        // Start the next conversion
    }
    
    
    // Sample interrupt 38khz
    ISR(TIMER0_COMPA_vect) {
      if (pcm_buffer.read_ptr != pcm_buffer.write_ptr) {
        byte sample  =  pcm_buffer.data[pcm_buffer.read_ptr];
        pcm_buffer.data[pcm_buffer.read_ptr] = 0;
        OCR1B = sample;
        pcm_buffer.read_ptr = (pcm_buffer.read_ptr + 1) & BUFFER_MASK;
      }
    }
    
    /*
    ISR(USI_OVF_vect) {
      byte incommingByte = 0;
      // Wait for complete byte to arrive
      //while ((USISR & (1 << USIOIF)) == 0) {
     // }
      incommingByte = USIDR;
      byte next = ((pcm_buffer.write_ptr + 1) & BUFFER_MASK);
      if (pcm_buffer.read_ptr != next) {
        pcm_buffer.data[pcm_buffer.write_ptr] = incommingByte;
        pcm_buffer.write_ptr = next;
      } else {
        pcm_buffer.data[pcm_buffer.write_ptr] = 0;
      }
        
      if (adc_buffer.read_ptr !=   adc_buffer.write_ptr) {
        byte adcValue =  adc_buffer.data[adc_buffer.read_ptr];
        adc_buffer.data[adc_buffer.read_ptr] = 0;
        USIDR = adcValue; // Put data in USI data register.
        adc_buffer.read_ptr = (adc_buffer.read_ptr + 1) & BUFFER_MASK;
      } else {
        USIDR = 0;// Put data in USI data register.
      }
    
      // Clear counter overflow flag so next byte can begin arriving
      // While we're processing this one
      USISR = (1 << USIOIF);
      
    }
    */
    
    void loop() {
      byte incommingByte = 0;
      // Wait for complete byte to arrive
      while ((USISR & (1 << USIOIF)) == 0) {}
      
      incommingByte = USIDR;
      byte next = ((pcm_buffer.write_ptr + 1) & BUFFER_MASK);
      if (pcm_buffer.read_ptr != next) {
        pcm_buffer.data[pcm_buffer.write_ptr] = incommingByte;
        pcm_buffer.write_ptr = next;
      } else {
        pcm_buffer.data[pcm_buffer.write_ptr] = 0;
      }
        
      if (adc_buffer.read_ptr !=   adc_buffer.write_ptr) {
        byte adcValue =  adc_buffer.data[adc_buffer.read_ptr];
        adc_buffer.data[adc_buffer.read_ptr] = 0;
        USIDR = adcValue; // Put data in USI data register.
        adc_buffer.read_ptr = (adc_buffer.read_ptr + 1) & BUFFER_MASK;
      } else {
        USIDR = 0;// Put data in USI data register.
      }
    
      // Clear counter overflow flag so next byte can begin arriving
      // While we're processing this one
      USISR = (1 << USIOIF);
      
    }
    Funzt.

    Was ich noch nicht weiß ober der adc auch funktioniert. Muss erst mal ein Licht Empfänger basteln.

    Auch herausgefunden habe ich, das ich diese isr gar nicht benötige und den dazugehörigen Puffer auch nicht :
    Code:
    // Sample interrupt 38khz
    ISR(TIMER0_COMPA_vect) {
      if (pcm_buffer.read_ptr != pcm_buffer.write_ptr) {
        byte sample  =  pcm_buffer.data[pcm_buffer.read_ptr];
        pcm_buffer.data[pcm_buffer.read_ptr] = 0;
        OCR1B = sample;
        pcm_buffer.read_ptr = (pcm_buffer.read_ptr + 1) & BUFFER_MASK;
      }
    }
    Ich kann direkt OCR1B = USIDR schreiben.

    Aber, Frage:
    Was hältst du von der Pufferung, ist es besser eine zu haben oder kann ich die auch komplett weglassen?
    Dann kann man den Attiny45 satt 85 nehmen ist zwar Pfennig kram aber immerhin.

  7. #52
    tsseh ist offline Foren-Gott
    registriert
    19-05-2008
    Beiträge
    5.646

    AW: für xorg1990

    Zitat Zitat von xorg1990 Beitrag anzeigen
    Habe auch nochmal ausprobiert, wenn ich sende und empfange gleichzeitig, dann kommt gar kein onmessege event. Entweder kommt der Watchdog oder die WS Verbindung wird einfach so geschlossen.
    dann hast du vermutlich noch ein anderes problem

    Zitat Zitat von xorg1990 Beitrag anzeigen
    Beim avr habe ich das Problem gefunden es lag an dieser Zeile.
    USISR = (1 << USIOIF);
    ja, das ist falsch, auch am ende. das statusregister zu schreiben ist keine gute idee

    Zitat Zitat von xorg1990 Beitrag anzeigen
    Hab die USI ISR koplett deaktivert und alles in die While gepackt:
    keine gute idee, wenn es einen int gibt, sollte man den auch nutzen

    Zitat Zitat von xorg1990 Beitrag anzeigen
    Auch herausgefunden habe ich, das ich diese isr gar nicht benötige und den dazugehörigen Puffer auch nicht :
    der isr sorgt doch aber für einen 38khz takt, ohne taktest du ja immer wenn ein wert über spi angekommen ist.
    wenn das mit fester taktrate passiert und die frequenz passt, kannst du darauf verzichten

  8. #53
    Avatar von xorg1990
    xorg1990 ist offline König
    registriert
    20-12-2013
    Beiträge
    851

    AW: für xorg1990

    Zitat Zitat von tsseh
    dann hast du vermutlich noch ein anderes problem
    Dann weiß ich aber auch nicht an was es liegen soll. Es gäbe noch die Möglichkeit der Datenkompression aber ob der ESP das schafft ? Ich würde mich da auf adpcm beschränken. mp3, vorbis etc, ist alles zu kompliziert.

    Zitat Zitat von tsseh
    ja, das ist falsch, auch am ende. das statusregister zu schreiben ist keine gute idee
    Wie jetzt ich soll die Zeile komplett weglassen??

    Zitat Zitat von tsseh
    wenn es einen int gibt, sollte man den auch nutzen
    was meinst du mit int?? Integer? Erläutere das mal genauer?

    Zitat Zitat von tsseh
    wenn das mit fester Taktrate passiert und die Frequenz passt, kannst du darauf verzichten
    Ja, das ist synchron. Manchmal ist es aber besser eine kleine Puffer zu haben, im falle die SPI Übertragung hat mal kleinere Aussetzer.

  9. #54
    tsseh ist offline Foren-Gott
    registriert
    19-05-2008
    Beiträge
    5.646

    AW: für xorg1990

    Zitat Zitat von xorg1990 Beitrag anzeigen
    Dann weiß ich aber auch nicht an was es liegen soll.
    irgendwas musst du ja machen auf dem esp was die zeit frisst. wenn du daten zum esp sendest, empfängt dieser die. das was du dann (mit den daten?) machst, dauert so lange, daß du nicht mal mehr zum antworten kommst ehe die nächsten daten eintreffen

    Zitat Zitat von xorg1990 Beitrag anzeigen
    Wie jetzt ich soll die Zeile komplett weglassen??
    ja, wozu soll die gut sein? das flag setzt der esp wenn ein byte angekommen ist, nicht du. maximal musst du sowas zurücksetzten

    Zitat Zitat von xorg1990 Beitrag anzeigen
    was meinst du mit int?? Integer? Erläutere das mal genauer?
    interrupt

    Zitat Zitat von xorg1990 Beitrag anzeigen
    Ja, das ist synchron. Manchmal ist es aber besser eine kleine Puffer zu haben, im falle die SPI Übertragung hat mal kleinere Aussetzer.
    entweder ist es synchron oder hat aussetzer. die frage ist kannst du mit den aussetzern leben und musst du das überhaupt.
    ohne puffer spaarst du diesen,m waren aber auch nur 128 byte, außerden sparrst du laufzeit. beides sollte eigentlich ausreichend zur verfügung stehen, also müsstest du nicht damit leben.

  10. #55
    tsseh ist offline Foren-Gott
    registriert
    19-05-2008
    Beiträge
    5.646

    AW: für xorg1990

    Zitat Zitat von tsseh Beitrag anzeigen
    ja, wozu soll die gut sein? das flag setzt der esp wenn ein byte angekommen ist, nicht du. maximal musst du sowas zurücksetzten
    du hast recht, das ist das zürücksetzen
    The flag will only be cleared if a one is written to the USIOIF bit.
    dann ist am ende nicht falsch, jede andere stelle aber auch nicht, da spi kein clock stretching unterstützt

  11. #56
    Avatar von xorg1990
    xorg1990 ist offline König
    registriert
    20-12-2013
    Beiträge
    851

    AW: für xorg1990

    Zitat Zitat von tsseh
    irgendwas musst du ja machen auf dem esp was die zeit frisst.
    Habe alle möglichen Sachen ausprobiert an mir liegt es nicht. Selbst wenn der esp nur eine Puffer empfängt und exakt diesen wieder sendet wird es nicht besser. Entweder liegt es an der websocket klasse oder an der Wlan Modulation.
    Wenn du mal Zeit hast kannst du dir mal diese Playlist ansehen: https://www.youtube.com/watch?v=Vhgk...Vhh_eZALqmLCQh

    Dan hast du einen Überblick wie aufwendig das zu Programmieren ist.

    Zitat Zitat von tsseh
    entweder ist es synchron oder hat aussetzer. die frage ist kannst du mit den aussetzern leben und musst du das überhaupt.
    Ausprobieren.

    Zitat Zitat von tsseh
    dann ist am ende nicht falsch, jede andere stelle aber auch nicht, da spi kein clock stretching unterstützt
    Also mit der usi isr wird es überhaupt nix, da dreht die LED durch wenn eine ADC Wandlung im Gange ist. Bzw die SPI Übertagung produziert Unsinn . Es klappt nur mit der von mir zuletzt geposteten Lösung in der while. Stange

  12. #57
    tsseh ist offline Foren-Gott
    registriert
    19-05-2008
    Beiträge
    5.646

    AW: für xorg1990

    ich hab das jetzt mal selbst ausprobiert websocket zum esp.
    das sind meine zeiten:ws.png
    ich schicke immer 100 byte zum esp und der sendet sie zurück. die zeiten sind immer von vor dem senden bis zum empfang der daten die zurückgeschickt wurden.
    100 byte habe ich genommen, weil das websocket-protokoll ab 126 byte payload etwas komplizierter wird und die arbeit wollte ich mir spaaren, aber das sollte als anhaltspunkt schon mal reichen.

  13. #58
    Avatar von xorg1990
    xorg1990 ist offline König
    registriert
    20-12-2013
    Beiträge
    851

    AW: für xorg1990

    Sry das ich jetzt erst antworte, brauchte mal 'ne Pause.

    Die Zeiten sehn gut aus.

    Zitat Zitat von tsseh
    websocket-protokoll ab 126 byte payload etwas komplizierter wird
    Warum?


    Bei avr habe ich noch festgestellt, dass die Adc Wandlung nur gut funktioniert wenn man ein Prescalar von 16 wählt. Ist man schneller oder langsamer versteht man keine Sprache mehr.

    Problem, ein Prescalar von 16 entspricht ~38khz Sample rate, das ist zu viel für den ESP. Ich lasse die SPI Übertragung einfach um die Hälfte langsamer laufen, dann wird zwar jeder 2te adc Wert übersprungen... aber sei's drum, geht.

  14. #59
    tsseh ist offline Foren-Gott
    registriert
    19-05-2008
    Beiträge
    5.646

    AW: für xorg1990

    Zitat Zitat von xorg1990 Beitrag anzeigen
    Warum?
    weil die nutzdatenlängen bei 126 im nächsten word steht und bei 127 im nächsten dword
    https://tools.ietf.org/html/rfc6455#section-5.2

    Zitat Zitat von xorg1990 Beitrag anzeigen
    Problem, ein Prescalar von 16 entspricht ~38khz Sample rate, das ist zu viel für den ESP. Ich lasse die SPI Übertragung einfach um die Hälfte langsamer laufen, dann wird zwar jeder 2te adc Wert übersprungen... aber sei's drum, geht.
    das ist doch aber kein problem. deine sample rate wird doch sowieso durch die SPI-taktung bzw. deinen timer(den du glaube ich nicht mehr verwendest) festgelegt. du hattest doch 8khz sample rate. dann musst du einfach in diesem takt diene werte wandeln. das ist doch sogar besser als wenn du dicht an die 38khz des adc rankommen würdest.

  15. #60
    Avatar von xorg1990
    xorg1990 ist offline König
    registriert
    20-12-2013
    Beiträge
    851

    AW: für xorg1990

    Zitat Zitat von tsseh
    weil die nutzdatenlängen bei 126 im nächsten word steht und bei 127 im nächsten dword
    Und das soll sich auf die Übertragungsgeschwindigkeit auswirken?
    Zitat Zitat von tsseh
    dann musst du einfach in diesem takt diene werte wandeln.
    Naja so einfach ist es dann doch nicht. Ich hatte mir ein attiny gebastelt der einen ADC Wert direkt wider als PWM ausgibt. Nur um erst mal grundsätzlich zu klären ob sich der Attiny überhaupt als Soundkarten(besser ADC) Ersatz eignet, für Audio.

    Und dabei bin ich dahinter gekommen das die Audioqualität dann am besten ist, wenn der Prescaler auf 16 steht einspricht ~38Khz, wird die Wandlung schneller rauscht es, ist es langsamer sind die Frequenzen verschoben . Ist der Prescaler auf 128(das langsamste) geht gar nix los.


    Habe man eine frage zum Timer auf dem ESP. Timer0 und Timer1 sind Hardware Timer?

    Wie bewege ich Timer 1 dazu alle 51microsec einen Interrupt zu feuern?

    Timer 0 geht so.
    timer0_write(ESP.getCycleCount() + interval_us * 80); // 160 when running at 160mhz

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •