PSoC™ Creator & Designer Forum Discussions
Hi,
not sure if this is the right forum place, my question isn't related to a given device, but the development tools, GCC in this case.
So, after working massively with PSoC4 and a bit with PSoC5, I wan't to dig deeper into the GCC tools. I'm coming from the 8051 world, where it was easy to check the generated assembler code if it was blown unnecessarily. Also the map file was relatively detailed regarding memory location of a given variable or checking the overlay mechanism for local function variables.
Now, how can I get this for the Cortex-M0/M3 devices? Regarding the assembler code, it seems that the generated LST files are the right place, right? They're not always easy to read, but I assume this is getting better with experience.
The MAP file makes more headache, it doesn't give me the informations I expected based on my experience with 8051 map files... So, the question is: is this related to the different memory architecture or is there simply a linker switch which outputs more details? For example, the 8051 map file showed up the memory type (which doesn't exists on a Cortex-Mx device due to the linear address space), the address, etc., but I can't find those informations for local function variables, only for globals - is this because global variables are created on the HEAP, which is dynamic?
And the third question: let's say I wan't to create an assembler only project to get knowledge of the instruction set, how can I create such a project?
Regards,
Ralf
Show LessHi All,
I shamelessly modified the stock SPI master 2.40 component in the catalog to support large DMA transfers more easily. The only reference I could find to send data via SPI and DMA was to use the interrupt line and then an indexed DMA to clear the interupt flag (CE56273). Probably there are other solutions but I did not come across them in my short search.
This method seemed complicated as I have a 4kB frame buffer I want to repeatedly send to a display without worrying too much. Thus, I added two lines of verilog to the Base Spi component:
output wire tx_drq //in the module descriptor for module B_SPI_Master_v2_40_DMA just to indicate an extra output
as well as:
assign tx_drq = dpMOSI_fifo_empty;
All this does is bring out the FIFO empty signal to make it accessible to a level sensitive dma component. There is an extra pin brought out for the base and the master component. All the rest is left the same. Attached you can find the workspace with the custom components.
It is happily transfering 4096 bytes across to my display now (which is so annoyingly one byte larger than one TD can handle!). This project is for a psoc5.
Any input is appreciated.
Show LessMaybe it's a new bug or maybe this is how it's been all the time. I did a search in the forum but nothing showed up.
So I have a project and I do a "Select Device", when the window pops up, I apply filters to narrow down my choices of chips.
Once I'm happy with my filter I click the "Auto Select" button so it will check what devices will support my project.
I wa expecting that it will only check for the devices in the list after the filters are applied, but it checks all of them regardless of the filter. Meaning that It can take a long time until it checks all of them so I can figure out the ones from my list.
After 30 minutes it's just done with the PSoC 3 devices and I had them filtered out. It might take another hour or more to do them all.
Is this the intended way to operate or is it a bug?
Thanks.
Show LessI have a CY8C3866 project using the standard 2x16 parallel char LCD (on port6) & a number of other components working fine on TQFP-100 part 030 board. I've copied that project and am trying to remove the LCD, replace with an I2C panel that I have all drivers for & is working fine in other projects, and change to the 64-QFN. Both projects are in the same workspace (Creator 3 comp pack 7/Win7 Pro/ i7). I copy the project, rename, select the 64-QFN device, delete the parallel LCD from the code and TopDesign, add I2C fixed master to the TopDesign. The old LCD will not leave the pins view, the new I2C master will not show up in the pins view. A clean build does not correct. I know if I start a new project from scratch this will all work fine.
I have never run into this before on a copied project within the same workspace. What am I missing?
Thanks - Steve
Show LessWe share the same source code over several different PSoC devices (PSoC 3 and PSoC 5) and use a varying amount of features. For some debug functions, I would like to test (precompiler - #ifdef) if in the current project a given resource is available. For instance, whether Port3 or Port 5 exists (on the package of course, I understand that the registers and hardware might be even there, just not externally connected), would be useful to a debugging tool that displays the status of each port.
cydevice.h and cypins.h define all the registers, I have checked also in designs that use a package where those pins don't exist.
I think the fitter must have a knowledge base for each device/package?
There is CYDEV_SRAM_SIZE and CYDEV_EE_SIZE, so for some resources the software can find the sizes.
But for instance,
CYDEV_IO_PC_PRT5_SIZE 0x00000008u
for a CY8C3866LTI-067, the 48 pin QFP package, that does not have port 5.
Andreas
Show LessHi,
In my program I write and read to and from PSoC5 EEPROM.
But during read I found unexpected values. The problem is now that I don't know if the Write or the Read is going wrong. For that reason I want to inspect EEPROM to see what was written.
I search everywhere but could not find how to inspect EEPROM memory during debug.
Please help!
Thanks!
Rob
Show LessI have a custom board with PSoC5 using USBUART. In the past, I got this board version working and enumerating just fine. Today, I pulled out a second board made at the same time as the first one. I programmed the PSoC5. I inserted the USB plug into my PC, and things aren't behaving.
Specifically, in Device Manager I see the board identified as "Unknown Device". I tried to update the driver, providing my ...Generated_Source\PSoC5 folder name. Windows told me the driver was up-to-date. Nevertheless, it's not installed properly. The driver is from Microsoft, date 6/21/2006, version 6.1.7601.18328.
Meanwhile, I still have the original board that works. I plug its USB cable into my PC and it comes up just fine as COM9 in the Device Manager. It says it's using a driver from Cypress, date 3/5/2007, version 2.0.0.0.
What step did I forget? How do I force windows to use the Cypress driver?
I'm using Win7 SP1, 64-bit, 32GB ram, Intel I7-2600 3.4GHz
Show Less