Svenska ElektronikForumet

*bänkar mig med en öl i soffan och följer denna oooooligt intressanta tråd...*

Sedan är frågan om overflow() bara svara på OM det har hänt men inte nollställer flaggan om detta.
Är det fallet måste programmet lösa detta också.

EDIT: Sodjans post visar att det är fallet, overflow() nollställer faktisk flaggan.

http://arduino.cc/en/Reference/SoftwareSerialOverflow

"Tests to see if a software serial buffer overflow has occurred. Calling this
function clears the overflow flag, meaning that subsequent calls will return
false unless another byte of data has been received and discarded in the meantime."

Går nästan snabbare att kolla än att skriva ett inlägg...

Jag får intryck av att något genererar tecken in på mottagaren utan att
sändaren har (avsiktligt) skickat något. Det kan vara fel konfigurerat, fel
i koden i sändaren, störningar som ger falska tecken o.s.v. o.s.v. Bara
att felsöka "som vanligt"...

Al_Bundy skrev:Just nu kör jag bara RX,TX via software serial på digitala pinnarna 12,13.

Är det bara jag som inte fattar, eller varför står det: "SoftwareSerial mySerial(13, 7); // RX, TX#) i din kod när du säger att du använder 12,13 och varför står det : "pinMode(8, INPUT_PULLUP); och pinMode(9, INPUT_PULLUP);" när det borde vara pinMode(12, INPUT_PULLUP); om 12 skall vara RX-porten, eller är jag ute och cyklar?

Jag har löst det bättre nu. Just nu har varsin uC sin egen spänningskälla. Förr fick dem dela på spänningskällan (USB 2.0 500 mA) men nu har dem var sin. Och jag tog även bort "plusskabeln" eller vad man nu ska kalla den, som gick mellan VCC på från master till slave. Men GND sitter ihop med varandra iallafall.

Som jag ser nu på displayen så visar alla fyra temperatursensorerna rätt temperatur (1-wire) och inga fel än har upptäckts.
Jag hade också ett problem när jag började skicka. Jag fördröjde tiden till 5 sekunder, sedan kolla. Annars så kunde jag fylla upp bufferten till 64 bytes tills det blev overflow.

Alltså betyder det för att tömma bufferten i Arduino så måste jag läsa hela bufferten också. Förr hade Arduino någon flush funktion men jag vet inte vart den har tagit vägen någonstans. Arduino säger att flush() ingår i available() funktionen, men tveksamt det där.

Hur att sammanfatta detta:
1. Egen spänningskälla.
2. Delay så jag inte fyller upp bufferten direkt
3. Koppla bort kablen för VCC mellan uC:arna.

Men jag är ändå osäker på att 1:an löste problemet. Förr eller senare så kommer de få dela på en spänningskälla. Men jag tror att två processorer dela på ett USB 2.0 ström/spänning kanske var för fattigt.



Det jag ska göra nu är att bara finslipa på det hela.

SeniorLemuren skrev:

Al_Bundy skrev:Just nu kör jag bara RX,TX via software serial på digitala pinnarna 12,13.

Är det bara jag som inte fattar, eller varför står det: "SoftwareSerial mySerial(13, 7); // RX, TX#) i din kod när du säger att du använder 12,13 och varför står det : "pinMode(8, INPUT_PULLUP); och pinMode(9, INPUT_PULLUP);" när det borde vara pinMode(12, INPUT_PULLUP); om 12 skall vara RX-porten, eller är jag ute och cyklar?

Kod: Markera allt

SoftwareSerial mySerial(13, 7); // RX, TX


void setup(void)
{
  // start serial port
  Serial.begin(9600);
  mySerial.begin(9600);
  sensors.begin();

  pinMode(8, INPUT_PULLUP);
  pinMode(9, INPUT_PULLUP);

Det där med INPUT_PULLUP är Arduinos egna hittepå.
Man kan exempelvis kolla om något är anslutet t.ex. om en dörr är stängd eller så. Detta har inget med RX,TX att göra
Normalt ska man ha en resistor när man använder digitalRead() funktionen i Arduino. Men med INPUT_PULLUP så slipper man det. Bara en digital ingång som skickar en spänning till GND. Om detta är sant så blir det en 1:a. Enkelt va?

Det är faktiskt till ett reglersystem i MATLAB/Simulink om du undrar

> Arduino säger att flush() ingår i available() funktionen,

Källa? Det låter ju märkligt. Var har du sett det?

http://arduino.cc/en/Serial/Flush säger:

"flush(), Description:
Waits for the transmission of outgoing serial data to complete. (Prior to
Arduino 1.0, this instead removed any buffered incoming serial data.)"

Alltså, den gamla funktionen (att tömma RX bufferten) låter ju som den
rimliga funktionen för en "flush", inte att vänta på att något ska sändas.

> 1. Egen spänningskälla.
> 2. Delay så jag inte fyller upp bufferten direkt
> 3. Koppla bort kablen för VCC mellan uC:arna.

1 och 3 tror jag inte alls på.
2 känns ju ganska självklar...

Men står det inte att flush() är samma sak som availabale() i Arduino 1.0+?

Okej, 1,3 kan man sammanfatta som dessa processorerna var behov var mer ström. Du är noga ser jag.

> Men står det inte...

Var?

Och varför tror du att 1 och 3 hade något med overflow'en att göra?

Nej.

Jag skickade helt enkelt för snabbt från början. Men nu har jag en liten delay på några millisekunder så den hinner

Jag menade att om en uC får för lite ström så får den problem med RX,TX.

> Jag skickade helt enkelt för snabbt från början.

Ja, det verkar så, men det har ju ingenting med...

> Jag menade att om en uC får för lite ström...

...att göra. Jag tror inte att det var något problem.
Eller, det finns inget som pekar på det (i tråden).

Men du verkar veta svaret eller hur då du nekar det jag har upplevt. Säg mig då, vad tror du att det är?

Det har jag redan gjort:

>> 1. Egen spänningskälla.
>> 2. Delay så jag inte fyller upp bufferten direkt
>> 3. Koppla bort kablen för VCC mellan uC:arna.

> 1 och 3 tror jag inte alls på.
> 2 känns ju ganska självklar...

Du säger ingenting om i vilken ordning du gjorde ändringarna så
då måste man anta att allt gjordes utan tester under tiden. Och
då tror jag inte på spänningsmatningen...

Punkt 2 ensamt (alltså dålig eller ogenomtänkt design) är helt
tillräcklig i sig själv för att få de problem du hade.

Jag pratar inte om overflow, jag pratar mer om varför jag fick ibland 255 när jag skickade något annat
Jag har relativ seg kommunikation. 3 sekunder per sändning för slaven måste få tid också att ta emot -> analysera -> skicka.
Jag kommer effektivera det där också.

Start med att göra en testcase.
* Slaven svarar på fråga med ett värde som t.ex. räknas upp med 1 för varje gång den frågas. Kan ju börja på något lämpligt värde i närheten av 255, t.ex. 250. Att ha ett kommando för "nollställ räknaren" känns bra, då kan den komma om man laddar in ny version program i mastern.

* Mastern frågar och hämtar svaren och du jämför med vad det borde vara.

Men min gissning är den vanliga: du skickar bytes hit och dit - utan att ha koll på vad du egentligen sänder och utan att ha koll på hur du ska ta emot värden.

Det är väl floats igen - eller försöker du sända en int?