avr veel variabelen opslaan ?

Op 20 april 2020 22:11:37 schreef trix:
[...]
de uiteindelijke toepassing wil ik nog even voor mezelf houden, voegt ook niks toe, hooguit voor de beeld vorming.

Juist, die beeldvorming daar heeft iedereen wel behoefte aan denk ik
maar begrijpelijk als het nog even "geheim" blijft

Op 20 april 2020 22:11:37 schreef trix:
heb je voor zo'n ARM soms ergens een beginners artikel, om te kijken hoe dat werkt ?

nee weet ik zo niet, zo eenvoudig is het ook weer niet
Maar een stm32 cube getting started tutorial zullen er vast wel zijn.
de STM32 discovery of nucleo kits kosten geen drol

Je moet even stoppen met "3 bytes per atmega". Het is lastig als je steeds "rekenfouten" blijft maken.

6 meter per seconde en 3 meter levert 500ms, niet 100ms op.

Even totale doorvoer berekenen:

6 meter per seconde, 600 lijn-scans per seconde. Simpel. Hoe groot een object is: maakt me niet uit. Iedere lijn is 288/6 = 36 bytes.

Totale doorvoer: 21.6kbyte per seconde.

Als we de boel over een serieel lijntje moeten sturen dan is ongeveer 200kps genoeg. Fijn om te weten. Ik zou denk ik niet voor 200 of 250kbps communicatie kiezen, maar eerder voor 500kbps of 1Mbps. Als er niet bijvoorbeeld uiteindelijk voor USB gekozen zou worden wat zowiezo al sneller gaat.

Maar in ieder geval hebben we bepaald dat het niet om absurde hoeveelheden data gaat en dat we het "real-time" naar een master controller kunnen sturen.

-----------
Intermezzo. 6 meter per MINUUT is 100ms per LIJN. WHOA! Als de fout niet in de berekening zit maar in de bron-gegevens, dan zit je het WEEER onnodig moeilijk te maken voor ons om te helpen: WEER zitten we te werken met foute gegevens.

Op 20 april 2020 20:56:11 schreef trix:
- uitgangspunt = de "scan" uit te voeren met 6 mtr./sec (kan meer of minder worden, afhankelijk v/d mogelijk heden).

Dan nog 60x langzamer moet kunnen. Ik blijf effe mikken op gewoon 6m/s zoals je hebt aangegeven.

-----------

Ik ben het met je eens met dat "looplicht". Maar ik den niet dat je dat met maar 1 lampje tegelijk kan volhouden: volgens mij haal je dan de scantijd niet. Als je er voor kan zorgen dat iedere TSOP maar een stuk of 10 TSAL's kan zien dan kan je een fors aantal van die looplichten tegelijk laten lopen.

Iedere TSOP, ik heb het datasheet er bij gepakt. Doet er volgens spec ongeveer 0.4ms over om te reageren op een inkomend signaal. Ik zou zeggen: Reken even op 1ms. Dat betekent dat je met een enkel looplicht 288 ms bezig bent. Als je 6m/sec gaat, dan is dat 600cm/sec = 1.6ms/per sample. Dan heb je niet de tijd om een looplicht te gaan doen.

Goed. Hier stop ik met het ontwerp. Eerst moet duidelijk zijn of het 6m/s of 0.1m/s is.

Voor het "data vergaren en doorsturen met een microcontroller" is het geen probleem om het 60x sneller te doen dan wat je nodig hebt... voor de TSOP ontvangers echter wel. Dus zeg het maar wat het is.

Op 21 april 2020 07:54:05 schreef rew:
Iedere TSOP, ik heb het datasheet er bij gepakt. Doet er volgens spec ongeveer 0.4ms over om te reageren op een inkomend signaal. Ik zou zeggen: Reken even op 1ms. Dat betekent dat je met een enkel looplicht 288 ms bezig bent. Als je 6m/sec gaat, dan is dat 600cm/sec = 1.6ms/per sample. Dan heb je niet de tijd om een looplicht te gaan doen.

Volgens eerdere gegevens gaat het om 4mS per "lamp" wat maakt dat er 288x0.004 = 1152mS nodig zijn voor 1 scan.
Zelfs als dat gehalveerd kan worden heb je nog redelijk veel tijdverlies.

Daarom ook dat ik al experimenten gedaan heb om iets te bekomen dat alle ingangen in 1 keer gelezen worden, met alle zenderleds altijd "aan"...moeilijk met TSOP's

Maar... trix maakt rekenfouten, zegt "1cm afstand" op zo'n manier dat ik denk dat het over de afstand tussen de sensor en transmitter gaat. Hij kent niet alle "bouwstenen", met dat ie rare/foute onderdelen kiest, dat soort dingen. Daarom wilde ik bij het begin beginnen. Dus ik heb zojuist voor gerekend dat 1ms per zender wel ongeveer moet kunnen. Trix is kennelijk op "4ms" uitgekomen. Met 1152 ms/lijn ga je zelfs 6m/minuut niet halen. Dus... we moeten bij het begin beginnen en niet uitgaan van rare half-fabrikaten-specs van trix.

Op 21 april 2020 07:54:05 schreef rew:
Intermezzo. 6 meter per MINUUT is 100ms per LIJN. WHOA! Als de fout niet in de berekening zit maar in de bron-gegevens, dan zit je het WEEER onnodig moeilijk te maken voor ons om te helpen: WEER zitten we te werken met foute gegevens.

Dan nog 60x langzamer moet kunnen. Ik blijf effe mikken op gewoon 6m/s zoals je hebt aangegeven.

Ik ben het met je eens met dat "looplicht". Maar ik den niet dat je dat met maar 1 lampje tegelijk kan volhouden: volgens mij haal je dan de scantijd niet. Als je er voor kan zorgen dat iedere TSOP maar een stuk of 10 TSAL's kan zien dan kan je een fors aantal van die looplichten tegelijk laten lopen.

met het schaamrood op mijn kaken, moet ik bekennen dat het inderdaad 6 mtr./min. is. te snel getypt
sorry voor dat, het zijn ook zoveel getallen.
dus inderdaad 100 mS per lijn.

het laatste in je quote is dus wat ik aan het doen ben, ik noem dat dus blokken......12 stuks.
wat 12x PCB is en dus 12x atmega.
288/12 = 24 is dus 3 byte per atmega. (1x atmega per PCB)
dit is dus wel per "lijn" zoals jij dat noemt.

dus die 3 bytes per atmega klopt gewoon, is echt geen rekenfout.

op deze foto is zo'n PCB voor de TSOP & de TSAL te zien. met 24 TSOP of TSAL en 1x atmega.

ik ben bezig een stukje code schrijven die de 11,8 kByte aan data in de ext. RAM gaat schrijven.
nu zat ik mij af te vragen wat er gebeurt met de UART overdracht wanneer het weg schrijven van een byte langer duurt, dan de overdracht van een byte.
dan moet denk ik wel de snelheid v/d UART verbinding omlaag, maar is dat ook zo ?

UART en SPI zijn losse peripherals die niets met elkaar te maken hebben...
Er moet natuurlijk wel voldoende tijd zijn om alle interrupts af te handelen en databuffers te vullen.

Verder kosten UART/I2C/SPI geen tijd; het zijn autonome modules...

Op 22 april 2020 20:48:31 schreef Arco:
UART en SPI zijn losse peripherals die niets met elkaar te maken hebben...

Wel als je de data van de ene naar de andere moet doorsluizen. Je moet aan een kant sneller zijn anders krijg je een overrun.

Er moet natuurlijk wel voldoende tijd zijn om alle interrupts af te handelen en databuffers te vullen.

Dat dus inderdaad.

Verder kosten UART/I2C/SPI geen tijd; het zijn autonome modules...

Die kosten wel degelijk wat tijd. De tijd die je in de interrupt handler verstookt en wat setup tijd om de boel te starten, hier en daar wat packet/fragmentatie van commando's etc. De ene peripheral wat meer dan de andere. De TWI interface is wat minder efficient dan een UART. Bij de TWI moet je de start/stop bits etc afhandelen. Bij een UART kun je eeuwig door blijven schrijven. Bij SPI moet je na elke page write een nieuw adres schrijven waarvan je weer kunt "auto-incrementen" bij data schrijven etc.

Maar alles netjes onder interrupt gemaakt en je tijdsbudget komt uit, moet je met efficiente buffer handling een heel eind komen.

Die kosten wel degelijk wat tijd.

Dat zijn niet de modules zelf, maar het 'klaarzetten' van de benodigde data en afhandelen van de in/output die tijd kosten.
Als dat gebeurd is gaat de rest autonoom...

Nou niet echt in dit geval, bij sommige processoren wel, dan kun je met DMA alles versturen. Maar niet bij een AVR of kleine CPU. Je zult elk byte in je ISR toch in de peripheral moeten stoppen.
Kost niet veel tijd, als je het efficient doet maar een handvol machine instructies.

Ah,

De pics die ik gebruik hebben FIFO buffers voor SPI/UART/I2C waar je alvast wat in kunt 'proppen'...
(ook DMA trouwens, maar dat gebruik ik nooit)

Zelfs zonder "FIFO" is er nog wel wat buffer ruimte. Omdat het mogelijk moet zijn om back-to-back data te versturen wordt het transmit data-register geleegd op het moment dat BEGONNEN wordt met een byte versturen. Zo heb je een hele byte-tijd de tijd om de volgende klaar te zetten.

Op 22 april 2020 22:07:52 schreef henri62:
[...] Wel als je de data van de ene naar de andere moet doorsluizen. Je moet aan een kant sneller zijn anders krijg je een overrun.

hoe uit zich dat ? ga je dan data verliezen of word de boel trager ?

Bij SPI moet je na elke page write een nieuw adres schrijven waarvan je weer kunt "auto-incrementen" bij data schrijven etc.

ik kies de sequentiele mode, dan kan de data in 1 "run" in de ext. RAM.[/quote]

Maar alles netjes onder interrupt gemaakt en je tijdsbudget komt uit, moet je met efficiente buffer handling een heel eind komen.

die interrupts moet ik inderdaad ook gaan toepassen, ik ben altijd een beetje bang om te veel in een interrupt te wilen doen.

Op 23 april 2020 15:18:47 schreef trix:
[...]
hoe uit zich dat ? ga je dan data verliezen of word de boel trager ?
[...]

Als je dat binnen krijgt van een andere controller waar je geen controle over hebt moet je de data op tijd verwerken anders ben je inderdaad data kwijt.
Heb je controle over de "bron", bijvoorbeeld je bent zelf een I2C slave kun je clock stretching doen en wordt de boel gewoon trager.

Voor seriele aanvoer met UARTS wordt vaak XON/XOFF gebruikt om de bron te vertagen of de reguliere DSR/DTR lijntjes.

Maar volgens mij gebruik jij geen van beide.

ik kies de sequentiele mode, dan kan de data in 1 "run" in de ext. RAM.

In het datasheet van het ram staat in hoe groot een maximale block write is. Vaak is er een limiet van 32/64 of whatever bytes. Dus altijd het datasheet nakijken.

Oh ja: en die pages beginnen op een veelvoud van de grootte. Dus als je page size 64 bytes is en begint bij 70 te schrijven mag nog maar 56 bytes schrijven met autoincrement tot en met je bij 127 bent.

Valt niet me hè, embedded software..

valt zeker niet mee, maar dat had ik ook niet verwacht. beetje bij beetje word het wel duidelijker.
ik gebruik trouwens wel de UART (met MAX485).

ik ben in de datasheet v/d 23LC1024 niets tegen gekomen over een maximale schrijf groote, volgens mij kan je die gewoon van het begin tot het ein in een "run" vol schrijven.

De 23C512 heeft een size van 32 bytes, zal deze ook eens opzoeken.
Oh ja: Is soms ook merk afhankelijk, fijn he!

-edit- Nope deze is ook 32 byte, zie hoofdstuk 2.4 van bijvoorbeeld het microchip document.
Lezen kan wel over de hele range.

Chips die een 'sequential mode' hebben (bijv de IS62WVS5128 van Issi) kun je in 1 keer helemaal lezen/schrijven...

Op 23 april 2020 16:49:01 schreef henri62:
-edit- Nope deze is ook 32 byte, zie hoofdstuk 2.4 van bijvoorbeeld het microchip document.
Lezen kan wel over de hele range.

in sequentiel mode kan je hem wel in 1 run vol schrijven, die 32 byte geld voor de "page" mode.

[Bericht gewijzigd door trix op donderdag 23 april 2020 17:54:20 (20%)

Ah, die had ik gemist. Je blijft je verassen.

net een mens

klopt het als ik zeg:
baud = 9600 = 9600 bits/sec. = 1200 byte/sec
1 byte 1/1200 = 833uSec.
dus ik heb 833 uSec. om de byte weg te schrijven in de exr. RAM.

Meestal kun je grofweg 10 bits per byte rekenen (geen 8). Dit komt door start/stop bits...

Op 23 april 2020 15:18:47 schreef trix:
[...]
die interrupts moet ik inderdaad ook gaan toepassen, ik ben altijd een beetje bang om te veel in een interrupt te wilen doen.

Dat moet je inderdaad ook niet doen, maar je moet ook juist weer niet schromen om ze niet te gebruiken.

Die interrupt heb je nodig om bytes te ontvangen of versturen via je UART

jouw ontvangende kant moet dus elke byte die binnenkomt gegarandeerd uit het UDR register trekken en ergens tijdelijk opslaan. Ik zou zeggen in een RAM buffer.
In de main loop (daar kom je tussen elke ontvangen byte gewoon weer een of meerdere keren (zolang je geen rare dingen in je interrupt doet) kun je dan een trigger om deze ram buffer in de nv ram te schrijven.
Je kan hiervoor ook weer een SPI interrupt gebruiken.

Nu bedenk ik me wel dat je datastream veel groter is in je RAM past.
Of was het nou 900 bytes per print met de leds? (Dan zou het kunnen in 8K ram, al is het niet heel efficiënt)

Misschien werkt het ook wel als je direct vanuit de rx interrupt van de uart de byte in het SPI dataregister zet, al denk ik dat het efficiënter is om via SPI op hoge snelheid een hele reeks bytes in je NV ram te schrijven. Het hangt allemaal van timing af wat het gunstigste uitkomt. En hoe je je interrupt load wil verdelen.

NV ram is externe ram neem ik aan ?

Of was het nou 900 bytes per print met de leds?

dat was het inderdaad.

[Bericht gewijzigd door trix op vrijdag 24 april 2020 10:32:00 (58%)

ik heb een stukje code geschreven, wat voor mijn gevoel een heel eind goed is. die moet de in komende data van alle TSOP-en in de ext, RAM plaatsen. ik zie alleen niet: waar en hoe ik een interrupt moet implementeren.
(dat heb ik eigenlijk heel vaak met een interrupt ) die interrupt is dus leeg.
ik gebruik nu voor de adressering v/d ext. RAM decimale getallen (dat kan ik beter visualiseren) mag/kan dat ?
ik hoop dat iemand dit wil bekijken. (code is deel van een groter geheel)

ISR(USART0_RX_vect)
{
	
}

//*** below: receiving the data from the TSOP ***********************************************
//*** DE & RE (MAX485) was making "0" in the interrupt ***********************************************

UCSR0A &= ~(1 << MPCM0); // switch off the MPCM mode for receiving data
		
// below: SPI for extern RAM ***********************************************
SPCR = (1<<SPE)|(1<<MSTR)|(1<<SPR1)|(1<<SPR0); // Enable SPI, Master, set clock rate fck/128
	
uint8_t SPI_transfer(uint8_t data) // functie
{
	SPDR = data;
	while(!(SPSR & (1<<SPIF))); // Wait for transmission complete
	return SPDR;
}
	
uint32_t address;
		
//**************** TO SET THE EXT. RAM IN THE sequential MODE (01) *************************	
PORTG &= ~(1 << PING5); // make SS pin = 0
SPI_transfer(0b00000001);  // write mode register
SPI_transfer(0x01); // set mode register in *sequential mode*
PORTB |= (1 << PINB0); // make SS pin = 1									
									
_delay_ms(1);
			
for (scanner_read = 1; scanner_read < 13; scanner_read ++) // reading TSOP's to the MAIN pcb.
			{
	for (TSOP_read = 1; TSOP_read < 4; TSOP_read ++) // reading the bytes from 1X TSOP (3 times)
				{				
	// below: calculate adress in ext. RAM
	// example: TSOP pcb #4 and byte #2 = 7600
	// every byte (in total 36) have at least 600 bytes in front of him.				
	RAM_adress_temp_1 = ((scanner_read * 2000)-1000); 
	if (TSOP_read == 1) {RAM_adress_temp_2 = 0;}
	if (TSOP_read == 2) {RAM_adress_temp_2 = 600;}
	if (TSOP_read == 3) {RAM_adress_temp_2 = 1200;}
	RAM_adress = RAM_adress_temp_1 + RAM_adress_temp_2;
					
	while ((UCSR0A & (1 << RXC0)) == 0) {}; // wait for data to be received
	receivedbyte = UDR0; // copy the received byte value into the variable "ReceivedByte							
					
	if (TSOP_read == 1) // byte 1 from TSOP
					{
	PORTG &= ~(1 << PING5); // make SS pin = 0
	SPI_transfer(0b00000010);  // write data to memory
	address = RAM_adress; // is address in ext. RAM
						
	SPI_transfer((address>>16)); // adress
	SPI_transfer((address>>8)); // adress
	SPI_transfer((address)); // adress

	SPI_transfer(receivedbyte); // data what you write in the ext. RAM

	PORTG |= (1 << PING5); // make SS pin = 1
	_delay_ms(2); // just for testing
}					
}
}

Met 9600 baud komt de data binnen met 1 byte per milliseconde.

Als je die binnen die milliseconde kunt verwerken dan zijn interrupts niet nodig en kun je alles in de mainloop afhandelen.

Maar dan helpt het wel als je de SPI wat sneller instelt met een kleinere prescaler, en je de _delay_ms(2); weghaalt.