- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I cannot suggest to use assembly for ARM processors. The availlable C-compilers are optimizing pretty well and the 3-address-assembly is rather complicated. Can you be a bit more specific and tell us what you would like to perform with assembly-code that will not work in C?
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Many thanks Bod and Dana for the tips. Now I search/test the ways how to set/reset single or multiple PSoC4 IO pins as quick as possible. Cypress API library works OK, but I hope that for digital/time measurements quicker solution may exist. Regards, Viktor
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
.... There are two possible reasons why you want to use assembly language.
- First is, that C is limited when we are getting closer to the hardware. E.g. there's no C statement for directly modifying the processor status register.
- The second reason is to create highly optimized code. No doubt, the C code optimizer does a good job, but the results are far away from handcrafted assembler code.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, Dana the AN72382 is really nice source of information.
I have collected some experimental data from real PSoC4 measurement. The project including with data as comments in main.c attached as Achive.
I can not toggle the IO pin on higher frequency than cca 300 kHz. Is is normal or there is an embedded mistake .......
Regards, Viktor
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Problems with file atattchment ....
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you are doing this in ASM, look in TRM and count cycles needed by
code to toggle, and translate to speed for the clock rate you are running
CPU at.
If in C, look at .lst file for code generated, again counting clock cycles.
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Some people are having problems posting with Chrome, try
Firefox, IE.
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Although your top schematic does not show this I assume you
have a 10 - 50 ohm R in series with clk pin and external source
of clk ? If not look at with fast scope, low C scope probe,
you will see a lot of ringing, over and under shoot which may be
mis-clocking CPU core.
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You are using Pin_1_Write(1) and Pin_1_Write(0) APIs, C,
take a look at code generated in Pin_1.lst file, and you can
see the code generated.
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The fastest way to toggle may be using hardware, a FF with master clock as clock. But it all depends what is it used for.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, H L sure nice idea, but it is not programmable .... Viktor
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, Dana
Many thanks for your recommendations.
1. Adding the 24 ohm series resistor between the output of the quartz oscillator and PSoC4 P0[6] => no frequency difference
2. Long time (2 hours) 40 MHz quartz oscillator frequency monitoring stable mean frequency 39.9999825 MHz +- 25 Hz maximum
3. Adding 10 microfarad tantalum to oscillator power supply => no frequency difference
4. My digital oscilloscope is not excellent, but long time frequency monitoring with digital counter at PSoC4 dedicated output pin P2[0] - ExternalClock is very stable
5. All PSoC4 toggle IO pin frequencies are very stable, many times verified. (Within +- 1 Hz due to the counter time base stability, 1 second time interval).
Regards,
Viktor
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
My point about looking at .lst file is there is more code needed
than just a direct register write, eg elimination of stack push and other
stuff API is using. Look in TRM for the register name, and use direct
writes to it. Register name table below.
The series R will allow you to meet input over/undershoot specs, otherwise
you are pumping a lot of charge into substrate, and can get unpredictable
results. So allways use an R to mitigate PCB trace L effects, especially
on high speed paths.
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You are right - a pure DFF is not programmable. But there are these niftly little things called UDBs, with their Datapaths in them. And they are programmable indeed...
So if you can tell us what you want to achieve, maybe we can give you some ideas how to do this in a better way. You know, the slogan is 'MCUs can't, PSoC can' 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
HLI and Dana .... You need not apply the slogan is 'MCUs can't, PSoC can' small C code optimisation is sufficient for big results.
1. I have changed the platform to PSoC5LP on CY8CKIT-050B because the perfect PSoC5LP Registers TRM PDF file is available.
2. I have changed the compiler, now I use Keil ARM MDK version 4.71a
3. The changes are significant. Using the PSoC5LP running at 66 MHz derived from the onboard 24 MHz quartz, the IO togle frequency is as high as 10.666662 MHz. Compared to maximum from previous post using PSoC4 running on 40 MHz external oscillator cca 300 kHz .....
4. Project with results mentioned in main.c comments included
5. Next results in comming days ....
Regards,
Viktor
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I suppose a much higher frequency could be obtained ba connecting a 24MHz clock directly to an output pin gated with a control-register or a LUT-state-machine if you like. No CPU needed
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, all
Additional information ... from testing
1. Back to the PSoC4 - CY8CKIT-042 platform running from 40 MHz external oscillator.
2. Using Keil ARM MDK compiler version 4.71a
3. IO togle frequency is as high as 3.855420 MHz which is more than 10x higher compared to my previous post using GCC compiler
4. Project with results mentioned in main.c comments included
5. Next results in comming days ....
Regards,
Viktor
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Bob,
" ...I suppose a much higher frequency could be obtained ba connecting a 24MHz clock directly to an output pin gated with a control-register or a LUT-state-machine if you like. No CPU needed. Bob ...*
Nice idea, but not for my purpose. I need a quick and versatile IO pin state control under programmable overhead. Usage for NONSTANDARD interfaces, data convertors etc.
Regards,
Viktor
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Actually what you are describing ("nonstandard interfaces") is exactyl what the UDBs and the data path are designed for... Sure, given a fast enough CPU core may allow you to handle it in software, but it will be more difficult and sensistive to other parts of your software than doing it in hardware.
But as long as we don't know what you want to do exactly we can only guess...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nice to hear that you have solution to your problem.
But just wondering if a counter/timer would have higher speed in this case? And it is programable.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Bit banging is the choice when having a CPU with some power and you run out of hardware.
Thinking PSoC is a bit different from that !
The USBs Hli mentioned (I do not know if you got informed, so I repeat) are programmable ALUs with shifters, masks, registers, two FiFos and everyting running independently from main-CPU. Additionally the UDB-resources can be used to program some hardware in VeriLog and building own usermodules that run REALLY fast.
Some of the I2C-implementation have been made (by Cypress) using UDBs and they use bit-banging without the need of the CPU.
So "Thinking PSoC" could make things real without stressing the CPU
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Last testing ...
void main()
{
Pin_1_DR |= 0x01; // = PSoC4 pin_1 => P0[0]
CyDelay(1000); // = GCC 4.4.1 Compiler instaled from "PSoC4.ISO"
Pin_1_DR &= ~0x01; // = CY8CKIT-042 running at 40 MHz from external oscillator
// = IO P0[0] pin frequency PSoC4 CY8CKIT-042
while (1) { // = IO P0[0] pin frequency 1.666666 MHz SPEED optimised
Pin_1_DR ^= 0x01; // = IO P0[0] pin frequency 1.249999 MHz SIZE optimised
} // = IO P0[0] pin frequency 1.052631 MHz NONE optimised
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What is driving the need for high GPIO pin toggling rate ?
What are these pins being used for ?
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content