Flera Pic-processorer på I2C
- PHermansson
- EF Sponsor
- Inlägg: 4340
- Blev medlem: 22 december 2004, 00:46:38
- Ort: Särestad Grästorp
- Kontakt:
Re: Flera Pic-processorer på I2C
Men ett beslut kräver ju en del förarbete, man kan ju inte köra på något för att det låter bra och efter 1000 nedlagda timmar komma på att man valt fel väg.
Re: Flera Pic-processorer på I2C
Och förklara, varför kan man inte göra det?
Det finns ju bevisligen flertalet statliga myndigheter och andra stora företag som kör på den linjen...
SL, SJ mfl..

Sen att det är mindre bra är ju en annan fråga, men klart det går
Det finns ju bevisligen flertalet statliga myndigheter och andra stora företag som kör på den linjen...

SL, SJ mfl..

Sen att det är mindre bra är ju en annan fråga, men klart det går

- Swech
- EF Sponsor
- Inlägg: 4750
- Blev medlem: 6 november 2006, 21:43:35
- Ort: Munkedal, Sverige (Sweden)
- Kontakt:
Re: Flera Pic-processorer på I2C
I det här fallet verkar det lämpligt med CAN.
Inget vad som framkommit gör CAN till en icke framkomlig väg.
Det kan däremot finnas andra alternativ också.
Swech
Inget vad som framkommit gör CAN till en icke framkomlig väg.
Det kan däremot finnas andra alternativ också.
Swech
Re: Flera Pic-processorer på I2C
Håller med björn kostnaden är ju också ett alternativ där rs485 har en bra fördel (kostar väl en 12 spänn per stället eller nåt).
Prio ETT tycker jag dock är att försöka få in allt i samma µc, flera kretsar gör enbart att komplexiteten ökar minst 10x. Tex kan man inte förutsätta att något sker i realtid utan allt måste ske med fördröjning alternativt bekräftelse. Med detta menar jag att kommunikationen har säkert 100 gånger längre responstid än att bara sätta en pinne hög/låg och man måste även ta hänsyn till den mottagande enheten för att inte få "konflikter".
Tex kan man tänka sig ett scenario att ena processorn säger gasa medans andra säger bromsa -> dåligt.
En µc kan i de flesta fallen göra rätt många saker samtidigt och responstiden kan göras väldigt kort tex mha interrupt.
Prio ETT tycker jag dock är att försöka få in allt i samma µc, flera kretsar gör enbart att komplexiteten ökar minst 10x. Tex kan man inte förutsätta att något sker i realtid utan allt måste ske med fördröjning alternativt bekräftelse. Med detta menar jag att kommunikationen har säkert 100 gånger längre responstid än att bara sätta en pinne hög/låg och man måste även ta hänsyn till den mottagande enheten för att inte få "konflikter".
Tex kan man tänka sig ett scenario att ena processorn säger gasa medans andra säger bromsa -> dåligt.
En µc kan i de flesta fallen göra rätt många saker samtidigt och responstiden kan göras väldigt kort tex mha interrupt.
- peterjansson20
- Inlägg: 66
- Blev medlem: 12 april 2010, 09:07:16
Re: Flera Pic-processorer på I2C
Respons tiderna handlar om ca 10 < beslut per sekund (2beslut borde räcka).
Och om ett eller två beslut är felaktiga så hinner inte hydrauliken reagera.
När hastigheten ökar 10< kmh så är tanken att systemet skall stängas av.
Och om ett eller två beslut är felaktiga så hinner inte hydrauliken reagera.
När hastigheten ökar 10< kmh så är tanken att systemet skall stängas av.
- Swech
- EF Sponsor
- Inlägg: 4750
- Blev medlem: 6 november 2006, 21:43:35
- Ort: Munkedal, Sverige (Sweden)
- Kontakt:
Re: Flera Pic-processorer på I2C
Är det ett liknande system som används i din sidobild?
Vad gäller prisbild o liknande så framgår det inte om du skall ha 1 eller 10.000 enheter.
Är det bara 1 så är ju inte priset så känsligt.
Swech

Vad gäller prisbild o liknande så framgår det inte om du skall ha 1 eller 10.000 enheter.
Är det bara 1 så är ju inte priset så känsligt.
Swech
Re: Flera Pic-processorer på I2C
> Respons tiderna handlar om ca 10 < beslut per sekund
Alltså fler än 10 "beslut per sekund".
Hur hänger det ihop med att "2beslut borde räcka" ??
Alltså fler än 10 "beslut per sekund".
Hur hänger det ihop med att "2beslut borde räcka" ??
Re: Flera Pic-processorer på I2C
Han vill kanske ha marginal till sina 2, Tio är ju fler än två vilket isåfall verkat vara ett ganska bra (lägsta) mål.
EDIT: Hade skrivit 10 där det skulle vara 2, får hålla mig till decimalt...
EDIT: Hade skrivit 10 där det skulle vara 2, får hålla mig till decimalt...
- peterjansson20
- Inlägg: 66
- Blev medlem: 12 april 2010, 09:07:16
Re: Flera Pic-processorer på I2C
Om systemet klarar tio eller mer beslut per sekund så är det mycket snabbare än en människa.
Mer än 1010 beslut per sekund binärt.
Min sidobild har inget antispinn-system.
Det är helt otroligt att kameramannen lyckades ta detta fotot, eftersom kameran hade en respons tid på ca 6 sekunder.
Antalet maskiner är i första hand ett.
men om försöket slår väl så är det marknaden som får avgöra.
om vi tar oss fram bättre än Alstor i skogen så blir det nog många maskiner.
Mer än 1010 beslut per sekund binärt.
Min sidobild har inget antispinn-system.
Det är helt otroligt att kameramannen lyckades ta detta fotot, eftersom kameran hade en respons tid på ca 6 sekunder.
Antalet maskiner är i första hand ett.
men om försöket slår väl så är det marknaden som får avgöra.
om vi tar oss fram bättre än Alstor i skogen så blir det nog många maskiner.
Re: Flera Pic-processorer på I2C
Du verkar redan ha bestämt dig, men skulle ändå vilja lägga ytterligare en röst på CAN framför I2C.
Har jobbat lite grann med båda och tycker genast att CAN är smidigare rent programmeringsmässigt. Blev aldrig riktigt vän med I2C!
Har jobbat lite grann med båda och tycker genast att CAN är smidigare rent programmeringsmässigt. Blev aldrig riktigt vän med I2C!
- peterjansson20
- Inlägg: 66
- Blev medlem: 12 april 2010, 09:07:16
Re: Flera Pic-processorer på I2C
Jag tänker testa båda lite, men det blir nog CAN till detta projekt.