I've found those registers in this documentation: https://developer.arm.com/docs/ddi0487/latest So far this is the best description on the net, but like any other arm doc, it's not 100% perfect. Most notably the summary tables are often wrong. Still I would recommend to use that.zedrummer wrote: ↑Wed Jan 10, 2018 2:30 pmThank you Scotty for the advice, but I'd like to remain in the Bare-Metal side, not sure the libs are useful so, are they?
I will try your solution bzt, I have several questions on it.
- For your wait_msec: I was not aware of coprocessor registers like CNTFRQ_EL0 and CNTPCT_EL0, I have read http://infocenter.arm.com/help/index.js ... DFGH.htmll that seems quite ambiguous about the frequency. Is CNTFRQ_EL0 in MHz ("typically in MHz") ?
Yes as long you use one implementation in your code. If you implement it in two places, then there could be differences, see dwelch67's detailed answer (first implemetation in L1, but second only in L2 for example, or the first on an instruction cacheable page and the 2nd on a non-cacheable page etc.).
You're welcome! Sorry I couldn't provide more details, only theory.
You need to understand when switching PINS very fast they have capacitance and the pins have limited current drive typically in mA. It comes under the description Parasitic capacitancezedrummer wrote: ↑Thu Jan 11, 2018 6:25 amSorry your sentence "I also warn you that the GPIO pins don't have enormous drive at those frequencies you will need to take proper care to get them off the board to another board." makes no sense for me, what is the drive you are talking about and how to take care?
Initially the waveforms will start to round off edges, eventually you will end up with a thing that looks like a triangle wave and it wont reach a level it will trigger your connected circuit in the TLC5940.At low frequencies parasitic capacitance can usually be ignored, but in high frequency circuits it can be a major problem
The maximum fan-out of an output measures its load-driving capability: it is the greatest number of inputs of gates of the same type to which the output can be safely connected.
If you don't have access to a oscilloscope I would start other way, test it all at slow speed and get everything working and then start reducing the delays until you get to maximum or something breaks. A couple of hundred nanosecond pulses shouldn't be a problem.
Sure I have demonstrated this many times, in the pi the execution speed of that loop or even simpler without the nop, can vary by 20x or more. A fair amount of that you can control but timed loops dont work well on cores with pipelines like these, against caches against dram. (by definition no instruction takes only one clock cycle, the pipe and other features attempt a desire of an average of one. its like if you see a new car come out of the factory door every minute doesnt mean it takes a minute to make a car. same exact thing is going on here).Really interesting and extensive answer.
In my case, it is just a loop with:
Could it really change from one time to another ?
Users browsing this forum: No registered users and 5 guests