Maximale data in PIC

1920/8 = 240 bytes.

Dat gaat dus niet passen in 128 bytes RAM.
Gebruik een PIC met meer RAM geheugen, je programma zal ook nog wel wat RAM geheugen nodig hebben, een 16F866 bijvoorbeeld.

@Jowi

Bedankt voor je reactie, maar dat het daar niet in ging dat begrijp ik. Maar wat is die 2K dan?

Een woord is bij de 16F serie 14 bits, dus 2K woorden is 3.5 kByte. En dat is FLASH (programma) geheugen.

Vandaar...
Nou, begrijp ik ook weer hoe ze daaraan komen.

Even dat ik het dus op een rijtje heb:
Je programma komt in de ROM (FLASH) te staan.
Hieruit kan de variable maken of een code block in je RAM.

Het 'draaien' van het programma, gebruikt hij daarvoor ook nog RAM?

Ja, voor ondermeer de stack ed.

Dus als ik nu al weet dat ik 240 bytes nodig heb, dan is het niet handig om 256 bytes te nemen. Dat is vragen om problemen. Lijkt mij erg krap dan.
Klopt dat?

Lijkt me idd krap. Als je bv patronen wilt opslaan die je naar je ledkubus wilt sturen zou je ook een I2C eeprom aan je pic kunnen knopen.

Roland, Het zou best kunnen dat de PIC een hardware-stack heeft (voor de call-return). Die zit dus niet in RAM.

@Roland

Er komt verder geen patroon oid in te staan. Het word een iets grotere kubus. Dit is slecht 1/8e van de aansturing. Er komt een processor die verantwoordelijk is voor de patronen en communicatie met een (BV) PC.

Het beestje dat net werd voorgesteld heeft volgens de datasheet:
• 8-level deep hardware stack

Dus dat komt er niet bij dan. Maar het is dus uittellen wat er word ingenomen door timers of variable ed.

Kunnen jullie miss wat aanraders geven? Ik ben via farnell alvast wat aan t opzoeken.

knoop er een sram met 2 schuifregisters (74HC595) of tellers (74HC590) voor de adressen aan.

Hey,

Dat is ook een mogelijkheid ja, maar zou het niet makkelijker/mooier of goedkoper zijn om een ander PIC te nemen?
Ik zit te denken aan:
PIC18F24J10

1024Byts RAM.
16K Flash
21 I/O
40MHz

Ik vermoed dat dit dan 'netter' is dan extra chips te gaan plaatsen.

Hij is te verkrijgen als through hole en als SMD. Dus makkelijk oefenen en ook in te disgne als smd print

Zelf vind ik het juist netter om een extern geheugen te gebruiken (bijvoorbeeld een eeprom of flash) dan om programmacode te gebruiken om veel data in op te slaan.
Als je de patronen extern opslaat kun je ze later ook mooi vullen via bijvoorbeeld een USB poort (of serieel). Een I2C EEPROM is erg klein en er kan behoorlijk veel data in, je hebt ze geloof ik al in 1MBit.
Verder bestaat er ook I2C RAM geheugen. Op 400kHz kun je daar behoorlijk snel uit lezen. Je kunt er vaak een hele pagina tegelijk er uithalen, dan heb je de overhead niet van steeds het starten, adresseren en stoppen van de communicatie.

Daar komt nog eens bij dat een I2C EEPROM maar een paar cent kost, zo'n grote PIC kost een paar euro.
[edit]Ik zie net dat de genoemde PIC ook maar iets van 2 euro kost[/edit]

Ik begrijp je punt. maar...

Het is een kubus van 8*8*8 RGB leds.

1PIC stuurt 64 leds aan. (in totaal 8 PIC's)

In 1 PIC staat een code block waarin de kleur van iedere LED is vastgesteld. De taak van deze PIC is om continu de leds aan te sturen met de data die hij heeft staan.

Een Processor waar ik eerder mee heb gewerkt zal de patronen maken en iedere PIC via UART of SPI (oid) 'vertellen' welke leds van kleur veranderen.

Door deze manier kan ik een programma maken dat het flikkeren van de kubus uitsluit. Dus het lieft 1 PIC dat dit kan. (met 3 externe MUXen)
De PIC zal ook een software PWM uitvoeren om de RGB-leds van kleur te doen veranderen.

Vandaar dat de variable die ik maak 64(leds)*3(R,G,B)*10(bits voor PWM)=1920 bits

Maar...
Even hardop denkend voor de mensen die me nog volgen ;P

Ik stuur 1 8bits code op per led. (dit is vanaf de processor naar de PIC)
Dit sla ik op. Hiermee heb ik maar 64*8=64Byte nodig.
Die 8 bits code stelt de kleur voor. 2^8=256 Kleuren.
aan de hand van deze code kan ik bepalen welke kleur ik nodig heb en hiermee per pin (R,G,B) 10 bits gaan sturen. Dan hoef ik alleen nog maar de kleuren op te slaan. dit zijn 30 bits per kleur.

Geweldig zo'n forum. Hier kom je tot een hoop ontdekkingen

Op 16 november 2010 13:01:41 schreef rew:
Roland, Het zou best kunnen dat de PIC een hardware-stack heeft (voor de call-return). Die zit dus niet in RAM.

Dat zou niet alleen kunnen, voor de meeste PICs (10F, 12F, 16F, 18F) is dit ook zo.

Maar een programma gebruikt altijd ook nog wat RAM voor parameters, temporaries, etc.

Neem een 16F1936. Is volgens mij zelfs pin-compatible, en kost maar een paar dubbeltjes meer.
Heeft 14k flash en 512 bytes RAM (dus beide 4x zo veel), en ook nog 256 bytes eeprom.
Ook de clock is max 32MHz ipv 20MHz...

@arco

De PIC die ik voorstelde:
PIC18F24J10
Heeft:
1024Byts RAM.
16K Flash
21 I/O
40MHz

Dus die lijkt me dan nog net iets beter
En dat voor 2 eur

@wouter
Dat is idd wat eerder al is opgemerkt. Daarom dat 256Bytes te krap.
De bovengenoemde moet goed zijn denk ik

Op 17 november 2010 10:38:16 schreef Marcel van Ede:
De PIC die ik voorstelde:
PIC18F24J10

Maar let op: die chip gaat maar tot 3.6V

http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en024621

Op 17 november 2010 10:38:16 schreef Marcel van Ede:
De PIC die ik voorstelde:
PIC18F24J10...

Ik nam aan dat je in de 16F familie wilde blijven. Dan is de 1936 de beste keus... (Is ook 5 volt)
Alle 'J' pics zijn 3 volt, voor 5 volt de gewone gebruiken (18F2410)

Bedankt Wouter, maar dat had ik gezien. De ingangen zijn volgens de datasheet wel 5V bestendigd.

De 1936 zal ik gaan opzoeken. Zoveel ken ik er niet.

Bedankt voor het advies van allen