für xorg1990

[tsseh]

Das macht doch die SPI Klasse, wie die das macht ist mir Wurst.

sollte es aber nicht

https://github.com/esp8266/Arduino/blob/master/libraries/SPI/SPI.cpp#L196

dann ist das doch keine bit banging implementierung sondern die übertragung macht die hardware, damit sollten die 2µs "eigentlich" kein problem sein

Weiß ich, erklärt aber nicht warum dort durch 16 Teilt.

alle 16 cycles zählt der counter 1 weiter
wenn du wissen willst wieviel cycles er zählen muss um alle x µs einen Int auszulösen musst du cycles pro µs / 16 * x rechnen

In einem github Projekt stand geschrieben, dass die 320kBit/s wifi Bandbreite nur gehen wenn der esp mit 160Mhz getaktet ist. hast du das Quellen für??

quellen für was? du meinst die sdk c-files? nee. das ist nur ne lib, da bekommst du nur den compelierten asm-code raus

Das Verzögerungs Problem im WLAN beim senden/empfangen ist auch kein Einzelfall.

nochmal. ich hab das getestet und es geht im schnitt grob geschätzt mit ca. 10 ms im mittel für 100 byte hin und wieder zurück, das sollte doch reichen.

Mir kommt es eher so vor, als ob das Modul in einem 100ms Raster arbeitet.

dass das in irgendeinem raster arbeitet würde ich auch erwarten, aber keine 100ms, die es auch nicht sein können, weil in meinem test sonst immer mindestens 200ms rauskommen müssten.

- - - Aktualisiert - - -

das ist nur ne lib, da bekommst du nur den compelierten asm-code raus

hier
https://github.com/ernacktob/esp8266_wifi_raw/blob/master/disas/callstack#L23
hat sich mal jemand damit beschäftigt

 

[xorg1990]

sollte es aber nicht

Naja, wie SPi Funktioniert und das es in Hardware basiert und nicht via BitBanging, das habe ich mir schon angehen.

dann ist das doch keine bit banging

Habe ich das gesagt. Habe mir doch damals extra die ESP-03 Module geholt.

quellen für was?

Das die Wlan Übertagung mit 160Mhz schneller geht als mit 80Mhz.

 

[tsseh]

Habe ich das gesagt. Habe mir doch damals extra die ESP-03 Module geholt.

weiss ich nicht mehr, dachte immer du hattest eine sw-lösung

Das die Wlan Übertagung mit 160Mhz schneller geht als mit 80Mhz.

dafür würde ich keinen grund sehen, kann sein dass du die schneller mit daten versorgt bekommst, da dein code dann ja doppelt soviel zeit hat um abgearbeitet zu werden und damit mehr zeit übrig bleibt für tcp ip die übertragung selbst sollte davon nicht betroffen sein.

 

[xorg1990]

weiss ich nicht mehr, dachte immer du hattest eine sw-lösung

Nee, hatte doch extra den ESP-03 geholt, da einzige was wir nicht wussten was mit den Flash Speicher passiert wenn man eine SPI Übertagung zum avr startet. Das Ergebnis ist nix.

dafür würde ich keinen grund sehen,

Ích ebenfalls nicht, das einzeige was ich gestern herausgefunden habe ist, das das Übertragungs delay bei 80Mhz größer ist als als bei 160Mhz.

2Dinge kapiere ich dennoch nicht.
Ding 1:
Ich höre am AVR, also an der PWM Ausgabe was der ESP macht, z.b Wenn ich das WLAN verbinde oder wen ich die Webseite aus dem Flash Spiecher lade. Da hört man dann so digitales gedöns. Nicht weiter störend aber warum eigentlich?

Ding2:
Die SPI Übertragung ist ja Synchroton sprich wenn ich ein byte sende Empfang ich im Gegenzug eins. Das betrift auch die Zeiten, wenn ich mit 1Mhz sende kommt auch ein byte alle 1Mhz.

Da passt bei mir aber nicht. Wenn ich Daten vom AVR empfangen möchte, dann muss ich mit 1Mhz arbeiten. Möchte ich Daten zum AVR senden dann nur 1/4 weniger oder mehr. Habe eine SPI Frequenz Umschaltung aufgebaut aber sinn und zweck ist das auch nicht.


Aktuell klinkt die Ausgabe gut, im Browser jittert es ab und zu mal, habe den esp aber auch zu 100% ausgereizt:
kannst du dir hier downloaden und anhören:
https://1drv.ms/u/s!AlZ7IuvCJ0zWkleNpdc7lOZq2jti

Die PWM Aufnahme Pfeift etwas, liegt an der Aufnahme, normal hört man das nicht.

 

[tsseh]

war ne weile nicht da

da einzige was wir nicht wussten was mit den Flash Speicher passiert wenn man eine SPI Übertagung zum avr startet. Das Ergebnis ist nix.

doch, das wussten wir/ich der esp hat 2 spi schnittstellen, an einem hängt der flash, den anderen nutzt du

Da passt bei mir aber nicht. Wenn ich Daten vom AVR empfangen möchte, dann muss ich mit 1Mhz arbeiten. Möchte ich Daten zum AVR senden dann nur 1/4 weniger oder mehr.

klingt komisch

 

[xorg1990]

war ne weile nicht da

Mach nüscht, bin auch oft auf Montage oder manchmal auch im Urlaub

doch, das wussten wir/ich der esp hat 2 spi schnittstellen, an einem hängt der flash, den anderen nutzt du

Ok.

klingt komisch

Das verhalten ist nur wenn man des ESP mit 160Mhz taktet.

Aktuell bin ich mit der Übertragung zu frieden mal davon abgesehen, dass das Gegensprechen nicht funktioniert. Die Qualität der Ausgabe ist aber ok, sowohl die PWM als auch das was im Browser ankommt.

Eine Sache habe ich doch noch, ich brauche eine Umschaltung der Referenzspannung beim AVR ADC.

Kann ich in das ADMUX Register schreiben wärend der ADC Im FreeRunning mode läuft?
Müsste von VCC Refs zu 1.1V Intern Refs umschalten.

 

[tsseh]

Eine Sache habe ich doch noch, ich brauche eine Umschaltung der Referenzspannung beim AVR ADC.

warum das denn?

Kann ich in das ADMUX Register schreiben wärend der ADC Im FreeRunning mode läuft?

naja, du wirst dann den aktuell gemessenen wert (der nächste der fertig wird) nicht gebrauchen können.

- - - Aktualisiert - - -

ADC Voltage Reference
The voltage reference for the ADC (VREF) indicates the conversion range for the ADC. Single ended channels that
exceed VREF will result in codes close to 0x3FF. VREF can be selected as either VCC, or internal 1.1V / 2.56V voltage
reference, or external AREF pin. The first ADC conversion result after switching voltage reference source may
be inaccurate, and the user is advised to discard this result.

 

[xorg1990]

warum das denn?

Naja,wenn die Foto-Diode nicht mehr genug Leistung bringt (Z.B wenn es neblig wird), kann man die Referenzspannung reduzieren und das empfangen Signal sollte wider lauter werden.

naja, du wirst dann den aktuell gemessenen wert (der nächste der fertig wird) nicht gebrauchen können.

Denke das kann man verschmerzen.

 

[xorg1990]

Hi tsseh, das umschalten der Referenzspannung klappt doch nicht so ohne weiteres.
Ändert man nur das ADMUX Register, bleibt der ADC Stehen.

Habe es so gelöst:

void toggleVref(void) {
  cli();
   ADCSRA = (0 << ADEN);
  if (isLowRefVoltage == false) {
    ADMUX =   3 | //channel 3
              (1 << ADLAR) |     // left shift result
              (0 << REFS2) |     // Sets ref. voltage to internal 1.1V, bit 1
              (1 << REFS1) |     // Sets ref. voltage to internal 1.1V, bit 2
              (0 << REFS0) ;     // Sets ref. voltage to internal 1.1V, bit 1
    isLowRefVoltage = true;
  } else {
    ADMUX =   3 | //channel 3
              (1 << ADLAR) |     // left shift result
              (0 << REFS1) |     // Sets ref. voltage to internal 3.3V, bit 1
              (0 << REFS0) ;     // Sets ref. voltage to internal 3.3V, bit 0

    isLowRefVoltage = false;
  }
  ADCSRA =
    (1 << ADEN)  |     // Enable ADC at 38461 Hz Samplerate
    (1 << ADSC)    | // start conversion
    (1 << ADATE)   | // free running
    (1 << ADPS2) |     // set prescaler to 16, bit 2
    (0 << ADPS1) |     // set prescaler to 16, bit 1
    (0 << ADPS0) |     // set prescaler to 16, bit 0
    (1 << ADIE); //enabel adc isr
    sei();
}

NB:
Die PCINT Interrupts funktionieren im AttinyCore auch nicht wirklich, da musste ich diese Klasse nehmen.
https://github.com/NicoHood/PinChangeInterrupt

 

[tsseh]

Die PCINT Interrupts funktionieren im AttinyCore auch nicht wirklich, da musste ich diese Klasse nehmen.
https://github.com/NicoHood/PinChangeInterrupt

dann würde die klasse auch nicht funktionieren. du meinst die funktionieren nicht wie normale INT0-n? ja! der einzige externe interrupt beim tiny, INT0, liegt auf PB2.

 

[xorg1990]

dann würde die klasse auch nicht funktionieren. du meinst die funktionieren nicht wie normale INT0-n? ja! der einzige externe interrupt beim tiny, INT0, liegt auf PB2.

Ja das weiß ich, die attachInterrupt Funktion funktioniert nur mit dem INT0-n Pins. Meinte die PCINT Pins also die Pin Change Interrupts funktionieren nicht

Folgende kleine Script geht nicht:

void setup() {
   pinMode(4, OUTPUT);
  pinMode(2, INPUT_PULLUP);
  cli();
  GIMSK |= (1 << PCIE);   // pin change interrupt enable
  PCMSK |= (1 << PCINT2); // pin change interrupt enabled for PCINT2
  sei();
  digitalWrite(4, HIGH);
 }

ISR(PCINT2_vect){
  digitalWrite(4, !digitalRead(4));
}


void loop() {
 
}

Noch eine Kleien Frage, kann ich ein Register in einer Variable speicher und dann wider auslesen z.B:
byte adcCopy = ADCSRA; und dann ADCSRA = adcCopy.

 

[tsseh]

Folgende kleine Script geht nicht:

und woran merkst du das? das geht allerdings wahnsinnig schnell, da du pin4 gleich wieder änderst.
und pin4 muss dann auch PCINT2, also PB2 sein. ist das so? kannst ja mal PCMSK |= (1 << PCINT2); in PCMSK |= (1 << PCINT0) | (1 << PCINT1) | (1 << PCINT2) | (1 << PCINT3) | (1 << PCINT4) | (1 << PCINT5); ändern um sicherzugehen

Noch eine Kleien Frage, kann ich ein Register in einer Variable speicher und dann wider auslesen z.B:
byte adcCopy = ADCSRA; und dann ADCSRA = adcCopy.

ja, natürlich

 

[xorg1990]

und woran merkst du das? das geht allerdings wahnsinnig schnell, da du pin4 gleich wieder änderst.

Naja an PB4 Hängt 'ne LED und jedes mal wenn ein Pin change auf PB2 Auftritt müsste die LED Aus und An gehen. Es Passiert einfach Nüscht.
Und Wieso soll das Schnell gehen? Wenn ich den mc einschalte, hängt PB2 via KABEL an GND, stecke ich das Kabel an + Müsste der Pin Change auftreten.

ja, natürlich

supi, dann kann ich den code nochmal Übersichtlicher gestalten.

 

[tsseh]

müsste die LED Aus und An gehen.

an ODER aus

Und Wieso soll das Schnell gehen?

weil ich vermutet habe pin 4 ist PB2. und du wechselst bei jedem int den level von pin 4
machst du aber anscheinend nicht, sondern pin 2 ist PB2 und du änderst das level händisch durch ein kabel auf GND

stecke ich das Kabel an + Müsste der Pin Change auftreten.

AB und AN, steckst du das Kabel ab müsste der Pin Change auftreten steckst du es wieder an GND ein weiterer

 

[xorg1990]

an ODER aus

Meinte ich doch.

sondern pin 2 ist PB2 und du änderst das level händisch durch ein kabel auf GND

So ist es.

Habe das Problem gefunden die ISR ist falsch es heißt ISR(PCINT0_vect)
Innerhalb der isr muss man dann feststellen das der int vom richtigen Pin kam.

uint8_t pinOld;
void setup() {
   pinMode(4, OUTPUT);
  pinMode(3, INPUT_PULLUP);
  cli();
  GIMSK |= 1<<PCIE;                            // Enable Pin Change Interrupt
  PCMSK |= 1<<PCINT3;                          // Watch for Pin Change (Falling) on D2 (PB2)
  sei();
  digitalWrite(4, HIGH);
 }

ISR(PCINT0_vect){
   uint8_t pinNow = PINB;
  uint8_t diff = pinNow ^ pinOld;
   if( diff & (1<<PB3)){
      digitalWrite(4, !digitalRead(4));
   }
   pinOld = pinNow;   // für den nächsten Interrupt merken
}


void loop() {
 
}

 

[tsseh]

Innerhalb der isr muss man dann feststellen das der int vom richtigen Pin kam.

das kannst du dir spaaren, das brauchst du nur, wenn du mehrere ints an verschiedenen pins unterscheiden musst.
da du aber nur einen, PCINT2 bzw. jetzt PCINT3, enabled hast, kann der int nur von diesem einen pin ausgelöst werden.

- - - Aktualisiert - - -

Habe das Problem gefunden die ISR ist falsch es heißt ISR(PCINT0_vect)

kam da nicht ein compilerfehler, "PCINT2_vect not defined"?

- - - Aktualisiert - - -

für den attiny85 ist nur PCINT0_vect definiert, es sollte also ein compilerfehler kommen

- - - Aktualisiert - - -

ok, doch nicht das makro ISR macht nur eine functiondeklaration, wenn PCINT2_vect nicht definiert ist, wird einfach eine funktion PCINT2_vect erzeugt.

 

[xorg1990]

ok, doch nicht das makro ISR macht nur eine functiondeklaration, wenn PCINT2_vect nicht definiert ist, wird einfach eine funktion PCINT2_vect erzeugt.

Aber das ist doch total unsinnig.