PS : I'm using PSoC 4 Pioneer kit.
1. PSoC4 only has max. 32k flash and 4k RAM, not a lot. Are you sure you it is enough for your project?
2. What kinds of EEPROM you want to interface, there are normal byte wide and serial versions as well.
3. You can post your requirment here so we can help you to see if the chip is good enough for your project.
Basically you can connect any EEPROM which uses a serial interface (SPI or I2C). Which one to choose depends whether one of these interfaces is already occupied in your solution. Apart from that, choose whatever fits your needs.
What is 'a vast amount of data'? Could it be that a PSoC4 is not the right tool for your problem, and maybe a PSoC5 would be more suited?
You should think about moving parts of your algorithm into the PSoC hardware (UDBs) - this makes it faster and consumes less CPU resources.
If you describe the basic application the forum can potentialy guide you to
the right family.
Your blink LED project, was it FLASH or SRAM consumed you feel was excessive ?
The release of Creator 3.0 changed the way SRAM is reported -
I am trying to make device to detect and store IR message packets from different remote controls. To make it compatible with the numerous data formats, I want to detect the rising and falling edges in a packet, which translates to storing 60-80 32 bit values from a timer, and I want to store atleast 15-20 such packets in my device.
I assume that I'll need a serial EEPROM, because I want to quickly store the rising/falling edge so that I dont miss the net edge. Also, I may need to interface a keypad and screen at a later stage if project, so I may need EEPROM to store data as well as code memory.
Thanks to all for the prompt reply!!
Some thoughts about your design:
Having a timer resolution of 32 bits @ 48MHz would give a time of max 90 seconds with a resolution of about 0.02µs. I think that 16 bit resolution would be sufficent.
Writing to eeprom between two edges will not work since the required time can easily be in the range of some ms.
Solution can be: Buffer a single complete sequence to sram and when verified store to eeprom.
Reverse this when a sequence has to be played: from eeprom to sram and then play.
Try to estimate the number of pins needed for your display + eeprom + keypad so that you will not exceed PSoC4's pincount.
You might look at serial NOR FLASH, write times, 256 bytes, 5 mS for the page.
100K erase cycles limitation typical however.
Or FLASH/RAM combo parts.
1. As most IR using the Philips or the NEC protocol, would it be easier to decode the IR code and store the code rather then the pulse train?
2. If you want to make a learning remote and with a simple character LCD display , PSoC4 should be OK and you can use the EEPROM emulator to store the IR code.
3. The good thing about PSoC series is if you need a bigger chip or more resources, you can switch to PSoC5 and port your project across with little or no change to your project.
Yes, I thought of decoding the NEC or philips format and then storing the data in the memory. Because of the vast number of formats available i was wondering if this could be a better solution.
Well, the two format would be the most commonly used. Storing th raw timing may be the only solution for 100% of every format.
Again, you should be able to use the EEPROM emulator on the PSoC4 to store the data.