Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i

Seairth · 2016-02-12 04:05

While you're in the docs, can you add some for the state machine modes?

cgracey · 2016-02-12 04:07

Seairth wrote: »

While you're in the docs, can you add some for the state machine modes?

Yes, that's tonight.

cgracey · 2016-02-12 11:42

Okay. I didn't make any example configurations, yet, but I got the doc's done for the configurable state machine modes.

I also put more explanation into all the other modes.

All that's left to do now is the serial modes.

ozpropdev · 2016-02-12 11:51

Thanks Chip!
I've been playing with the smartpins today. Excellent work!
Looking forward to playing with the serial modes.

Cheers
Brian

cgracey · 2016-02-12 12:25

ozpropdev wrote: »

Thanks Chip!
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.

rjo__ · 2016-02-12 23:06

Chip,

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

Rayman · 2016-02-12 23:14

Just looking at the state machine stuff.

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?

cgracey · 2016-02-13 01:56

Rayman wrote: »

Just looking at the state machine stuff.

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.
.

Rayman · 2016-02-13 17:57

So, I think I like the DAC modes, especially since they free you from having to know which cog# you are using to talk to the DAC on a certain pin.

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?

Rayman · 2016-02-13 18:02

I think the pin functions like internal pullup resistor, ADC and that stuff still needs to be added to docs, right?

Rayman · 2016-02-13 19:00

ignore

Rayman · 2016-02-14 00:08

Wishing I could delete earlier posts...

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)

potatohead · 2016-02-14 00:09

Just edit the not working ones away.

jmg · 2016-02-14 01:10

Rayman wrote: »

Wishing I could delete earlier posts...

As a workaround, you can always shrink them down to a single line *skip to update*

ozpropdev · 2016-02-14 01:44

Can the smartpin serial transmitter modes be polled for transmitter busy status?
Maybe the unused interrupts 14&15 could be used by the smartpins?

jmg · 2016-02-14 02:56

ozpropdev wrote: »

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 ?

rjo__ · 2016-02-14 04:27

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:)

Rayman · 2016-02-14 12:24

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...

ozpropdev · 2016-02-14 12:58

jmg wrote: »

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.

Rayman · 2016-02-14 15:16

rjo__ wrote: »

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.

rjo__ · 2016-02-14 19:12

potatohead wrote: »

Oh god, forgive me. This just popped into my head:

**A POG is these silly collectable kid toy: https://en.wikipedia.org/wiki/Pogs

what we have are Stated Pins

jmg · 2016-02-14 20:34

ozpropdev wrote: »

jmg wrote: »

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.

Seairth · 2016-02-14 21:35

Rayman wrote: »

rjo__ wrote: »

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...

jmg · 2016-02-14 22:53

Rayman wrote: »

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...

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

Rayman wrote: »

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.

ozpropdev · 2016-02-14 23:52

All good now, in the end it was a Doh! moment.
Serial transmitter status simply is done using INx.

		pinsety	adra,#tx_pin
.busy		testb	inb,#tx_pin wz		'wait for transmitter
	if_z	jmp	#.busy
		pinack	#tx_pin

jmg · 2016-02-15 00:40

ozpropdev wrote: »

Serial transmitter status simply is done using INx.

Great,
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 )

 EXAR XR21B14x test results
 80M/9 = 8888889  Measure :   1-4.4453M*2/8.888888M = -1.926e-4
 80M/10 = 8MBd    Measure :   1-8M/(4.0002M*2) = 4.99e-5
 80M/11 = 7272727 Measure :   1-7272727/(2*3.6374M) = 2.849e-4
 80M/12 = 6666666 Measure :   1-6666666/(3.3339M*2) = 1.700e-4
 10M              Measure :-> 4.7704M*2 = 9540800  (USB limit)
Measure is Freq Counter Average of continual 0x55 send.

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.

Tubular · 2016-02-15 03:00

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?

rjo__ · 2016-02-15 03:03

Rayman wrote: »

rjo__ wrote: »

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:)

rjo__ · 2016-02-15 03:13

The thing that mystifies me is that when I looked at Chip's example, I could not figure out exactly how to use it.

Your stuff is almost exactly the same... go figure:)

jmg · 2016-02-15 04:27

Tubular wrote: »

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 ?

Tubular wrote: »

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.

Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i

Comments