You have now descended into insinuations of bad intention "fraud", and or personal commentary "arrogance and ignorance", "10 year old", "lunacy"
Please don't do that here. It's annoying. I don't appreciated it at least. Thank you.
Peter is free to do what he likes, as are we all. He is welcome to discuss it here, as are we all I hope. He has indicated that whatever the final result is, success, failure, or something in between will be published here.
That peer review of which you speak does not generally happen until the work is done and presented for review. That is often how science works. That's not to say that scientists involved in some research or other don't discuss what they are up to among themselves at the forums and conferences they have.
ksltd,
As a moderator, I'm tasked to keep the conversations here polite, respectful, etc. no matter how technically outrageous the topic might seem to some. If you don't like what's being described, either go read and comment on other topics you feel better about or limit your comments to observations of fact or a specific technique critique. Personal criticisms will no longer be tolerated here. Peter is experienced and has contributed a lot. This would not be the first time he (and others) have made outrageous sounding proposals and eventually reduced them to practice after a lot of work ... rendered gratis ... and/or described the limitations of the technique involved after a lot of work to characterize it.
Well said, @Mike Green.
I would also like to add that - even if I do not do FORTH - I really enjoyed reading Tachion's source code as far as I could follow. So mostly the spin and pasm parts. I personally can not really wrap myself around that FORTH stuff. I tried, but failed.
@Peter Jakacki has proven over time that he is able to deliver a lot of fun stuff. I am still tempted by FORTH but I am soooooo used to 'normal' languages to not adjust to FORTH.
But @Peter Jakacki has provided a lot of working stuff, and I am very impressed by the working, speed and good memory usage of Tachion. He basically seems to know his stuff.
On the other hand I do not remember ANY source code, project or example provided by @ksltd. None. Nada, Zilch.
There is some Chinese proverb: "People who say that things can not be done should not disturb people doing it."
@Peter Jakacki is NOT advertising the stuff he is doing for business. And he seems to do a lot of nice things. Sometimes he mentioned them, but he even has no link in his signature to his web site, if he even has one.
I, personally do also get exited about some posts and 'have to correct what somebody said over the internet', (like now) but I try to be polite and not insult people at all.
Sure @Publison called me once or twice for insulting @Heater, but it was never planned by me to insult him, just a language barrier, and I am pretty sure @heater never felt insulted at all.
But you know @ksltd, I am reading this forums every day. Some sort of addiction. Once in a while I do some projects. Sometime I write about them and sometimes I don't.
But I read about people having problems with their project, and I give them a tip to solve the same, if I know of one. I sometimes ask questions about how to handle some stuff, and get tips to handle it. That is what a forum for entrepreneurs is for.
What you are doing is trying to discourage someone doing his stuff, and not helping him at all. Why you are doing this?
Is it because YOU are not getting anything done, so nobody else is allowed to? (Sorry for that, but it has to be said)
So I do now challenge you @ksltd to post SOME Source code YOU wrote for the P1. Anything. Show me your expertise of Pasm or Spin or C or Forth or Pbasic or whatever else you personally use.
Anything. Just post some file of source code you wrote by yourself. Any stupid file to show your coding and documentation skills.
Then we talk about @Peter Jakacki's abilities again, OK?.
And if you can NOT provide some own stuff, better shut up, instead of discouraging people to try something not done before.
Sorry @Peter Jakacki to drag this into this thread, but I could not control myself anymore.
So I do now challenge you @ksltd to post SOME Source code YOU wrote for the P1. Anything. Show me your expertise of Pasm or Spin or C or Forth or Pbasic or whatever else you personally use.
Anything. Just post some file of source code you wrote by yourself. Any stupid file to show your coding and documentation skills.
Then we talk about @Peter Jakacki's abilities again, OK?.
And if you can NOT provide some own stuff, better shut up, instead of discouraging people to try something not done before.
Sorry @Peter Jakacki to drag this into this thread, but I could not control myself anymore.
Somebody was wrong on the internet...
Enjoy!
Mike
Perhaps we should start a new thread "ksltd vs the internet" instead of hijacking Peter's :P
Well... I was going to post earlier... but I could not come up with anything proper to say, and I really don't have anything now... however I will say this...
Peter has always been very helpful to me and in my opinion, he is a vital member to this online community, who contributes his time, knowledge, and examples, so that others may learn and enjoy their hobby. Instead of being rebuked, he should be respected.
If I did something wrong in the past: it was, that I didn't start to use Peters Tachyon Forth. Whenever there is someone tumbles, he is the first and best to help, mostly he solves the problems before the become obvious. And now I think: while it is not worth the ink to write against somebody, it is always a pleasure to write something pro a person.
It would be nice to see the source code for this. I understand that Peter may be reluctant to share source since he writes P1 code for a living, but maybe somebody else can shed some light on how this works. It seems that what is required is to read bytes from 32 buffers and combine their bytes into 8 32-bit longs so that all the bits can be sent out to OUTA at the same time.
There's another thread on transposing 32 bytes to produce 8 32-bit longs, so maybe that's related to this problem. It can be made jitter-free by ensuring that each loop has the same number of cycles every time. I haven't figured out how a precise 115200 Hz clock can be derived from an 80 MHz clock, but maybe someone knows how that can be done.
It can be made jitter-free by ensuring that each loop has the same number of cycles every time. I haven't figured out how a precise 115200 Hz clock can be derived from an 80 MHz clock, but maybe someone knows how that can be done.
I think the folks talking about jitter free 115,200 on the prop are referring to "relatively jitter free". Not sure though... I'm curious to know too
There are certainly numerous cases of jitter free signals - and its possible to generate them with a propeller. The simple loop:
loop xor outa,#1
jmp #loop
will create a jitter free square wave on pin P0. The signal's frequency may drift, but there will be no jitter. Right?
Moving on, there is no specification or any standards body that defends interoperability requirements for asynchronous serial data. The 2.5% is a budget number, not a specification and no one would build a device to that budget.
In typical, modern, hardware implementations, the combination of drift of bits between transmitter and receiver has to be less than 50% of the bit time. If there is cumulative error, this 50% must not accumulate over the number of bits per symbol. With 10 bits per symbol, that's 5% per bit. Splitting that budget between transmitter and receiver is the source of the 2.5% number that's frequently sited. That's a budget analysis, not a specification. To work in the real world, one must stay substantially within any budget analysis.
Most implementation are constructed around much less than 1% in frequency error (usually zero) and a few parts per million in long term drift. Start bit detection is canceled during data bit sampling. Cumulative error within a symbol is limited only by frequency error plus long term drift. In other words, accuracy is in the few parts per million or a few 0.0001 percents.
Were this not the case, the propeller soft UART implementation could not work.
In fact, the soft implementations have a receive window that bounces around from approximately 25% to 75% of a bit time. Accumulated drift is limited by error in converting baud clock to system clocks - and attention to that conversion is critical to maximum performance. The 25% is fixed, and the 75% is determined by worst case latency through code paths at maximum baud rate. The exact sample point is dependent on the combination of transmit and receive activity among all channels and can't be predicted. Coupled to a transmitter that had any appreciable amount of cumulative per-bit drift the soft uarts would fail a lot of the time.
You're right that it is not possible to synthesize 115,200 from 80,000,000 using whole numbers.
There are three separate choices.
One can synthesize 694/80000000 or ~115273.775216Hz with zero jitter
One can synthesize 695/80000000 or ~115107.913669Hz with zero jitter
Or, one can synthesize 5 of the former and 4 of the latter and get a long term result that is exactly 115,200 with no long term drift but some small jitter. If the repeated pattern is 694, 695, 694, 695, 694, 695, 694, 695, 694 then jitter and short term frequency error are both equal and only 1 part in 80 million; not bad and a reasonable approximation of zero. Probably better than the frequency drift of a crystal oscillator.
The existing drivers use integer division to compute the tick count used. By rounding the result of that division, a change I made in my implementations, the maximum performance stepped up significantly.
It would be nice to see the source code for this. I understand that Peter may be reluctant to share source since he writes P1 code for a living, but maybe somebody else can shed some light on how this works. It seems that what is required is to read bytes from 32 buffers and combine their bytes into 8 32-bit longs so that all the bits can be sent out to OUTA at the same time.
while Peter writes P1 code for a living - you can't really say he is reluctant sharing.
The complete Tachyon with loads of modules and examples he gives freely to us - the community.
Have a look at his signature ... Dropbox
of course there might be custom projects that can not be shared - but anybody should understand that.
and for the code for MAGIC32 ... just be ALL a bit patient ...
it makes no sense to show all intermediate steps / experiments / iterations / ...
in the end your questions might be answered ... or not ;-) ... that's life
There's another thread on transposing 32 bytes to produce 8 32-bit longs, so maybe that's related to this problem. It can be made jitter-free by ensuring that each loop has the same number of cycles every time. I haven't figured out how a precise 115200 Hz clock can be derived from an 80 MHz clock, but maybe someone knows how that can be done.
I started this transposition thread, while thinking about the impossible as well.
As the 32-channel sending routine consists of 2 major parts:
1. sending out the 8+start/stop bits on all (1..32) channels
2. preparing the words (32-bits) to be shifted out.
and this requires this transposition.
Thinking about it I was wondernig if there could be some genius tricks to speed this up.
But apparrently nobody came up with something better than a:
a) shift out - shift in loop
b) or my shift out - MUXC proposal
Depending on the baud rate the part 2, preparation, could be done after the shift for slow speed
or potentially interleaved with the shifts of the data bits to OUT for high speed.
The signal's frequency may drift, but there will be no jitter. Right?
Well yeah, obviously.
Up to a point. Have you ever measured the jitter on the output? May be very small but I'm sure there is some.
You have a point, I have no idea where these requirements for timing accuracy in RS232 or UARTs in general come from. Clearly if you are triggered on an edge like the good old teletypes were your motor had better be spinning at the correct speed to clock in the rest of the bits of a character. No different when we go with digital electronics.
while Peter writes P1 code for a living - you can't really say he is reluctant sharing.
We all know that he shares the source for the Tachyon code. I was referring specifically to the source code for doing "32 magic channels of impossible jitter-free fast serial in 1 cog". I assumed he was reluctant to share the source code since he hasn't posted it. I suppose I should have asked if you could post it before making any assumptions.
while Peter writes P1 code for a living - you can't really say he is reluctant sharing.
We all know that he shares the source for the Tachyon code. I was referring specifically to the source code for doing "32 magic channels of impossible jitter-free fast serial in 1 cog". I assumed he was reluctant to share the source code since he hasn't posted it. I suppose I should have asked if you could post it before making any assumptions.
Peter, could you please post the source code?
I can not speak for Peter - but I can quote myself from above
and for the code for MAGIC32 ... just be ALL a bit patient ...
it makes no sense to show all intermediate steps / experiments / iterations / ...
in the end your questions might be answered ... or not ;-) ... that's life
he will post, when he is ready
it is exiting .. I know ...
and many are keen to see the code und understand if / how it works - then ... (me included)
but he just created SPLAT on the way - something we can start to play with already
The signal's frequency may drift, but there will be no jitter. Right?
Well yeah, obviously.
Up to a point. Have you ever measured the jitter on the output? May be very small but I'm sure there is some.
You have a point, I have no idea where these requirements for timing accuracy in RS232 or UARTs in general come from. Clearly if you are triggered on an edge like the good old teletypes were your motor had better be spinning at the correct speed to clock in the rest of the bits of a character. No different when we go with digital electronics.
I'm pretty sure those timing requirements evolved from the timing requirements of the solenoids and synchronous motors used in the first teletypes. The mechanical precision and complexity required was incredible at the time.
The timing requirement for async is directly related to the frame size. 8-bits of data plus a start and stop bit produces a frame size of 10 bits. Once the leading edge of the start bit is detected the data is then sampled in the middle of each bit. This allows for +/- half a bit of timing error. Over 10 bit times there could be up to a 5% difference in frequency between the transmitter and the receiver. A limit of 5% difference between the transmitter and receiver means that each one must be within 2.5% of the nominal frequency.
Since the Prop uses a crystal oscillator the system clock frequency is accurate to a small fraction of a percent. So this provides some flexibility for using clock divisors that aren't precise and timing loops that can have some jitter in them.
You have a point, I have no idea where these requirements for timing accuracy in RS232 or UARTs in general come from.
Most figures are derived from sampling at 16x, often with 3 points, and still having enough margin to sense a stop bit, and assume each end is 'equally bad'.
A rough first-pass gives half a bit in ten, or 5% or 2.5% each end, in time domain.
A little more precision for sampling both ends (start & stop), can give numbers like 3.75% or 1.875% each end.
Of course, these days not all uarts sample at 16x...
Since the Prop uses a crystal oscillator the system clock frequency is accurate to a small fraction of a percent. So this provides some flexibility for using clock divisors that aren't precise and timing loops that can have some jitter in them.
It also means 8 bit payloads is not mandated.
You could send 32b using UART framing, with Prop+Xtals at each end.
I wonder how hard it would be to implement an instruction for the P2 that would take 32 longs and bitwise transpose them all. I imagine it wouldn't really be practical, although I suspect the P2 MERGE(B|W) instructions would be helpful for a software implementation. If MAGIC32 works how I suspect, it seems like that would be very useful for a driver like this.
I wonder how hard it would be to implement an instruction for the P2 that would take 32 longs and bitwise transpose them all. I imagine it wouldn't really be practical..
Yup, not practical as a single opcode - 32 longs is 1024 bits, and memory bandwidth limits say that cannot be done in one cycle.
I could see an opcode that managed an 8 bit stripe, given a source, starting index, & bit-column index, and that would need 8 memory access cycles.
Is this still a challenge? I think SPLAT is interesting, however this seems more interesting insofar as seeing how far you can push the Prop.
I've been meaning to come back and read this thread and also confirm that I am still intent on implementing this driver. I never expected to ever want to run 32 streams all at once at full throughput and from a single application either but the idea was to have the flexibility to pick and choose what was needed.
At the time I wanted to have some fun and also a challenge, to get me to focus on something positive. Well the positive part got eroded away until it wasn't fun anymore, so I have just let it lie dormant in the meantime until a better time.
But now that I have had my distractions I suppose the right thing to do is to get back into it and see what can become of it as I expect to have a usable multi-channel transmitter working at the very least. Now I've also had some thoughts that I can also make this a multiprotocol transmitter as well to handle things like WS2812 LEDs for instance, and also clocked streams too. Whether that is practical for the receiver side I don't know yet, but I find it interesting too and would like to get it working, first in Tachyon where it's easy to test and tune in combination with SPLAT, and then others can adapt it to C and Spin etc.
Go for it! Projects like this are doubly interesting because they show us the boundary conditions of what's doable, not just whether something is doable or not, but under what conditions / assumptions.
Comments
Well said
Well said, @Mike Green.
I would also like to add that - even if I do not do FORTH - I really enjoyed reading Tachion's source code as far as I could follow. So mostly the spin and pasm parts. I personally can not really wrap myself around that FORTH stuff. I tried, but failed.
@Peter Jakacki has proven over time that he is able to deliver a lot of fun stuff. I am still tempted by FORTH but I am soooooo used to 'normal' languages to not adjust to FORTH.
But @Peter Jakacki has provided a lot of working stuff, and I am very impressed by the working, speed and good memory usage of Tachion. He basically seems to know his stuff.
On the other hand I do not remember ANY source code, project or example provided by @ksltd. None. Nada, Zilch.
There is some Chinese proverb: "People who say that things can not be done should not disturb people doing it."
@Peter Jakacki is NOT advertising the stuff he is doing for business. And he seems to do a lot of nice things. Sometimes he mentioned them, but he even has no link in his signature to his web site, if he even has one.
I, personally do also get exited about some posts and 'have to correct what somebody said over the internet', (like now) but I try to be polite and not insult people at all.
Sure @Publison called me once or twice for insulting @Heater, but it was never planned by me to insult him, just a language barrier, and I am pretty sure @heater never felt insulted at all.
But you know @ksltd, I am reading this forums every day. Some sort of addiction. Once in a while I do some projects. Sometime I write about them and sometimes I don't.
But I read about people having problems with their project, and I give them a tip to solve the same, if I know of one. I sometimes ask questions about how to handle some stuff, and get tips to handle it. That is what a forum for entrepreneurs is for.
What you are doing is trying to discourage someone doing his stuff, and not helping him at all. Why you are doing this?
Is it because YOU are not getting anything done, so nobody else is allowed to? (Sorry for that, but it has to be said)
So I do now challenge you @ksltd to post SOME Source code YOU wrote for the P1. Anything. Show me your expertise of Pasm or Spin or C or Forth or Pbasic or whatever else you personally use.
Anything. Just post some file of source code you wrote by yourself. Any stupid file to show your coding and documentation skills.
Then we talk about @Peter Jakacki's abilities again, OK?.
And if you can NOT provide some own stuff, better shut up, instead of discouraging people to try something not done before.
Sorry @Peter Jakacki to drag this into this thread, but I could not control myself anymore.
Somebody was wrong on the internet...
Enjoy!
Mike
Perhaps we should start a new thread "ksltd vs the internet" instead of hijacking Peter's :P
Peter has always been very helpful to me and in my opinion, he is a vital member to this online community, who contributes his time, knowledge, and examples, so that others may learn and enjoy their hobby. Instead of being rebuked, he should be respected.
There's another thread on transposing 32 bytes to produce 8 32-bit longs, so maybe that's related to this problem. It can be made jitter-free by ensuring that each loop has the same number of cycles every time. I haven't figured out how a precise 115200 Hz clock can be derived from an 80 MHz clock, but maybe someone knows how that can be done.
In 8.6805 microseconds we can do 8.6805e-6 * 20e6 = 173.61 instructions (Not accounting for HUB access and all that)
Call it 173.
Dropping that 0.61 is an error of 0.35%
Serial comms is spec'ed to work with a speed mismatch of 2.5% or so. Or say 1% in each end. So we are good to go with a one instruction sized jitter.
If the other end is a real UART with much tighter tolerances then we can be a lot more sloppy and get away with jitter of many instruction periods.
I think the folks talking about jitter free 115,200 on the prop are referring to "relatively jitter free". Not sure though... I'm curious to know too
When bit banging we have instruction period sized errors in the timing of the edges.
The question is are those errors significant for the application?
I have to refine my error estimate. No mater what you do for each edge you have to do:
1) Fetch bit
2) Set the pin
3) Loop
If that is four instructions our timing error can be 0.3% * 4 = 1.2% Still within spec.
loop xor outa,#1 jmp #loopwill create a jitter free square wave on pin P0. The signal's frequency may drift, but there will be no jitter. Right?
Moving on, there is no specification or any standards body that defends interoperability requirements for asynchronous serial data. The 2.5% is a budget number, not a specification and no one would build a device to that budget.
In typical, modern, hardware implementations, the combination of drift of bits between transmitter and receiver has to be less than 50% of the bit time. If there is cumulative error, this 50% must not accumulate over the number of bits per symbol. With 10 bits per symbol, that's 5% per bit. Splitting that budget between transmitter and receiver is the source of the 2.5% number that's frequently sited. That's a budget analysis, not a specification. To work in the real world, one must stay substantially within any budget analysis.
Most implementation are constructed around much less than 1% in frequency error (usually zero) and a few parts per million in long term drift. Start bit detection is canceled during data bit sampling. Cumulative error within a symbol is limited only by frequency error plus long term drift. In other words, accuracy is in the few parts per million or a few 0.0001 percents.
Were this not the case, the propeller soft UART implementation could not work.
In fact, the soft implementations have a receive window that bounces around from approximately 25% to 75% of a bit time. Accumulated drift is limited by error in converting baud clock to system clocks - and attention to that conversion is critical to maximum performance. The 25% is fixed, and the 75% is determined by worst case latency through code paths at maximum baud rate. The exact sample point is dependent on the combination of transmit and receive activity among all channels and can't be predicted. Coupled to a transmitter that had any appreciable amount of cumulative per-bit drift the soft uarts would fail a lot of the time.
You're conflating two separate things.
You're right that it is not possible to synthesize 115,200 from 80,000,000 using whole numbers.
There are three separate choices.
One can synthesize 694/80000000 or ~115273.775216Hz with zero jitter
One can synthesize 695/80000000 or ~115107.913669Hz with zero jitter
Or, one can synthesize 5 of the former and 4 of the latter and get a long term result that is exactly 115,200 with no long term drift but some small jitter. If the repeated pattern is 694, 695, 694, 695, 694, 695, 694, 695, 694 then jitter and short term frequency error are both equal and only 1 part in 80 million; not bad and a reasonable approximation of zero. Probably better than the frequency drift of a crystal oscillator.
The existing drivers use integer division to compute the tick count used. By rounding the result of that division, a change I made in my implementations, the maximum performance stepped up significantly.
The complete Tachyon with loads of modules and examples he gives freely to us - the community.
Have a look at his signature ... Dropbox
of course there might be custom projects that can not be shared - but anybody should understand that.
and for the code for MAGIC32 ... just be ALL a bit patient ...
it makes no sense to show all intermediate steps / experiments / iterations / ...
in the end your questions might be answered ... or not ;-) ... that's life
I started this transposition thread, while thinking about the impossible as well.
As the 32-channel sending routine consists of 2 major parts:
1. sending out the 8+start/stop bits on all (1..32) channels
2. preparing the words (32-bits) to be shifted out.
and this requires this transposition.
Thinking about it I was wondernig if there could be some genius tricks to speed this up.
But apparrently nobody came up with something better than a:
a) shift out - shift in loop
b) or my shift out - MUXC proposal
Depending on the baud rate the part 2, preparation, could be done after the shift for slow speed
or potentially interleaved with the shifts of the data bits to OUT for high speed.
Up to a point. Have you ever measured the jitter on the output? May be very small but I'm sure there is some.
You have a point, I have no idea where these requirements for timing accuracy in RS232 or UARTs in general come from. Clearly if you are triggered on an edge like the good old teletypes were your motor had better be spinning at the correct speed to clock in the rest of the bits of a character. No different when we go with digital electronics.
Peter, could you please post the source code?
it is exiting .. I know ...
and many are keen to see the code und understand if / how it works - then ... (me included)
but he just created SPLAT on the way - something we can start to play with already
I'm pretty sure those timing requirements evolved from the timing requirements of the solenoids and synchronous motors used in the first teletypes. The mechanical precision and complexity required was incredible at the time.
Since the Prop uses a crystal oscillator the system clock frequency is accurate to a small fraction of a percent. So this provides some flexibility for using clock divisors that aren't precise and timing loops that can have some jitter in them.
A rough first-pass gives half a bit in ten, or 5% or 2.5% each end, in time domain.
A little more precision for sampling both ends (start & stop), can give numbers like 3.75% or 1.875% each end.
Of course, these days not all uarts sample at 16x...
You could send 32b using UART framing, with Prop+Xtals at each end.
I think the post was about bit-matrix rotate, more than simple bit-reversal.
Yup, not practical as a single opcode - 32 longs is 1024 bits, and memory bandwidth limits say that cannot be done in one cycle.
I could see an opcode that managed an 8 bit stripe, given a source, starting index, & bit-column index, and that would need 8 memory access cycles.
Good point.
Is this still a challenge? I think SPLAT is interesting, however this seems more interesting insofar as seeing how far you can push the Prop.
I've been meaning to come back and read this thread and also confirm that I am still intent on implementing this driver. I never expected to ever want to run 32 streams all at once at full throughput and from a single application either but the idea was to have the flexibility to pick and choose what was needed.
At the time I wanted to have some fun and also a challenge, to get me to focus on something positive. Well the positive part got eroded away until it wasn't fun anymore, so I have just let it lie dormant in the meantime until a better time.
But now that I have had my distractions I suppose the right thing to do is to get back into it and see what can become of it as I expect to have a usable multi-channel transmitter working at the very least. Now I've also had some thoughts that I can also make this a multiprotocol transmitter as well to handle things like WS2812 LEDs for instance, and also clocked streams too. Whether that is practical for the receiver side I don't know yet, but I find it interesting too and would like to get it working, first in Tachyon where it's easy to test and tune in combination with SPLAT, and then others can adapt it to C and Spin etc.