Maybe. Perhaps there is a way to use an adjacent pin in NCO mode as the clock, consuming a pin is a reasonable compromise
I think lets have a good play with this v7 package in its entirety, and see what the biggest omissions are, since logic space will be constrained and everything is multiplied *64
An optional NCO could be good, but I'd be cautious about NCO only, as AutoBAUD functions and some calibrate features, expect the BIT timing to be essentially jitter free.
An alternative is a rate-multiplier like modulate of BIT times on a fractional baud basis.
That means every char 'looks' the same, but edges effectively snap to the nearest SysCLK.
Anything that is Whole-Number SysCLK related, has zero jitter.
Testing the EXAR part some more, it seems to do that, as
48M/4.5 is very close, whilst 48M/4.55 and 48M/4.45 both measure just under 1% errors from requested Baud value.
In the tests I did above, the 80M/N numbers happen to all be 0.1 increments from 48MHz.
A number of small MCUs already offer Fractional Baud schemes.
Addit: Running some numbers, there may be a way to use the NCO, which is already a mode in place.
Q: Is the NCO mode available when in Baud-generate cases, or is that logic committed elsewhere ?
If you re-phase the NCO every Char Frame, then the behaviour becomes bit-number locked, (ie now the same as a rate multiplier, but probably with less Logic by reusing the existing NCO) and there is no inter-char jitter.
You lose some decimal places of precision but gain lower jitter. (=> zero jitter between like edges)
I think this means a Sync RST on the NCO adder, at the Char frame rate ?
Rate-Multiplier modulation is also very useful for Digital PWM modes, to give higher effective bits.
Maybe the same Sub-frame re-phase (aks Sync RST) of NCO can be used there too ?
Rayman...thanks. All integrated and zipping along at 3_000_000 baud. That's a 2.3x improvement over stupid pins. Couldn't be much simpler... unless the smart pins had voice recognition:)
I just test at 3_000_000 baud too... That's crazy fast. Didn't know that was possible. I didn't even know PST had that option...
That's about 26 clocks per bit, 208 clocks per byte. I guess it's possible to actually process data that fast with P2.
Thinking about how long it would take to transfer VGA image... 3Mbaud ~ 375kB/sec.
640x480 ~ 307 kB. Looks like little less than one second.
I assume and JMG just confirmed... that we are going to have USB or the functional equivalent.
I wasn't sure about that because I mix and match my numbers from time to time. So it is good to hear JMP reconfirm it for me.
I'm all about the here and now. Instant gratification.
I am getting 320x240(8 bit) in about a 250ms. I don't actually need anything faster than 4 frames per second because at this stage it is all about building my personal code base, and understanding what Chip is doing and lots of dreaming about the future.
But if I wanted 20+ frames per second tomorrow, I know could get it by using multiple serial connections... probably not with my $99 Win 10 machine. Right now, I'm doing stereo camera and Kinect stuff, using the serial simply to transfer images in and out, to store stuff, and exercise the P2v. In the future, hopefully a different camera will be attached directly to a real Prop2 and the Kinect will be replaced by several Parallax TOF devices. It is difficult to predict the future. So, I could be using my current approach for some time, even after the real P2 replaces my P2v. It all works. It is powerful and there are no serious issues that remain to be resolved.
I assume and JMG just confirmed... that we are going to have USB or the functional equivalent.
I wasn't sure about that because I mix and match my numbers from time to time. So it is good to hear JMP reconfirm it for me.
Err, just to clarify my numbers were for UART-USB connections, so it is a connection to USB, but via a Bridge. (Not native USB inside P2 ?)
P2 should be able to run that simple Async link, at up-to the Bridge limits, which means 9+MBd (one way) for EXAR FS devices (reasonably affordable), or 12MBd (duplex) for FTDI HS-USB Uarts (less affordable, larger packages, and need a crystal).
There are 25MBd EXAR PCI USB devices, so those should also be P2-linkable, if you have a system with one in it.
There are also FT600 parts with a FIFO link, P2 might (hopefully) also be able to talk to, but they have constrained clock (choose 66Mhz or 100Mhz ) parallel interfaces that could suit the Streamer.
If P2 can link to FT600, then > 400MBd is possible.
@jmg
I had a FT2232H fed by P2 in 8 bit mode running @ 8M.
Data was clean and intact, looks encouraging.
Cool.
I see there is a FT2232H Fast Serial (clocked ) that can use up to 50MHz clock, but is Async/UART in data framing. (Start and Stop bits, plus 9th Source Bit) Half Duplex.
This looks like another common, fast serial link that maybe worth a test ? 40MHz on a 80Mhz SysCLK ?
Can the modes cover SysCLK/2 and a generated CLK for Async,8b (9th bit fixed for now?)
No-Clock Async has a SysCLK/3 limit, and I think you cannot manually generate SysCLK/3, so needs SysCLK/4, or half the possible 40MHz speed.
I wonder is that SysCLK.3 Chip mentioned just a suggested limit - can you set for SysCLK/2, and rely on the manual SysCLK/2 clock to remove jitter effects ?
CLK is generated by P2, so test could be to start at /4, or lower, and move up to /2, testing each time.
Addit: I ran Fast Serial some time ago, with PLDs, and ISTR it could config as standard VCP, which simply ignored Baud - so any terminal should work.
The speed is set by the FSCLK provided to FT2232H, which is easy to vary on P2.
Do the OUTA/B registers still give you actual pin output in Smart Pin mode?
Was just thinking that P2 could UART over INA/INB, OUTA, OUTB at 100 kHz (if I did the math right).
PC could that process that into a basic logic analyzer with 10 us resolution...
Can't we fudge variable bit length asynchronous by using 32 bit mode and setting all unused bits to 1?
Doesn't that make one long stop bit?
Yes, you can do this, and personally I think its fine for shorter than 8 data bit codes (5/6/7 bits, which are less likely to need full character rates anyway
You can also pack 3 bytes into a single long before transmission in 32 bit mode
So, I've been explaining the new "smart pins" to my co-workers. Invariably, I end up referring to the new functionality as "cells", not "pins". This comes about when I explain how you can select pins for the A/B inputs. In the end, I find that it is more natural to refer to these as "smart cells". With that, I can make statements like:
* The P2 has 64 smart cells that run independently of the cogs and are each capable of operating in 32 different modes.
* Each smart cell has affinity to a primary pin for input or output
* Each smart cell also has affinity to six secondary pins (three on either side of the primary pin) for input
* Smart cells that have affinity to the same pins can operate on those pins at the same time
As you can see, it's a lot easier explaining the cell-to-pin relationship when I don't use the term "smart pin". Now, it may be that the choice of the word "cell" isn't quite right, but I think it's better than "pin". Until someone comes up with something better, I think I will continue to refer to these things as "smart cells".
Pins are hard to reconcile when you have the primary PIN association plus the +/-3 pin A/B association. Cells or POGS or something else is probably better when it comes to discussing the smart thingies.
Since the new image came out with Smart Pins, I've been struggling to get something (anything) using the smarties to work - Chip's examples or anyone else's examples, compiled, loaded to my A9 board and then just sat there. I even got a USB logic analyzer set up and working. It showed be normal activity if I did normal PIN I/O and generally just noise or nothing if I tried some Smart I/O example.
Ctrl-G told me I had 64 Smart Pins.
Just for grins, I reflashed my board with the same image I used last time and things started working.
Not sure why but it seems like my smart pin image was partially loaded by px.exe
Just in case the world is driving you crazy, give it a try.
So, I've been explaining the new "smart pins" to my co-workers. Invariably, I end up referring to the new functionality as "cells", not "pins".
Yup - I've been using Pin Cell for that reason, as that is simply what they are.
This affinity/allocate feature of Pin cells, does open the possibility of having some number less than 64, and still giving coverage.
64 is ideal, but if die area comes in tight (and it may well do that) it may drive some lower Pin cell number.
Unlike COGS which are rather locked at 8 or 16, Pin Cells can vary more freely. 32/40/48/56/64 would all work.
A Paired cell is another option, that gives some logic saving.
To me, it seems like the smarts are very much tied to it's pin as it can only output on that pin.
Also, the IN function of that pin gives you the status of an operation.
It's only aware of it's neighbors input status, I think.
Maybe it's a similar situation as with an artificial neuron... Inputs from neighbors and state form it's output...
Out of curiosity, do A/B pin selections wrap around? In other words, if you set smart cell zero's A input to -1, will it use pin 63?
I would guess so.
There must be some logic cost to the arithmetic offset, but that is nice for PCB design & code portability.
A simpler LSB-map means an adjacent pin on a PCB, could be non-reachable.
Yes, you can do this, and personally I think its fine for shorter than 8 data bit codes (5/6/7 bits, which are less likely to need full character rates anyway
That does not work on receive (see above comment)
You do need variable bit-length, which Chip has said is in the plan.
What may be a useful compromise, is to constrain the alignment to MOD 8, so that for MSB/LSB unusual bit cases, the user needs to do a align rotate.
Common sizes like 8,16,24,32 need no fixups.
That can save a lot of tap-multiplexing in Logic.
Comments
I think lets have a good play with this v7 package in its entirety, and see what the biggest omissions are, since logic space will be constrained and everything is multiplied *64
An alternative is a rate-multiplier like modulate of BIT times on a fractional baud basis.
That means every char 'looks' the same, but edges effectively snap to the nearest SysCLK.
Anything that is Whole-Number SysCLK related, has zero jitter.
Testing the EXAR part some more, it seems to do that, as
48M/4.5 is very close, whilst 48M/4.55 and 48M/4.45 both measure just under 1% errors from requested Baud value.
In the tests I did above, the 80M/N numbers happen to all be 0.1 increments from 48MHz.
A number of small MCUs already offer Fractional Baud schemes.
Addit: Running some numbers, there may be a way to use the NCO, which is already a mode in place.
Q: Is the NCO mode available when in Baud-generate cases, or is that logic committed elsewhere ?
If you re-phase the NCO every Char Frame, then the behaviour becomes bit-number locked, (ie now the same as a rate multiplier, but probably with less Logic by reusing the existing NCO) and there is no inter-char jitter.
You lose some decimal places of precision but gain lower jitter. (=> zero jitter between like edges)
I think this means a Sync RST on the NCO adder, at the Char frame rate ?
Rate-Multiplier modulation is also very useful for Digital PWM modes, to give higher effective bits.
Maybe the same Sub-frame re-phase (aks Sync RST) of NCO can be used there too ?
Sort of. Each mode is just combinatorial logic that gets muxed to X, Y, Z, and seven state bits. There are a few adders in the mix.
I'd still rate variable-length TX/RX (1..32 bits) above Fractional Baud capability.
Yes, I intend to get variable bit lengths implemented.
I assume and JMG just confirmed... that we are going to have USB or the functional equivalent.
I wasn't sure about that because I mix and match my numbers from time to time. So it is good to hear JMP reconfirm it for me.
I'm all about the here and now. Instant gratification.
I am getting 320x240(8 bit) in about a 250ms. I don't actually need anything faster than 4 frames per second because at this stage it is all about building my personal code base, and understanding what Chip is doing and lots of dreaming about the future.
But if I wanted 20+ frames per second tomorrow, I know could get it by using multiple serial connections... probably not with my $99 Win 10 machine. Right now, I'm doing stereo camera and Kinect stuff, using the serial simply to transfer images in and out, to store stuff, and exercise the P2v. In the future, hopefully a different camera will be attached directly to a real Prop2 and the Kinect will be replaced by several Parallax TOF devices. It is difficult to predict the future. So, I could be using my current approach for some time, even after the real P2 replaces my P2v. It all works. It is powerful and there are no serious issues that remain to be resolved.
Happy days:)
P2 should be able to run that simple Async link, at up-to the Bridge limits, which means 9+MBd (one way) for EXAR FS devices (reasonably affordable), or 12MBd (duplex) for FTDI HS-USB Uarts (less affordable, larger packages, and need a crystal).
There are 25MBd EXAR PCI USB devices, so those should also be P2-linkable, if you have a system with one in it.
There are also FT600 parts with a FIFO link, P2 might (hopefully) also be able to talk to, but they have constrained clock (choose 66Mhz or 100Mhz ) parallel interfaces that could suit the Streamer.
If P2 can link to FT600, then > 400MBd is possible.
But I could be wrong... that's why I'm posting it. more of a question than a statement;)
I had a FT2232H fed by P2 in 8 bit mode running @ 8M.
Data was clean and intact, looks encouraging.
Cool.
I see there is a FT2232H Fast Serial (clocked ) that can use up to 50MHz clock, but is Async/UART in data framing. (Start and Stop bits, plus 9th Source Bit) Half Duplex.
This looks like another common, fast serial link that maybe worth a test ? 40MHz on a 80Mhz SysCLK ?
Can the modes cover SysCLK/2 and a generated CLK for Async,8b (9th bit fixed for now?)
No-Clock Async has a SysCLK/3 limit, and I think you cannot manually generate SysCLK/3, so needs SysCLK/4, or half the possible 40MHz speed.
I wonder is that SysCLK.3 Chip mentioned just a suggested limit - can you set for SysCLK/2, and rely on the manual SysCLK/2 clock to remove jitter effects ?
CLK is generated by P2, so test could be to start at /4, or lower, and move up to /2, testing each time.
Addit: I ran Fast Serial some time ago, with PLDs, and ISTR it could config as standard VCP, which simply ignored Baud - so any terminal should work.
The speed is set by the FSCLK provided to FT2232H, which is easy to vary on P2.
Doesn't that make one long stop bit?
On receive, you have to somehow insert those pad-bits, which is not easy/impossible on most UARTS.
Was just thinking that P2 could UART over INA/INB, OUTA, OUTB at 100 kHz (if I did the math right).
PC could that process that into a basic logic analyzer with 10 us resolution...
Yes, you can do this, and personally I think its fine for shorter than 8 data bit codes (5/6/7 bits, which are less likely to need full character rates anyway
You can also pack 3 bytes into a single long before transmission in 32 bit mode
* The P2 has 64 smart cells that run independently of the cogs and are each capable of operating in 32 different modes.
* Each smart cell has affinity to a primary pin for input or output
* Each smart cell also has affinity to six secondary pins (three on either side of the primary pin) for input
* Smart cells that have affinity to the same pins can operate on those pins at the same time
As you can see, it's a lot easier explaining the cell-to-pin relationship when I don't use the term "smart pin". Now, it may be that the choice of the word "cell" isn't quite right, but I think it's better than "pin". Until someone comes up with something better, I think I will continue to refer to these things as "smart cells".
Since the new image came out with Smart Pins, I've been struggling to get something (anything) using the smarties to work - Chip's examples or anyone else's examples, compiled, loaded to my A9 board and then just sat there. I even got a USB logic analyzer set up and working. It showed be normal activity if I did normal PIN I/O and generally just noise or nothing if I tried some Smart I/O example.
Ctrl-G told me I had 64 Smart Pins.
Just for grins, I reflashed my board with the same image I used last time and things started working.
Not sure why but it seems like my smart pin image was partially loaded by px.exe
Just in case the world is driving you crazy, give it a try.
Pins are pins, and when one doesn't invoke a POG, the COG drives 'em as expected. One or more POGS can be put to work assisting with the PINS, etc...
Now, POG is gonna slip out of me, on occasion, until we come up with something quick, simple, etc... like COG is.
This affinity/allocate feature of Pin cells, does open the possibility of having some number less than 64, and still giving coverage.
64 is ideal, but if die area comes in tight (and it may well do that) it may drive some lower Pin cell number.
Unlike COGS which are rather locked at 8 or 16, Pin Cells can vary more freely. 32/40/48/56/64 would all work.
A Paired cell is another option, that gives some logic saving.
Also, the IN function of that pin gives you the status of an operation.
It's only aware of it's neighbors input status, I think.
Maybe it's a similar situation as with an artificial neuron... Inputs from neighbors and state form it's output...
I would guess so.
There must be some logic cost to the arithmetic offset, but that is nice for PCB design & code portability.
A simpler LSB-map means an adjacent pin on a PCB, could be non-reachable.
You do need variable bit-length, which Chip has said is in the plan.
What may be a useful compromise, is to constrain the alignment to MOD 8, so that for MSB/LSB unusual bit cases, the user needs to do a align rotate.
Common sizes like 8,16,24,32 need no fixups.
That can save a lot of tap-multiplexing in Logic.
Smart Pin Cell.