Hallo,
voor mijn eindwerk heb ik 4 pic microcontrollers op 1 print, nu is mijn vraag, kan ik deze allemaal met dezelfde reset schakeling reseten, of toch maar elk een apparte reset schakeling?

MVG,
Mathieu

Moet je toch echt iets meer info geven....

Waarom vier microcontrollers in 1 schakeling, past dat niet één (grotere) controller.

volgens mij kun/mag je ze gewoon samen resetten, waarom zou het niet mogen?
Je hangt ze denk ik toch ook op dezelfde voedingsspanning?

Maar de 2 vorige posters hebben beide een punt.

Als die 4 PIC's gelijktijdig starten, en wellicht op dezelfde klokfrequentie lopen, zou ik ze toch dubbel-en-dik ontkoppelen. Na verloop van tijd zullen de klokfrequenties wel enigzins uit mekaar lopen, maar onmiddelijk na een reset loopt dat mooi in de pas. Dat zou wel eens rare effecten kunnen opleveren zonder afdoende ontkoppeling.

Wel het gaat om een cocktail machine omdat we in zeer korte tijden cocktails willen maken, hebben we besloten om per 2 flessen een nieuwe pic te hanteren, omdat deze op interrupt basis pulsen zal gaan tellen van onze flowsensoren. Ik had het ook graag in een controller gezien maar denk dat dit onmogelijk zal zijn. Kan nooit alle pulsen gaan tellen met 1 controller..

Eerst dachten we iedere flowsensor van een flipflop te voorzien en zo te gaan kijken naar de status, maar waar haal ik mijn clock vandaan ik kan niet weten hoe rap iedere vloeistof zal lopen...

Of denken jullie wel dat dit te doen is?

Even een korte schets:

-8 flowsensor die pulsen generen
-8 magneetventielen via uln 2803 aangestuurt
-via pic 18f4550 komen over usb hoeveelheden binnen
-worden nadien naar 18f1220 verzondern serieel

Kan prima met één PIC-ding.

-8 flowsensor die pulsen generen

1 - interupt-pin en 3 IO lijnen die een demultiplexer sturen, kwa snelheid moet het geen probleem zijn.

-8 magneetventielen via uln 2803 aangestuurt

Lijkt me simpel, gewoon 8 IO gebruiken.

-via pic 18f4550 komen over usb hoeveelheden binnen

Via FTDI-chip aan de UART.

-worden nadien naar 18f1220 verzondern serieel

Overbodig zie vorige punt.

en waarom met een pic. mooi klusje voor een cpld die tellers bijhoudt.
die kan je dan op je gemak gaan lezen.
- geen software dus ook geen software bugs.
- geen kans op 'te trage' reactie tijd. tis hardware.

Ik kan namelijk nog niet over weg met cpld's, daarom graag met een pic.

Dus als ik WilToyo goed versta, hangt hij aan een interrupt pen een mux (geen demux toch? ), die gestuurd wordt vanuit de PIC aan een hogere frequentie dan die dat de flowsensoren geven. Maar dan heb je toch kans dat hij 2 keer een puls teld? Tenzij je de vorige status van de poort ook bekijkt. Hoe je die teller van die demux aan zou sturen begrijp ik nog niet zo goed.

Als hij de mux nu van de ene ingang die laag is naar de volgend springt dit hoog is heeft hij een flank, dus een valse interrupt toch?

Wel nog even meedelen de pulsen komen soms gelijktijdig binnen.

[Bericht gewijzigd door ThieuV op (21%)]

Op 2 maart 2009 23:11:12 schreef free_electron:
en waarom met een pic. mooi klusje voor een cpld die tellers bijhoudt.
die kan je dan op je gemak gaan lezen.
- geen software dus ook geen software bugs.

Nee, dan krijg je hardware bugs als je zelf de hardware gaat (be)schrijven :)

Het idee met die demultiplexer is volgens mij dat je op de een of andere manier alle 8 de inputs via een of-poort aan de PIC hangt.
Dan, zodra er een interrupt optreedt, kijk je welke input hoog is. Dit kan je al behalen zonder multiplexers, maar kost je wel 8 IO poorten ipv 3. 1voordeel van geen multiplexer is dat je direct na de interrupt kan inlezen. Ipv via *alle 8 de poorten te scannen*, maar dat is maar net wat je zelf prettig vind en hoe snel alles moet :-).

(Demultiplexers heb je juist niet nodig ;-))

ik zou zelf die mux weglaten: scheelt componenten, beetje uC heeft I/O lijnen zat..

een dergelijke I/O expander lijkt mij dus overbodig: KISS...

Vandaag dacht ik bij me zelf, dan kan ik ook even interrupt on change gebruiken van de Port B van die pic? Of is dit niet goed?

Na het bekijken van de datasheet zijn dit alleen maar 4 pinnen. Gewoon pollen zou dat niet het beste zijn?

[Bericht gewijzigd door ThieuV op (30%)]

Ik zou niet pollen, want dan kan je pulsen missen tijdens het afhandelen van USB.
Ik zou eerder je USB pollen, zoals het ook in de voorbeelden van de microchip USB firmware stack gebeurd.
En, zoals ik dus al zei, en zoals HMH ook al aangeeft, 1external interrupt. Hang alle 8 je signalen ieder via een diode aan deze interrupt (of gebruik een 8-bits OR poort als die bestaan).
En hang diezelfde signalen aan ieder elk zijn input pin van de PIC.

Dan krijg je dit idee:


unsigned char portVal;
void interrupt(){
if(externalinterrupt){
portVal = PORTB;//als alles aan portb hangt
case(portVal){
case 1:break;
case 2:break;
case 4:break;
case etc:break;
...
default:break;
}
}
}

sorry voor geen indents, hier direct in dit invoer vak getikt :P

[edit]
Over je reset e.d. ipc kan je alle MCLR's gewoon aan mekaar knopen, geen probleem lijkt mij.
Ik weet ook niet of het de bedoeling is dat alles synchroon loopt? Maar je zou er aan kunnen denken om een osccilator te nemen en dan of om de PIC's parallel te schakelen aan de osccilator. O.- Scheelt ook 3crystallen :P

[Bericht gewijzigd door Daan Timmer op (17%)]

Ja maar ik zou het toch willen proberen, om met een pic te werken. Nu is het een gemakkelijke oplossing eigenlijk...

Ik kan geen pulsen missen want ik stuur mijn hoeveelheden door naar de pic en doe een service request en gij blijft in die request zolang al mijn pulsen niet heb gehad...

Dus pollen is wel mogelijk dan?

Verklaar je nader (pseudocode?)

void ServiceRequests(void)
{

    if(USBGenRead((byte*)&dataPacket,sizeof(dataPacket)))
    {	
		DATA_REG output,input;
        counter = 0;
        switch(dataPacket.CMD)
        {
            case READ_VERSION:
                //dataPacket._byte[1] is len
                dataPacket._byte[2] = MINOR_VERSION;
                dataPacket._byte[3] = MAJOR_VERSION;
                counter=0x04;
                break;

			case CHECK:
				break;

			case COCKTAIL:
				status._byte = 0b00000000;				// Clear byte status

				/********Hoeveelheden doorsturen naar PIC 1********/
				chipselect1   = 1;					// Selecteer PIC 1
				TXREG = dataPacket.hoeveelh0;		// Hoeveelheid 0 verzenden
				while(PIR1bits.TXIF == 0); 			// Wacht tot alles verzonden is

				//TXREG = dataPacket.hoeveelh1;		// Hoeveelheid 1 verzenden		
				//while(PIR1bits.TXIF == 0); 			// Wacht tot alles verzonden is
				
				//chipselect1 = 0;				
				/**************************************************/

				

				dataPacket._byte[1] = status._byte;
                counter = 0x02;
           	    break;
                
            case RESET:
                Reset();
                break;
                
            default:
                break;
        }//end switch()
        if(counter != 0)
        {
            if(!mUSBGenTxIsBusy())
                USBGenWrite((byte*)&dataPacket,counter);
        }//end if
    }//end if

}//end ServiceRequests

Via usb vraag ik de cocktail service request, nu staat er een heel andere code nog onder maar daar onder zou dan die polling moet komen. Dus kan hij niets missen door usb.

ligt het aan mij, of verstuurt hij daar via UART?


void interrupt(){
	if(externalinterrupt){
		//kijk welke poort hoog is
	}
}

void main(){
	while(1){
		ServiceRequests();
	}
}

ik zou dan zo iets doen?

Ik weet niet wat die counter variabele doet.
Maar hierdoor is het mogelijk om de geheletijd de ServiceRequest te pollen. En de interrupts komen er gewoon tussen door. Ik zie geen tijdkritische zaken in de servicerequests() staan.

In die servicerequests moet je dan kijken *of er al nieuwe pulsen zijn gekomen* maar dit kan je zelf beter implementeren want ik heb verder geen idee hoe je het af wilt handelen en wanneer je iets wilt verzenden.

onder de cocktail case, moet er nog een hele nieuwe code komen...

Nu verzend hij inderdaad over uart, maar daar zou ik dan gaan pollen en constant kijken of het gelijk is aan de doorgekregen hoeveelheden via usb...

of toch met een interrupt? Maar dat zal namelijk niet gaan om deze te gaan or'en want er gaat geen verandering op het signaal optreden. Dit is al eens aangehaald in een vorig topic...

een korte schets van het verloop:

1) via usb vraag ik cocktail modus aan en geef ik 8 hoeveelheden door in cl
2) cl omzetten naar pulsen
3) magneetventielen openen
4) pulsen gaan tellen van 8 flowsensoren
5) aantal pulsen gelijk aan bijhorende hoeveelheid? ja=> magneetventiel sluiten

4 & 5 worden een lusje als ik zal gaan pollen dan?

Ik heb vandaag even volgende code geschreven:


			case COCKTAIL:
				status._byte = 0b00000000;				// Clear byte status
				magneetventielen._byte = 0b00000000;	// Clear byte magneetventielen

				//***************Doorgekregen ml's omzetten naar pulsen***************//
				hoeveelh0= dataPacket.hoeveelh0 * 1,28;	hoeveelh1= dataPacket.hoeveelh1 * 1,28;	hoeveelh2= dataPacket.hoeveelh2 * 1,28;	
				hoeveelh3= dataPacket.hoeveelh3 * 1,28;	hoeveelh4= dataPacket.hoeveelh4 * 1,28;	hoeveelh5= dataPacket.hoeveelh5 * 1,28;
				hoeveelh6= dataPacket.hoeveelh6 * 1,28;	hoeveelh7= dataPacket.hoeveelh7 * 1,28;
				//********************************************************************//
				
				flvorigestatus._byte = PORTB; 			// Rust toestand inlezen van de flowsensoren

				//********Controle welke magneetventielen moeten worden geopend*******//
				if(hoeveelh0 != teller0)				
					magneetventiel0 = 1;
				if(hoeveelh1 != teller1)
					magneetventiel1 = 1;
				if(hoeveelh2 != teller2)
					magneetventiel2 = 1;
				if(hoeveelh3 != teller3)
					magneetventiel3 = 1;
				if(hoeveelh4 != teller4)
					magneetventiel4 = 1;
				if(hoeveelh5 != teller5)
					magneetventiel5 = 1;
				if(hoeveelh6 != teller6)
					magneetventiel6 = 1;
				if(hoeveelh7 != teller7)
					magneetventiel7 = 1;
				//********************************************************************//

				LATD = magneetventielen._byte; 		// Magneetventielen openen


				while(LATD != 0b00000000)
				{
					if(hoeveelh0 != teller0)				
					{
						if(flvorigestatus.bo == 0 && PORTBbits.PORTB0)
						{
							teller0 ++;
							if(teller0 == hoeveelh0)
								magneetventiel0 = 0;
						}		
					}
					else
						magneetventiel0 = 0;
					if(hoeveelh1 != teller1)
					{
						
					}
					else
						magneetventiel1 = 0;

De code is nog niet compleet maar het is volgens hetzelfde partroon van de eerste keer. Maar nu heb ik geen macht wanneer deze zal gaan kijken. Wat denken jullie? Zouden jullie het anders doen?

Dit onderwerp hadden we toch al eens besproken hier? Toen hebben we dat pollen ook al tot in detail uitgekauwd als ik me goed herinner. Toen moest het zo nodig met irq's wat volkomen onnodig is.

PS, lekker BREED topic weer!

Sorry hoor... Ik snap het gewoon nog niet helemaal, heb daar nog helemaal geen ervaring mee..