I'm all for documentation... but less is definitely better.
I still can't read the documentation for the P1:) For the P2, I'm trying.
For the unwashed masses, examples are really where it is at.
Beautiful work. Take a few breaths.
There seems to be a lot of stuff about state 0 and state 1 and switching back and forth.
But, the only difference in the two states seems to be which way z gets shifted.
I'm trying to imagine what this could be used for...
SPI input maybe?
Just trying to figure this out. Looks like you shift in the previous value though. So, if you did this on rising edge of clock, you'd get the wrong data. Guess you'd want to shift in on falling edge of clock?
There seems to be a lot of stuff about state 0 and state 1 and switching back and forth.
But, the only difference in the two states seems to be which way z gets shifted.
I'm trying to imagine what this could be used for...
That's how it is in two-bit mode. The state thing was really designed for the one-bit mode, where you have two different rule patterns. I just tried to make use of the state mechanism in two-bit mode, and I figured it could just reverse the meaning of set one, increment, and shift right.
.
Can the smartpin serial transmitter modes be polled for transmitter busy status?
Maybe the unused interrupts 14&15 could be used by the smartpins?
Didn't Chip mention that Pin-Cell status info re-maps onto normal read-able IO registers ?
There will be a limit to what/how many can remap, but I would expect the commonest items like
RxByteReady (in Rx) and TxShiftDone (in Tx) will be mapped ?
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:)
Great. I think INA is also supposed to say when a byte is received.
I'm not sure anymore if waitedg waits for beginning of character or end of character.
Have to test these things...
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.
Didn't Chip mention that Pin-Cell status info re-maps onto normal read-able IO registers ?
That's what I thought too. I tried a few things with no joy.
I'll have to wait for the last piece of the Smartpin doc's for my (doh!) moment.
Seems there are a few tests stalled for need of better information.
The DOCs header part says
Normally, an I/O pin is controlled by its DIR and OUT bits, and it returns its read state via its IN bit. In smart pin modes, the DIR bit is used as an active-low reset signal, while the IN bit is used as a flag to indicate when the smart pin has completed some function. The DIR bit still controls the pin’s output enable and the OUT bit still controls the pin’s output state, though in some smart pin modes which control the output state, OUT is overridden
I think each mode needs a simple table showing what
DIR
IN
OUT
do in Read and Write cases, in that Smart Pin mode.
If more than one flag can be mapped, that choice should be listed.
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...
And that's at 80MHz. I wonder what the current speed estimate is for the final product...
Thinking about how long it would take to transfer VGA image... 3Mbaud ~ 375kB/sec.
640x480 ~ 307 kB. Looks like little less than one second.
At these high Baud rates, some parts insert more stop bits, so you can drop that slightly.
The FT232H (HS USB) seem to work fine to 12MBd and the EXAR parts have the best FS Serial speeds we have measured, you can set those to 12MBd and they averages something over 9MBd.
Looks to sustain up to 80M/9 and 80M/8 can set, but USB limits to 4.6% under sustained speed.
Accepts 11.428571Bd and 12MBd but refuses on 13.333333MBd (no surprise )
I think these EXAR parts use a NCO scheme for Baud (or some smarter fractional baud scheme) as they have less granularity than others.
I had a play with the FT2232H mini module at 12Mbd (PC USB side).
Set the P2 async transmit clock to 80M/6=13.33Mbd, use the 32 bit TX mode, and insert a stretch bit to deal with the 11% difference. Ugly but works for now, and later we'll have more choice over system clock.
jmg what terminal programs were you using to measure? So far only "putty" allows 12Mbd. Realterm, Teraterm, PST don't.
PST is the next best option at 3 Mbd. Wonder if it could offer higher baud rates if it detects a FT2232H?
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'm not using PST. I'm using Processing.org's serial stuff. It can be modified for any arbitrary Baud rate... Testing everything using Propeller2Explorer... will post the current revision in the next few days.
I hit the wall right at 3Mbaud, but I have some overhead in there that might cause an undershoot... might be higher:)
I had a play with the FT2232H mini module at 12Mbd (PC USB side).
Set the P2 async transmit clock to 80M/6=13.33Mbd, use the 32 bit TX mode, and insert a stretch bit to deal with the 11% difference. Ugly but works for now, and later we'll have more choice over system clock.
This should also allow test of 8,6,4 MBd in 8b modes ?
jmg what terminal programs were you using to measure? So far only "putty" allows 12Mbd. Realterm, Teraterm, PST don't.
PST is the next best option at 3 Mbd. Wonder if it could offer higher baud rates if it detects a FT2232H?
I use an in-house Terminal, but pretty much any half decent terminal should just feed Baud (32b) to the Driver, and report if the Driver coughs. ( That means you do need the correct target USB connected before change of Baud. )
Most modern drivers also snap-to-nearest, so you can ask for 'off' baud rate, and they give the nearest possible.
Comments
Yes, that's tonight.
I also put more explanation into all the other modes.
All that's left to do now is the serial modes.
I've been playing with the smartpins today. Excellent work!
Looking forward to playing with the serial modes.
Cheers
Brian
Try to make something out of the custom state machine modes. The doc's are complete now, but small.
I'm all for documentation... but less is definitely better.
I still can't read the documentation for the P1:) For the P2, I'm trying.
For the unwashed masses, examples are really where it is at.
Beautiful work. Take a few breaths.
Rich
There seems to be a lot of stuff about state 0 and state 1 and switching back and forth.
But, the only difference in the two states seems to be which way z gets shifted.
I'm trying to imagine what this could be used for...
SPI input maybe?
Just trying to figure this out. Looks like you shift in the previous value though. So, if you did this on rising edge of clock, you'd get the wrong data. Guess you'd want to shift in on falling edge of clock?
That's how it is in two-bit mode. The state thing was really designed for the one-bit mode, where you have two different rule patterns. I just tried to make use of the state mechanism in two-bit mode, and I figured it could just reverse the meaning of set one, increment, and shift right.
.
So, if you don't need high speed DAC output, this is a lot simpler.
Is there a way to just set an 8-bit DAC value with no PWM or dithering?
Wait: I guess if the lower 8 bits are all zero, there is no dithering, right?
Here's one that actually works! (receives characters on P63 and sends them back out on P62, these are the pins connected to USB serial)
Maybe the unused interrupts 14&15 could be used by the smartpins?
There will be a limit to what/how many can remap, but I would expect the commonest items like
RxByteReady (in Rx) and TxShiftDone (in Tx) will be mapped ?
I'm not sure anymore if waitedg waits for beginning of character or end of character.
Have to test these things...
I'll have to wait for the last piece of the Smartpin doc's for my (doh!) moment.
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.
what we have are Stated Pins
Seems there are a few tests stalled for need of better information.
The DOCs header part says
I think each mode needs a simple table showing what
DIR
IN
OUT
do in Read and Write cases, in that Smart Pin mode.
If more than one flag can be mapped, that choice should be listed.
And that's at 80MHz. I wonder what the current speed estimate is for the final product...
3MBd is only modest in the modern scheme of things.
Chip says the Async limit is SysCLK/3, and EXAR have 25MBd UARTs.
FT232H series UARTs can do 12Mbd continual, and also 8MBd, 6MBd, then 24M/N
It should be possible to test 4MBd and 8MBd with 80MHz SysCLKs
At these high Baud rates, some parts insert more stop bits, so you can drop that slightly.
The FT232H (HS USB) seem to work fine to 12MBd and the EXAR parts have the best FS Serial speeds we have measured, you can set those to 12MBd and they averages something over 9MBd.
Serial transmitter status simply is done using INx.
Do you have FT2232H or FT232H there, to test 4-6-8MBd ?
If you happen to have EXAR parts, here are my quick Baud setting checks (for 80MHz SysCLK matching rates )
Looks to sustain up to 80M/9 and 80M/8 can set, but USB limits to 4.6% under sustained speed.
Accepts 11.428571Bd and 12MBd but refuses on 13.333333MBd (no surprise
I think these EXAR parts use a NCO scheme for Baud (or some smarter fractional baud scheme) as they have less granularity than others.
Set the P2 async transmit clock to 80M/6=13.33Mbd, use the 32 bit TX mode, and insert a stretch bit to deal with the 11% difference. Ugly but works for now, and later we'll have more choice over system clock.
jmg what terminal programs were you using to measure? So far only "putty" allows 12Mbd. Realterm, Teraterm, PST don't.
PST is the next best option at 3 Mbd. Wonder if it could offer higher baud rates if it detects a FT2232H?
I'm not using PST. I'm using Processing.org's serial stuff. It can be modified for any arbitrary Baud rate... Testing everything using Propeller2Explorer... will post the current revision in the next few days.
I hit the wall right at 3Mbaud, but I have some overhead in there that might cause an undershoot... might be higher:)
Your stuff is almost exactly the same... go figure:)
I use an in-house Terminal, but pretty much any half decent terminal should just feed Baud (32b) to the Driver, and report if the Driver coughs. ( That means you do need the correct target USB connected before change of Baud. )
Most modern drivers also snap-to-nearest, so you can ask for 'off' baud rate, and they give the nearest possible.