PSoC™ 4 Forum Discussions

The application is streaming audio from a PC across UART and having PSoC4 buffer it... and simultaneously send this stream to it's I2S output peripheral.

I am interested in having a host PC send blocks of 220 bytes into a receiving PSoC4 UART @ 500Kbps every 10ms. This means there is a time gap between the bursts of 220 bytes.

Then this buffer is output to I2S @ 384Kbps.

I assume DMA is the best, but I tried to set the Rx buffer size of the UART to 220 and it will not allow DMA support with this buffer size. However, the 'Number of data elements to transfer' of the DMA component can be set to 220. Should they match each other?

There is no 'Buffer size' setting requirement for the I2S. I simply set it's connected DMA data elements size to 220 and point to a static buffer with 220 elements. Why is a 'Rx Buffer Size' needed for the UART?.. and why can it's largest size only be 16?

Can this streaming data "bit rate modification" application be implemented totally in PSoC4 hardware, or is firmware required to alter the buffer address pointers for the UART, I2S and DMA blocks? If firmware is required, do I need to use 2 descriptors in the UART DMA block and 2 descriptors in the I2S DMA block... and cross ref their pointers in their interrupt routines?

Can a single DMA block be used with the UART connected as input and I2S connected as output?

Are there any examples of this scheme? I can only find a UART to/from memory 'terminal echo' example.

Hi,

I have a design in which CPU wakes up and waits for a digital pin state change. Immediately after that I2C write must be issued.

I have been reading SCB docs but still unsure what is the best way to achieve that. Wake pre-initialised SCB from sleep? 

Basically I have just two objectives:

1/ To make sure SCB master either idle or in a high impedance state all time except this short (one byte write) event

2/ Time between digital pin state change and the start of I2C transmission is as short as possible (say less than 100 us).

Code runs on CY8C4014LQI-412

All suggestions welcome (apart from the design change - it is set in stone).

Thanks,

Alex

Hi,

I have a question regarding CyBle_GapGenerateLocalP256Keys() funciton in Cypress BLE 3.30 module. If I never call this function my BLE device will use default P-256 Debug keys (can be seen from btmon in Linux when I connect that keys are of type "debug", this causes pairing/connect to take longer than with "real" P-256 keys). If I however generate local keys right after my stack has been initialized my BLE device will use "real" P-256 keys when I initiate a pairing (and not the debug keys). But every time my BLE device wakes up from Hibernate (=boots and generates keys again) and gets connected (not even creating new pairing, just re-connects to old pairing) it will now write data to Flash. When I do not generate the keys at all (and use default debug keys) the device only writes to flash ONCE, right after I create a new pairing, never at subsequent re-connects, just as one would expect. Why does GapGenerateLocalP256Keys() cause a new write to flash every time I connect back to my already existing pairing? Nothing in the pairing has changed, I can see from btmon in Linux that the same old keys are still used even if my BLE stack generates new keys every time it boots (as I understand these newly generated P-256 keys will only be used for new pairings, they do not affect old pairings already stored in flash, as seems to actually be the case)

Clearly the generated P-256 keys themselves are not stored in flash, as I already tried writing a flag to user space flash memory after successfully calling GapGenerateLocalP256Keys() and at next boot read this flag and never again generate any new keys if flag was set (indicating local keys was once generated). All this ended up doing was that it defaulted back to the default P-256 debug-keys at subsequent boots, indicating my previously generated keys were not loaded into the BLE stack at boot and neither can I find any API documentation about how to specifically load stored keys from flash into the stack. (Here I am assuming it is the newly generated P-256 keys that gets written to flash at every connect, but it is of course unclear exactly what is being written into flash, but they keys are the only thing that have changed at every boot, since I am not making new pairing, just re-connecting to same old pairing)

I.e. what is the reason the BLE stack wants to write to flash at every connect done after the GapGenerateLocalP256Keys() function has been called?

Hi All,

I'm using the EZ-BLE modules CYBLE-214009-EVAL and CYBLE-014008-EVAL with CY8CKIT-042 PSoC® 4 Pioneer Kits.

I'd like to scan for any/all I2C devices connected to my device, similarly to the Arduino project "i2c_scanner" (http://playground.arduino.cc/Main/I2cScanner).

Each module has identical code (apart from the I2C address) utilising an SCB Multi-Master-Slave component, when one module is triggered it should scan all I2C addresses and note any successful scans.

I've used a modified (with UART printfs for debugging) WriteCommandPacket() function from the SCB_I2cCommMaster code example.

So far my methods have involved looking for error codes from WriteCommandPacket() and I2CMasterWriteBuf(), but I've not been successful

So my problem is that I don't know the best way to test an I2C address with the aim of determining its presence. My ideal function would be something like:             uint8 TestI2CAddress( uint8 address )              which would return boolean type values( 0u/1u ).

Can anyone suggest the best way to achieve my objective please?

Thanks,
George

hi every body,

if anybody works on this. can i get details?

when i used 89xx uc. there INTRINS  extern unsigned char _crol_    (unsigned char, unsigned char); viz.

temp=_crol_(temp,1);/*Shift D7 BIT TO D0*/
SDA = (temp&0x01);/*SEND D0 BIT TO SDA*/

or how to implement this function.

Hi, 

My application for multiple time cc events used.

I wish used a same timer resource, it means that I write a compare register value to generate cc event interrupts when timer count reach the compare register, in the mean time, the timer does not stop, keep running and enter interrupt service routine, then firmware change compare register to a new value , new value is great than old (example it is a up counting mode), after clear interrupt return to main routine, wait for reaching  next compare register value then CC event happened. The new value is enough to process interrupt service routine. 

Is it workable ?