This mode could benefit from a means to launch many pins at the same time.
eg Suppose someone wants 5 pins with pulses of 1,2,3,4,5us, all starting on the same SysCLK, how do they do that ?
This mode seems to have dynamic range to burn, so the rule of use X=1 for critical edge control seems ok, for single pin leading edge delay issues ?
We could make it so that the internal state logic freezes when the A-input is low. Setting the A field in PINSETM to %0100 would select OUT. Once all the pins are configured, set all the OUT bits high at once in software. Then, they will start all at the same time.
We could make it so that the internal state logic freezes when the A-input is low. Setting the A field in PINSETM to %0100 would select OUT. Once all the pins are configured, set all the OUT bits high at once in software. Then, they will start all at the same time.
This mode could benefit from a means to launch many pins at the same time.
eg Suppose someone wants 5 pins with pulses of 1,2,3,4,5us, all starting on the same SysCLK, how do they do that ?
This mode seems to have dynamic range to burn, so the rule of use X=1 for critical edge control seems ok, for single pin leading edge delay issues ?
We could make it so that the internal state logic freezes when the A-input is low. Setting the A field in PINSETM to %0100 would select OUT. Once all the pins are configured, set all the OUT bits high at once in software. Then, they will start all at the same time.
Yes
A means to control multiple pin cells for Start (for pulses, or SW capture) or Arm (for Pin capture) is a great idea.
This mode could benefit from a means to launch many pins at the same time.
eg Suppose someone wants 5 pins with pulses of 1,2,3,4,5us, all starting on the same SysCLK, how do they do that ?
This mode seems to have dynamic range to burn, so the rule of use X=1 for critical edge control seems ok, for single pin leading edge delay issues ?
We could make it so that the internal state logic freezes when the A-input is low. Setting the A field in PINSETM to %0100 would select OUT. Once all the pins are configured, set all the OUT bits high at once in software. Then, they will start all at the same time.
Yes
A means to control multiple pin cells for Start (for pulses, or SW capture) or Arm (for Pin capture) is a great idea.
On further thought, using the A-input is overkill and even conflicting in some cases. All we need is the OUT bit for that pn. If OUT is high, state is frozen. This could work for all smart pins modes which override OUT. It would allow synchronization of many pins. I'll add that tomorrow. Indeed, this was something missing.
I am on Windows 10. I have to tell pnut every time which com port to use.
Then I have to do a Ctl-G to identify the port.
Now I can do a successful download.
Sometimes I can repeat this process to download again. Other times it locks and I have to unplug the com port and then "End Task". If I don't remove the com port (propplug) pnut locks and I cannot perform an "End Task" (using Ctl-Alt-Del task manager).
Chip,
Any chance of open sourcing PNut? I'd like to have a shot at porting the Delphi code over to FreePascal. Part of porting process is modifying the comms code to use a proven cross-platform unit - Hopefully fixing the Win10 issues as a bonus.
I am on Windows 10. I have to tell pnut every time which com port to use.
Then I have to do a Ctl-G to identify the port.
Now I can do a successful download.
Sometimes I can repeat this process to download again. Other times it locks and I have to unplug the com port and then "End Task". If I don't remove the com port (propplug) pnut locks and I cannot perform an "End Task" (using Ctl-Alt-Del task manager).
Running Pnut on two Win10 machines with no problems.
Not sure on that one Ray, maybe FTDI driver?
I am on Windows 10. I have to tell pnut every time which com port to use.
Then I have to do a Ctl-G to identify the port.
Now I can do a successful download.
Sometimes I can repeat this process to download again. Other times it locks and I have to unplug the com port and then "End Task". If I don't remove the com port (propplug) pnut locks and I cannot perform an "End Task" (using Ctl-Alt-Del task manager).
Running Pnut on two Win10 machines with no problems.
Not sure on that one Ray, maybe FTDI driver?
Me too. I used the latest PX.EXE to load my 1-2-3-A9 board with Chip's latest image and used PNut-v8.exe to load the LED blinking demo and had no problems on my Windows 10 laptop.
Chip,
Any chance the 8 smart pins could be on pins 56-63 for the De-nano ?
The prop plug used for programming/downloading is on P62/63. The downloaded code cannot use the UART on the same P62/63 pins, so another prop plug is required on P0:7.
From your example, Pulse is really a one-shot pulse, with Prescaler.
Pulse Formula is tPW = Y * X/(SysClk),
Shortest pulse is X=1,Y=1 => 1/SysCLK
Longest is ( @80M) ((2^32-1)*(2^16-1)/80M)/60/60 = 977.3287558 hours ?
Thinking some more about this Pulse Mode,
Q: Would the X field be more useful as a leading edge delay, than as a prescaler ?
ie Changes Pulse Formula from the above tPW = Y * X/(SysClk), to :
tPW = Y/(SysClk) // Pulse HI time, 32b range
tD = X/(SysClk) // Leading edge Delay time, 16b range
I can think of designs that would use multiple pulses, sync'd (Chip is now fixing that), and with adjustable widths and delays.
It is harder to think of a project that needs 977 hours, to 48 bits of precision, but there may be one somewhere
Addit: The same question may apply to NCO Frequency
It is not clear if the NCO has any means now to set the start Phase, P1 allows this.
ie Does NCO need 16b prescaler and 32b adder, Should X << 16 become NCO start phase ?
NCO duty, I can see uses both ways, as in this mode, X sets the output pulse width.
These have timebase capture, with a nice lossless reset, and software capture (continual mode, no reset) but there seems to be currently no Pin-Capture ability ?
Can the B field be used for that ? B = x100 would select the Timebase.TC, for periodic, and other values are already pins, with polarity.
This would mean those modes that use both A&B already, would lack Pin Capture, but that is likely ok ?
(QuadAB, Time interval A-B, A++B--, )
I'm still looking at precision Duty Cycle measurements.
For this, you need to avoid partial cycle captures, so the information capture must be external signal sync'd, but it can also be useful to capture over many cycles of higher frequency Duty Cycle.
JMG,
A pulse time measurement more precise than the sysclock needs a timer that is more precise. You're asking for too much there.
?? Not sure where you got that from.
I do not expect better than SysCLK precision, but I do expect the smart pins to be able to work up to SysCLK precisions, and to work over multiple smart pins, and over more than one cycle of signal in.
For Precision Duty Cycle for example, a higher frequency Sensor signal may need 100 or 1000 or more whole cycles read, to give the needed precision. That is not complex stuff, but the details matter
With Chips latest improvements, this is almost there.
Chip,
Any chance the 8 smart pins could be on pins 56-63 for the De-nano ?
The prop plug used for programming/downloading is on P62/63. The downloaded code cannot use the UART on the same P62/63 pins, so another prop plug is required on P0:7.
IIRC the smartpins are on P0:P7 to align with the DAC's of Cog0.
For Precision Duty Cycle for example, a higher frequency Sensor signal may need 100 or 1000 or more whole cycles read, to give the needed precision. That is not complex stuff, but the details matter
The way to do that is to use duration rather than a pulse count. Mode 01100, Inc on A-High, covers that. The accumulated high time divided by the total sample period give the precise averaged duty.
Chip,
looking at these modes I'm thinking mode 10011, Time A-rise to A-rise, is extraneous as it's covered by mode 10100, Time A-rise to B-rise with both inputs directed at one pin.
The way to do that is to use duration rather than a pulse count. Mode 01100, Inc on A-High, covers that. The accumulated high time divided by the total sample period give the precise averaged duty.
This is why I said the details matter.
Your approach is simple, but can have overlap errors, as you get HI gate effects, but not the correct periods. Worse case is an Inc-on-high that has N+1 HIGH phases, and N low phases, which will give an incorrect too-high value for Duty.
That is why I underlined the whole cycles of Fin.
A simple Gated approach, is only of modest precision, certainly far less than the silicon could be capable of.
Chip,
looking at these modes I'm thinking mode 10011, Time A-rise to A-rise, is extraneous as it's covered by mode 10100, Time A-rise to B-rise with both inputs directed at one pin.
If Chip applies the suggestion I made above of %BBBB = x100 would select the Timebase.TC, for periodic capture.
Other values of %BBBB would capture A-Counts from the selected B-Pin edge
Then those modes 10011, 10100 are different.
I think in the Pin-capture case, the X value can apply similar rules, to Timebase Capture.
if %BBBB <> x100 then
X=0 would be Software Armed capture, one B edge per Software request
X > 0 would spread capture over X edges of B, allowing 100, 1000 etc Cycles of Fin to be used to expand precision, for simpler fixed range use, on one pin Cell.
The way to do that is to use duration rather than a pulse count. Mode 01100, Inc on A-High, covers that. The accumulated high time divided by the total sample period give the precise averaged duty.
Worse case is an Inc-on-high that has N+1 HIGH phases, and N low phases, which will give an incorrect too-high value for Duty.
For "duration" I didn't mean count pulses for a duration but rather the literal sample period of a PCM sample. Each sample is an accumulation of "A=true" in sysclocks. The average ratio of high to low is precisely represented in the sample. This is how bit-streaming works. Mode 01100 is a time accumulator, not a pulse counter.
For "duration" I didn't mean count pulses for a duration but rather the literal sample period of a PCM sample. Each sample is an accumulation of "A=true" in sysclocks. The average ratio of high to low is precisely represented in the sample. This is how bit-streaming works. Mode 01100 is a time accumulator, not a pulse counter.
I have not mentioned trying to measure a PCM sample, so I am still not sure what you think I am saying ?
To Expand:
Let's say I want to capture the Duty Cycle of a sensor that outputs in Duty Cycle mode.
The Period of such signals may vary due to RC oscillators, but the Ratio of Hi/Period, should be stable and valid over multiple signal periods. So measure of HI time alone, is clearly not enough.
You can try to extract Hi/Period values in one single cycle. but depending on the frequency and filtering effects, more may give better signal to noise and precision. The choice to use more incoming cycles, should be simple.
The point I have made, more than once, is that in order to keep precision, care is needed to do that measurement over whole incoming periods. (be that 100, 1000, 1024 or whatever)
The signal you are measuring becomes PCM once sampled from the counter when that counter is in time accumulation mode. Precision increases indefinitely with time. Each new sample is lossless.
Chip,
looking at these modes I'm thinking mode 10011, Time A-rise to A-rise, is extraneous as it's covered by mode 10100, Time A-rise to B-rise with both inputs directed at one pin.
There's some subtlety there. They are different because the first reports every A period, while the second must wait for A then for B, not for A, A, A,... If you used the second mode for just A, you would miss every other period.
Chip,
Any chance the 8 smart pins could be on pins 56-63 for the De-nano ?
The prop plug used for programming/downloading is on P62/63. The downloaded code cannot use the UART on the same P62/63 pins, so another prop plug is required on P0:7.
I could make 63/62/5/4/3/2/1/0 be the smart pins. That would work on both DE0-Nano setups.
Chip,
Any chance the 8 smart pins could be on pins 56-63 for the De-nano ?
The prop plug used for programming/downloading is on P62/63. The downloaded code cannot use the UART on the same P62/63 pins, so another prop plug is required on P0:7.
I could make 63/62/5/4/3/2/1/0 be the smart pins. That would work on both DE0-Nano setups.
This would be fantastic Chip.
BTW I just asked on another thread, do the smart pins -1/-2/-3 wrap from P0 to P63 etc. ie Icould use smart pins P0 & P1 both with -2 to access actual P62 & P63 pins respectively ??? If this works then this would solve my problem.
Chip,
Any chance the 8 smart pins could be on pins 56-63 for the De-nano ?
The prop plug used for programming/downloading is on P62/63. The downloaded code cannot use the UART on the same P62/63 pins, so another prop plug is required on P0:7.
I could make 63/62/5/4/3/2/1/0 be the smart pins. That would work on both DE0-Nano setups.
This would be fantastic Chip.
BTW I just asked on another thread, do the smart pins -1/-2/-3 wrap from P0 to P63 etc. ie Icould use smart pins P0 & P1 both with -2 to access actual P62 & P63 pins respectively ??? If this works then this would solve my problem.
Don't know about DE0 configuration, but the general design does work that way.
BTW I just asked on another thread, do the smart pins -1/-2/-3 wrap from P0 to P63 etc. ie I could use smart pins P0 & P1 both with -2 to access actual P62 & P63 pins respectively ??? If this works then this would solve my problem.
Comments
We could make it so that the internal state logic freezes when the A-input is low. Setting the A field in PINSETM to %0100 would select OUT. Once all the pins are configured, set all the OUT bits high at once in software. Then, they will start all at the same time.
A means to control multiple pin cells for Start (for pulses, or SW capture) or Arm (for Pin capture) is a great idea.
On further thought, using the A-input is overkill and even conflicting in some cases. All we need is the OUT bit for that pn. If OUT is high, state is frozen. This could work for all smart pins modes which override OUT. It would allow synchronization of many pins. I'll add that tomorrow. Indeed, this was something missing.
I am on Windows 10. I have to tell pnut every time which com port to use.
Then I have to do a Ctl-G to identify the port.
Now I can do a successful download.
Sometimes I can repeat this process to download again. Other times it locks and I have to unplug the com port and then "End Task". If I don't remove the com port (propplug) pnut locks and I cannot perform an "End Task" (using Ctl-Alt-Del task manager).
Any chance of open sourcing PNut? I'd like to have a shot at porting the Delphi code over to FreePascal. Part of porting process is modifying the comms code to use a proven cross-platform unit - Hopefully fixing the Win10 issues as a bonus.
Not sure on that one Ray, maybe FTDI driver?
Any chance the 8 smart pins could be on pins 56-63 for the De-nano ?
The prop plug used for programming/downloading is on P62/63. The downloaded code cannot use the UART on the same P62/63 pins, so another prop plug is required on P0:7.
Thinking some more about this Pulse Mode,
Q: Would the X field be more useful as a leading edge delay, than as a prescaler ?
ie Changes Pulse Formula from the above tPW = Y * X/(SysClk), to :
tPW = Y/(SysClk) // Pulse HI time, 32b range
tD = X/(SysClk) // Leading edge Delay time, 16b range
I can think of designs that would use multiple pulses, sync'd (Chip is now fixing that), and with adjustable widths and delays.
It is harder to think of a project that needs 977 hours, to 48 bits of precision, but there may be one somewhere
Addit: The same question may apply to NCO Frequency
It is not clear if the NCO has any means now to set the start Phase, P1 allows this.
ie Does NCO need 16b prescaler and 32b adder, Should X << 16 become NCO start phase ?
NCO duty, I can see uses both ways, as in this mode, X sets the output pulse width.
These have timebase capture, with a nice lossless reset, and software capture (continual mode, no reset)
but there seems to be currently no Pin-Capture ability ?
Can the B field be used for that ? B = x100 would select the Timebase.TC, for periodic, and other values are already pins, with polarity.
This would mean those modes that use both A&B already, would lack Pin Capture, but that is likely ok ?
(QuadAB, Time interval A-B, A++B--, )
I'm still looking at precision Duty Cycle measurements.
For this, you need to avoid partial cycle captures, so the information capture must be external signal sync'd, but it can also be useful to capture over many cycles of higher frequency Duty Cycle.
A pulse time measurement more precise than the sysclock needs a timer that is more precise. You're asking for too much there.
I do not expect better than SysCLK precision, but I do expect the smart pins to be able to work up to SysCLK precisions, and to work over multiple smart pins, and over more than one cycle of signal in.
For Precision Duty Cycle for example, a higher frequency Sensor signal may need 100 or 1000 or more whole cycles read, to give the needed precision. That is not complex stuff, but the details matter
With Chips latest improvements, this is almost there.
IIRC the smartpins are on P0:P7 to align with the DAC's of Cog0.
The way to do that is to use duration rather than a pulse count. Mode 01100, Inc on A-High, covers that. The accumulated high time divided by the total sample period give the precise averaged duty.
looking at these modes I'm thinking mode 10011, Time A-rise to A-rise, is extraneous as it's covered by mode 10100, Time A-rise to B-rise with both inputs directed at one pin.
This is why I said the details matter.
Your approach is simple, but can have overlap errors, as you get HI gate effects, but not the correct periods. Worse case is an Inc-on-high that has N+1 HIGH phases, and N low phases, which will give an incorrect too-high value for Duty.
That is why I underlined the whole cycles of Fin.
A simple Gated approach, is only of modest precision, certainly far less than the silicon could be capable of.
If Chip applies the suggestion I made above of
%BBBB = x100 would select the Timebase.TC, for periodic capture.
Other values of %BBBB would capture A-Counts from the selected B-Pin edge
Then those modes 10011, 10100 are different.
I think in the Pin-capture case, the X value can apply similar rules, to Timebase Capture.
if %BBBB <> x100 then
X=0 would be Software Armed capture, one B edge per Software request
X > 0 would spread capture over X edges of B, allowing 100, 1000 etc Cycles of Fin to be used to expand precision, for simpler fixed range use, on one pin Cell.
For "duration" I didn't mean count pulses for a duration but rather the literal sample period of a PCM sample. Each sample is an accumulation of "A=true" in sysclocks. The average ratio of high to low is precisely represented in the sample. This is how bit-streaming works. Mode 01100 is a time accumulator, not a pulse counter.
To Expand:
Let's say I want to capture the Duty Cycle of a sensor that outputs in Duty Cycle mode.
The Period of such signals may vary due to RC oscillators, but the Ratio of Hi/Period, should be stable and valid over multiple signal periods. So measure of HI time alone, is clearly not enough.
You can try to extract Hi/Period values in one single cycle. but depending on the frequency and filtering effects, more may give better signal to noise and precision. The choice to use more incoming cycles, should be simple.
The point I have made, more than once, is that in order to keep precision, care is needed to do that measurement over whole incoming periods. (be that 100, 1000, 1024 or whatever)
There's some subtlety there. They are different because the first reports every A period, while the second must wait for A then for B, not for A, A, A,... If you used the second mode for just A, you would miss every other period.
I could make 63/62/5/4/3/2/1/0 be the smart pins. That would work on both DE0-Nano setups.
This would be fantastic Chip.
BTW I just asked on another thread, do the smart pins -1/-2/-3 wrap from P0 to P63 etc. ie Icould use smart pins P0 & P1 both with -2 to access actual P62 & P63 pins respectively ??? If this works then this would solve my problem.
Don't know about DE0 configuration, but the general design does work that way.
See here