SPI startmoment ?

Op 23 augustus 2019 13:49:46 schreef Arco:
[...]
Dat lokt natuurlijk de vraag uit: waarom... (kan dat niet met 1 processor?)

ik heb 300 input pinnen nodig.

ik ga eens de i2c bekijken, ik heb dat in het verleden al vaker gebruikt (o.a. I/O extension), maar naar mijn weten is dat bedoeld voor korte afstanden.

Zoals gezegd, voor I2C buiten een behuizing heb je de P82B715 extender nodig...
En met SPI hoe wou je al die slave selects aan gaan sturen?

Serieel met UART zou je alles in serie kunnen zetten:

  .----------<----------------<--------.
  |                                    |
  |   .----.      .----.      .----.   |
  '-rx|MCU1|tx--rx|MCU2|tx--rx|MCU3|tx-' 
      '----'      '----'      '----'

met dat SPI ben ik wat deze toepassing betreft wel klaar, ik gebruik het nog wel om de externe RAM (23LC1024) aan te sturen.
maar ik was van plan om alle atmega's als een soort 74HC595 te programeren en dan bij de laatste atmega de verzending met SPI naar de atmega128 te maken.

edit:
uart is ook nog steeds een optie, moet dat beter bekijken.

[Bericht gewijzigd door trix op vrijdag 23 augustus 2019 15:28:51 (11%)

Als je ze in serie zet zoals in het tekeningetje, kan iedere MCU het signaal gewoon doorsturen naar zijn collega (na er zijn eigen byte achter geplakt te hebben)
De master krijgt dan zijn eigen byte terug binnen, met 19 databytes daarachter.

Op 22 augustus 2019 18:31:57 schreef Arco:
Voor communicatie tussen CPU's is de UART veel simpeler in gebruik...

Bij AVR's kan je een USART in SPI mode zetten, het is dus bijna hetzelfde.

Zie pagina 202.
http://www.microchip.com/mymicrochip/filehandler.aspx?ddocname=en59046…

Volgens mij is het voordeel van SPI dat het bloedsnel is. Elk bit krijgt een clockpuls mee. Goed voorbeeld is te vinden bij aansturing meerdere stappenmotordrivers zoals bij de Arduino-controlled 3D printers.

Een UART moet (intern) gewoonlijk 16 MCU clockpulsen per bit hebben.

En I2C is nog slimmer maar ook weer langzamer. Hoofdvoordeel is voor mij dat je met maar 2 communicatie draadjes heel veel IC's aan elkaar kan knopen.

[Bericht gewijzigd door Spog2 op vrijdag 23 augustus 2019 17:03:37 (40%)

het hoeft helemaal niet snel te zijn, er moeten in totaal 11400 byte van de device naar de hoofdprint, en daar mag hij ong. 2 sec. over doen.

Op 23 augustus 2019 17:48:59 schreef trix:
het hoeft helemaal niet snel te zijn, er moeten in totaal 11400 byte van de device naar de hoofdprint, en daar mag hij ong. 2 sec. over doen.

Normaal gesproken zou je dan i2c nemen.
Maar ik heb ooit wel eens wat onderzoek gedaan wat er bij komt kijken als je zelf een i2c protocol zou willen implementeren. Leek me bij nader nog niet zo eenvoudig, en ben er toen niet op doorgegaan.
Een een chip of display met i2c uitlezen is nog even iets anders dan een chip met i2c uitleesbaar te maken. Er zijn mechanismen voor fouten, multimaster en zo. Dat meerdere divices tegelijk aangesproken worden of juist bezig zijn moet je in goede banen zien te sturen.

Maar als je het simpel kan houden en het hoeft niet supersnel dan zou ik voor i2c gaan.

[Bericht gewijzigd door Spog2 op vrijdag 23 augustus 2019 18:13:26 (13%)

soort gelijk probleem dus als met de SPI.

UART is dat het zelfde als USART ?

het is wel een heel gedoe om een paar bitjes om te testen binnen te krijgen.

[Bericht gewijzigd door trix op vrijdag 23 augustus 2019 18:26:02 (34%)

USART = Universal Synchronous and Asynchronous Receiver and Transmitter

Hij kan dus beide functies vervullen.

The XCKn (Tranfer Clock) pin is only used by synchronous transfer mode.
Als SPI heb je dezelfde situatie.

Bij UART ontbreekt dat clocksignaal (en dus het draadje). Daar wordt de pulsbreedte gemeten door de start/stop bitbreedte te scannen.
Dat bit moet de CPU 16x prikken om voldoende nauwkeurig te synchroniseren.

Als je met SPI werkt weet je zeker met welke chip je praat en dat er goed geklokt wordt.

Bij i2C praat je in principe tegelijk met iedereen door elkaar. Dat moet je softwarematig oplossen.

P.S.:
Je hebt bij displays vaak "9 bit SPI".
Vaak kun je bij SPI het byte ook achterste voren verzenden, dus ipv bit 87654321 stuur je 12345678.

[Bericht gewijzigd door Spog2 op vrijdag 23 augustus 2019 19:00:26 (10%)

wat me zo te binnen schiet, zou het via RS485 kunnen. ik stel me zo voor dat je dan 2x een RS485 module hebt. 1 bij de device en de andere bij de hoofdprint.
je bied die bitjes bij de device aan die module aan vervolgens gaat het met RS485 naar de andere module (storings ongevoelig) waar je het weer binnen kunt lezen in de atmega 128.

device ----> RS485 module ----> 10 mtr. kabel ----> RS485 module ----> atmega128

Er zijn mechanismen voor fouten, multimaster en zo. Dat meerdere divices tegelijk aangesproken worden of juist bezig zijn moet je in goede banen zien te sturen.

Dat is bij TS niet van belang er is maar 1 master.

Waarom geen RS232, ? 9600 8 N 1 , dat is een vrij algemene instelling de meeste zut werkt er wel mee/op

[edit] of er een LIN-bus van maken.

[Bericht gewijzigd door Shiptronic op vrijdag 23 augustus 2019 20:50:21 (16%)

Met 9600 baud ga je geen 11400 bytes in 2 sec. halen...
RS-232 kan prima, maar dan moet 't wel wat rapper...   (je haalt aan bytes ongeveer de baudrate/10 )

Tja het kan sneller, niet zo snel bij still gestaan

ik had verwacht dat het versturen van 11400 bytes over 10 mtr. eigenlijk geen probleem zou zijn. toch iets lastiger dan gedacht.
ik moet gewoon de juiste methode zien te vinden. die 2 sec. is ook niet strikt, 4 sec. is ook geen probleem.
maar bestaan er rs485 modules (of ander bus/protocol) zoals ik voorstelde op met mijn 5 posts terug ?

ik kan nog de P82B715 extender voor i2c bekijken zoals arco voorstelde.
maar een i2c slave maken is schijnbaar ook niet eenvoudig.

Ik heb het topic niet helemaal meer gevolgd, maar pik toch wat dingen op. Volgens mij is het hardware design heel erg uit de bocht aan het vliegen. Je doel is (denk ik) heel veel I/O aan sturen, en dat probeer je te bereiken met 20 microcontrollers die als SPI-slave staan en die door een andere micro wordt aangestuurd. Omdat je SPI gebruikt neem ik aan dat het ook nog eens allemaal op 1 board zit. Het is niet vervelend bedoeld hoor, maar dat voelt voor mij als een heel erg lelijke oplossing.
Wat ik zou doen: 1 enkele micro die de aansturing doet. Met I/O expanders op I2C sluit je zoveel I/O aan als je maar nodig hebt. Ik weet dat er ICs zijn met (uit m'n hoofd) 40 pinnen per IC, dus dat loopt lekker op. I2C zijn voor veel micros standaard library functies, dus dan wordt het ineens appeltje-eitje.

Er zijn er zelfs met 60 i/o... ( Cypress CY8C9560A )

@flipflop: zover ik het begrijp, gaat het om 19 ATmega8 bordjes die zelfstandig data verzamelen op hun eigen locatie en die data opslaan in een array van 600 bytes. Die data-arrays moet worden uitgelezen door een centraal systeem (ATmega128).
Het zit dus niet allemaal op 1 bord en er wordt niets aangestuurd.

zover ik het begrijp, gaat het om 19 ATmega8 bordjes die zelfstandig data verzamelen op hun eigen locatie en die data opslaan in een array van 600 bytes.

Dan weet je meer als ik kan opmaken uit de posts... (ik zie het nergens...)

MNM(tm) heeft het bij het juiste eind, ik heb wel een paar keer aangehaalt dat er 10 mtr. kabellengte tussen zit. dus niet op 1 bord.

in de basis is het:

- 11400 bytes
- in 2,3 of 4 seconden
- over 10 mtr. kabellengte sturen

Ja, dat begreep ik wel. Maar niet dat het 19 losse prints waren...

Dus we gaan met SPI over een kabel van 10 meter? Ik vrees dat mijn post dan nog volledig valide is. Misschien nog wel meer dan toen ik het schreef.

Ik zeg RS485.

ik zag wel dat er SPI to RS485 convertors zijn, b.v. de max3140. ik moet dat eens goed bekijken, kan een kanshebber zijn.

of krijg ik dan weer gewoon de synchronisatie problemen die ik eerst ook had ?

[Bericht gewijzigd door trix op zaterdag 24 augustus 2019 18:54:35 (25%)

SPI is niet bedoeld voor grote afstanden. Op hogere clocksnelheid krijg je dan altijd problemen bij grotere afstanden.

klopt daarom dus een PSI --> RS485 omzetting zodat de RS485 over de 10 mtr. kabel lengte gaat.