I'm fairly new to the PSoC architecture so I expect some frustration learing a new part. I've programmed PIC, Intel, Zilog, and Motorola microcontrollers in the past and they all have their learning curves and documentation issues. This is not a slam in any way as I'm just pointing out something that created some confusion to me when learning this device.
I'm working on a program that uses the SCB UART funtionality on a CY8CKIT-049-42xx board. so I was poking around trying to learn the register locations. I see on page 23 of the PSoC 4 Architecture TRM (Rev C 3/25/2014) that there are two SCBs. When I look at page 50 I see that the SCB registers are mapped to addresses 0x40060000-0x4006FFFF. I then go to the PSoC 4 Registers TRM (Rev A 6/25/2013) to actually look at the individual register definitions and I see the registers mapped in that address space, but there is no indication of two SCBs. So I compile a simple program in PSoC Creator and I hunted around in the include files and find that in the cydevice_trm.h file the SCB1 register address map appears to be 0x40070000-0x4007FFFF. This range is not even defined in the PSoC 4 Architecture TRM.
While I'm OK with finding this information out in a rather reverse engineering way, it would be a lot clearer if the documentation was updated to reflect the full picture especially with regards to registers in the device. I would rather not have to rely on compiled code to understand the register mappings. If I missed some errata document out there my apologies, and I would appreciate a link to it for my documentation collection.
I do like the PSoC devices though and look forward to using these devices in future projects.
Consider filing a CASE and supply a link to your post.
Hopefully that should bring attention to the TRM update
To create a technical or issue case at Cypress -
“Create a Case”
You have to be registered on Cypress web site first.
Welcome in the fascinating world of PSoCs!
That is a major difference between PICs and PSoCs with Creator: You do not have to care for register addresses.
When you build a project that uses components (as nearly every project has got) some C-language files are generated with the APIs and the internal handling which you may open to look at the way Cypress's engineers handle that. Moreover a process named "Fitter" could decide from time-to-time to use different hardware resources for optimization purposes which changes the involved registers and the associated files generated.
Especially when you are new to PSoCs: Start "Thinking PSoC". You may solve problems in hardware, in software or in a combination of both. How much hardware and how much software is up to you and is an individual decision. Even "Generating" new hardware using HDL is possible, when you like.
Thanks for the pointer Dana, I opened a case with Cypress Technical Support just now.
Yes Bob it is a new world being introduced to an old world engineer .
I cut my teeth on the Intel 8048 microcontroller many years ago - a different world back then for sure (and no I don't want to go back to those days.) I am somewhat getting and embracing the concept, but my brain is wired to understand what is really going on under the covers. I'm sure there is coming a day when I need to fit 10 pounds of programming poo into a 1 pound PSoC box and clever techniques will have to be utilized that require a somewhat intimate knowledge of the architecture to make it happen. At least that is what has happened to me in the past. I do like what I see so far, but trust has to be earned and I'm not at that level yet.
The actual state of the component collection from Cypress is rather trustworthy. When you follow the history at end of the datasheet you can see that there haven't been essential changes lately. Except the brandnew BLE which needed an update recently, the complete framework looks rather stable.
I admit: there is a lot to learn about PSoCs, but the kits come in handy and you find an example for nearly every component. Datasheets for the components are just a mouseclick away and all are structured similarly, easy to find what you are searching for.
8048? I think we both are of matchable age, although I started on an IBM360/370 😉
When you really really want to use registers (in rare cases the needed functionality is not exposed by the component API) then use the provided DEFINEs for the registers instead of the absolute address. As Bob said, PSoC Creator might change the resource assignment (e.g. due to what the external pins are).
But its even better to use the provided components, since they provide a higher level API (and are just much easier to use).
I think for SCB1 the address is correct, When you have a project with SCB0 used, you will see that it indeed starts at 0x40060000 (or just check cydevice_trm.h, that has all peripherals).
That should be described a little bit better - the register TRM only shows the set of registers for the first component if there are multiple, and the other follow with a certain offset. When you need them, the cydevice_trm.h has the base addresses for all instances (and their number might differ by the actual chip used).
If you want to use register addresses, or pointers to them, the
HW mapped registers are safe to use, as their addresses do
Register adressing can be useful in configuration updates and
saves that span several registers, especially if addressing sequential
as you know. Results in tight simple code.
As pointed out earlier the register defines are safest to use.
I didn#t want to imply that the register addresses can change (although they can when switching e.g. between the different PSoC4 families). But what can change is the resource assignment. E.g. when using a TCPWM which one exactly is assigned for you might change in subsequent runs, and then your registers are the wrong ones. Thats why you should always use the DEFINEs generated by Creator.
Thanks all for the interesting discussion. While it is nice to know register locations for direct access at times I definitelty understand the importance of using the #defines whenever possible. Even though the #define names are fairly straight forward I still find myself working backwards though the include files from the register address to identify what #define is the one I should be using, and that again requires a good document that lists all of the register mappings for the part.
There are 2 SCB blocks in PSoC 4. SCB0's registers are mapped to 0x40060000-0x4006FFFF and SCB1's registers are mapped to 0x40070000-0x4007FFFF.
But the PSOC 4 register TRM has information about the SCB registers at 0x40060000 - Page-337
But it doesnot specifically mention about SCB0 or SCB1.
Also, in the cydevicetrm.h, you can see the following defines,
But I will ensure that I report this to the respective team to correct this.