Svenska ElektronikForumet

Jag sitter och funderar lite på hur man på ett bra och enkelt sätt gör en signalhanterare till en microcontroller (18F4550 och dsPIC33fj256GP506) som ska skrivas i C. Med bra och enkelt så menar jag att det inte ska ta allt för mycket programminne och ramminne samt intuitivt hur man ska använda det. (Ingen begränsning i hur komplex själva koden är som hanterar signalerna).

Det jag skulle vilja göra är ett enkelt gränssnitt som en subrutin (eller tråd) lätt kan använda, typ sendData(buffer, size) och " ReadData(buffer, &size) eller liknande.
Kruxet i det hela är att flera trådar eller subrutiner ska kunna skicka och ta emot data och be om svar från en annan microcontroller men inte se varandras svar. Tanken är att de ska dela samma uart el CAN modul.

Ett exempel i pseudokod / C-kod för att visa principen jag är ute efter:

funktion1
{
int size = 0;
char buff[100];
static char mode =0;

switch(mode)
{
case 0:
send (mottagare1, "jag vill veta temperatur", 25);
mode = 1;
break;

case 1:
read(buff,&size)
if(size != 0)
{
mode = 3;
printf(buffer);
}
break;

default:
mode = 0;

}



funktion2
{
int size = 0;
char buff[100];
static char mode =0;

switch(mode)
{
case 0:
send (mottagare2, "vad är klockan?", 17);
mode = 1;
break;

case 1:
read(buff,&size)
if(size != 0)
{
mode = 3;
printf(buffer);
}
break;

default:
mode = 0;

}


while(1)
{
funktion1();
funktion2();
}


det jag undar över är:
har någon sett en bra princip för att lösa detta problem? finns det färdig kod nånstans som man skulle kunna ta inspiration från? Jag har 2 egna förslag på lösningar men är lite nyfiken på hur ni andra tänker eller skulle lösa detta problem.

Det låter lite som att det är interna meddelanden du syftar på. Dessa funktioner brukar finnas i olika realtids-OS.

Nä, det gäller mellan olika processorer hade jag tänkt.. Och jag har tyvär inget OS på dessa små pic'ar

Jag läser det halvt som vfr men att dessa "interna" meddelanden kommer på serieporten.

Och det är inte så svårt ändå faktisk, dock beroende av vilken sorts data som ska hämtas.

Jag kan tänka mig ett par scenario varav den mest sannolika skulle vara som följer:
En rutin som drivs per ISR ser till att handha all kommunikation, Till den bildas en lista över vilka värden som ska hämtas var och den betar av listan igen och igen i en kontinuerlig loop.

Alla svar sparas i ett minne där alla rutiner hämtar värden ifrån. Att för varje värde spara en flagga som anger att det är uppdaterat eller inte kan vara en bra idé.

På det vis kan alla programdelar få deras värden utan att snubbla över varandra.

En lite justerat version är att ha en stack över frågar som ska ställas och att rutiner fyller på stacken och kommunikationsrutinen betar av den i sin tur.

Det är väl ungefär de lösningarna jag tänkt på och funderar lite på den först-nämnda. Men tanken som jag hade där är hur man effektivt och smidigt gör en bra lista, eller om man vill göra en lista på en kommunikations-stack.

min tanke var oxå att man skulle använda ISRen för att skicka och ta emot data från/till 2 buffrar.

Det är när man ska läsa "sin data" som jag ser att det ev skulle kunna bli lite bökigt och där det antagligen finns massor av olika lösningar.

En tanke jag hade är att man skulle göra listobjekt för funktionen som innehåller t.ex
{
id
buffer pekare,
start index.
slut index.
}

sen kan man ha en funktion som skyfflar data från mottagar bufferten till alla funktioner med det ID som är intressrade av datan.

på så sätt så skulle man slippa bläddra genom hela listan varjegång man vill kolla om det finns någon relevant data. Tyvärr måste man hålla på och kopiera data och känns lite onödigt.

alternativt
{
id
funktionspekare till en funktion med buffer och storlek som inparameter.
}

här använder man ID't som en typ av fråga/kommando så att man hittar rätt funktion som i sin tur besvarar eller utför det som man förväntar sig av just det id't. Men i detta fallet så måste man göra en specifik funktion som tar hand om svaren vilket gör att man får skriva ytterligare hantering på högre nivå.

Känns ju som att man är en bit in på rätt spår iaf..

Jag tror du bör titta lite på de olika realtidsOS som finns, inte minst som idebank och källa för att sno ider. Det finns ju även de som klarar att ha koll på trådar som kör på olika µC.