Feedback on large P2 project?

Martin Hebel

Hi All,
For those that don't know me, I'm Martin Hebel, Associate Professor teaching technology (not engineering/CS) at Southern Illinois University and owner of SelmaWare Solutions (StampPlot/MakerPlot/StampDAQ software) and an early user (pre-release) of P1 including a book chapter in the Propeller text and XBee text using it, author of XBee Object and BS2 Function Object for P1. In any case... It's been about 6 years since I did anything serious with a Propeller.

The P2 has me intrigued and a few of my students will be applying for a undergraduate assistanceship to do a large scale project with the P2. While I won't get into details now of the overall focus, here's what I know it will need to do:

- Output to HDMI monitor for active graphical information.

- Be able to collect data from USB communications device - This may be tough one, but want to accept data from RTL-SDR digitally broadcast data. I have access to Linux code for same use so should be able to port it over?

- Interface with I2C and multiple other input devices for monitoring environmental parameters.

- Possibly produce output frequency of modulated digital around 1Ghz?

I've look over the datasheets, seen USB included, HDMI out, lot of great stuff the P1 had of course.

I've ordered the P2-ES Accessory board adapters.

1. So, it looks like all this is do-able??

2. When it comes to Programming/Objects for HDMI, I2C, USB, etc - are these and examples available yet?

3. As to languages I have FlexGUI now (nice job), is one language/editor preferable over the other for this? Objects restricted to Spin? etc?

4. Are available objects needed for this available now or in near future?

The real work on this probably won't start until summer and they have 1 year funding (if approved), but I'm looking to plan things out now, so if things WILL become available soon, please keep that in mind if you have feedback!

Thank you Chip and all the developers here for your efforts on the P2!

-Martin Hebel

Rayman

So, HDMI is limited in most cases to VGA (640x480x60Hz) resolution. Although I think you can get higher at 24 fps video, for TVs that will accept that. And, this is with "overclocking" the P2 to 250 MHz or more.

USB is provided at the lowest level and limited to full speed (12 MHz). If you want to use a USB 2.0 device, it has to work at full speed too.

garryj has an excellent 1-cog keyboard or mouse or k-m combo driver for USB.

There are a few HDMI examples around.

Check out propeller.parallax.com for a lot of info

FlexGui, the GUI for Fastspin is really nice. And, lets you include C and BASIC code in your Spin project.

I can't imagine how you could do 1 GHz digital with P2 at 250 MHz. There's probably some chip you could use to help with that though.

Rayman

Personally, for your USB, RTL-SDR digitally broadcast data thing, since sounds like runs under Linux...
I'd try to see if it works with Raspberry Pi Zero and then connect that to P2.
I've done this for controlling HDMI output of piz already...

Martin Hebel

Thanks Rayman, the plan is to get it down to the P2 only for processors if possible.

I saw that link you gave, but missed the "More Software and Examples" link from it! Thanks - looked too much like developers/testers work before that.

-Martin

whicker

The FM modulated signal at 1 GHz isn't possible, but you could certainly send the data out to a circuit or module that does that.

Martin Hebel

Figured, though I'd ask anyway whicker, I know Chip use to do some lower frequency RF examples if I remember correctly.

Rayman

a year or maybe two ago, I posted a USB sniffer program for P2.
It uses the P2 to record the exchange between a USB device and a PC.
Later, I'd play back the PC part to the device and was able to get things like HIDs talking...

I think I'd start with something like that for your USB device and try to figure out a simple initiation and data retrieval scheme...

BTW: Welcome back! I think you were at a Propeller Expo or two, right?
Sounds like there may be a new one soon...

Rayman

BTW, since you've been around here longer than me, you might want to check out the SpinEdit GUI for P1 & P2.
I should have posted it here, but it's over here.

potatohead

Yes, and those will make sense, and can be improved on P2. It's just the upper frequencies are bounded by the P2 clock, which looks to be 400Mhz and below.

Many of us are running 250 without even noticing. That's a lot like running P1 at 100Mhz was. Pretty much no brainer. Above that, some considerations must be taken into account, testing, etc... I've not taken mine much over ~250, but others here have pushed it.

Maybe a lower frequency input to some circuit would make sense. What's the data rate? Maybe a 1Ghz carrier modulated by a P2 would work. Otherwise, yeah. That part of the project is likely to need a chip.

FastGUI is, for the time being, the goto dev tool. That may well remain true, given the excellent work Eric has done to allow mix and match languages to make programs. Impressive.

In general, Spin 2 on P2 is likely to run fast enough to be comparable to P1 PASM speeds when Chip gets his interpreter done. And right now, Eric has made a good look at Spin 2 available in FastGUI as a compiled option. Spin 2, in some form, is extremely likely to be available and robust by the time your students get going. And it's fast enough to make a lot of things easy, SPI, etc... can likely just be coded without needing PASM. There isn't a lot of library code yet. But, a lot more code can be compiled and ported easily than was ever possible on P1.

PASM got very seriously extended too. For people familiar, it's fun to program in and robust. Several of us are doing PASM only projects due to the availability of HUB program execute. In short, one can write big PASM programs now, and do so in a largely familiar way. (assuming any other assembly language experience)

On that note, Spin 2 will include the ability to in-line PASM. FastGUI offers that across it's languages today too. This should make some tasks considerably easier. No need to make an entirely separate COG program to get fast assembly language routines into your project. Now, those can be in-lined, making things like drivers, fast math, access to the P2 hardware features, a much leaner task. One can just focus on the small sets of instructions that matter and leave the bigger details and framework to Spin and friends. IMHO, this is a big gain.

cgracey

Good too hear from you Martin. I hope the P2 will work out for your project. You've got all of us here, anyway.

jmg

Martin Hebel wrote: »

- Output to HDMI monitor for active graphical information.

Yes, examples and adapter boards with HDMI connectors already exist.

There is some crazy-flexible video work being done in this thread...
https://forums.parallax.com/discussion/170601/all-pasm2-gurus-help-optimizing-a-text-driver-over-dvi/p1

Martin Hebel wrote: »

- Be able to collect data from USB communications device - This may be tough one, but want to accept data from RTL-SDR digitally broadcast data. I have access to Linux code for same use so should be able to port it over?

FS-USB Mouse/Keyboard hosting is already working, I think that used boot-mode ?
My guess is RTL-SDR digitally broadcast data will use a Virtual Com port, so you need to check
a) What Baud rate those use
b) what sort of USB driver those expect (custom, CDC, HID or ?)
Or find the part number of the USB-UART bridge used.

FS-USB work to data has focused on 'get something working' to exercise the USB support silicon and prove it can actually work.
So far, that's modest data rates, and simplest host drivers, but it seems to be SysCLK MHz tolerant, using the NCO created 12MHz
HS-USB is not possible, and IIRC HID is simplest, but limits to 640kBaud sustained speeds. (64 bytes per ms)

Martin Hebel wrote: »

- Interface with I2C and multiple other input devices for monitoring environmental parameters.

i2c master is easy, and P2 can MUX across as many pins as you want

Martin Hebel wrote: »

- Possibly produce output frequency of modulated digital around 1Ghz?

How 'good' does that need to be ? What FM specs do you need ? What exact MHz and license band ?

You are best interfacing to a device that is designed to generate 1GHz.
That could be something as simple as a SAW oscillator (aka classic remote controls) or a synthesiser)
There are many i2c programmable clock oscillators that can do 1GHz, and many RF Transceiver designs for remote controls

Martin Hebel

Rayman, thanks, yup, been to parallax a lot, and one expo in upstate illinois.

Potatohead, thanks for the info dump! Very valuable!

Chip, thanks and nice to be active again. I’m collecting some good info for my students proposal for funding. Fingers crossed!

Martin Hebel

Thanks much jmg, lot of great feedback, appreciate it!

msrobots

Rayman wrote: »

a year or maybe two ago, I posted a USB sniffer program for P2.
It uses the P2 to record the exchange between a USB device and a PC.
Later, I'd play back the PC part to the device and was able to get things like HIDs talking...

I think I'd start with something like that for your USB device and try to figure out a simple initiation and data retrieval scheme...

BTW: Welcome back! I think you were at a Propeller Expo or two, right?
Sounds like there may be a new one soon...

Hey Ray, can you please share a link to this?

I have some nice RGB lit Keyboards I really would like to propellerize, but the company is not willing to share the documentation, so I will need to sniff it out of the data.

Mike

Rayman

USB sniff code is posted here: https://forums.parallax.com/discussion/163830/usb-testing/p3
I don't know if it's the latest, but it's certainly for P123 FPGA board and will need fixing to work on Rev.B silicon...

Circuitsoft

RTL-SDR takes advantage of a debug mode in a particular Realtek DVB-T receiver chip to directly digitize I/Q modulation at any frequency. It is explicitly USB-HS, and so could not be hosted on the P2.

However, what I would probably do is take the RTL-SDR device, pull the Realtek chip off the board, and connect the I and Q inputs directly to smartpins on the P2 and read the data that way. You can also connect the tuner chip (there are several possible in an RTL-SDR device) to the P2 over i2c to program the recieve frequency.

Martin Hebel

thanks, I’ve accessed the tuner with i2c for another project with Arduino, just not sure I’d be able to demod the frequency, if I recall the IF is fairly low, so possible. With some help for my students lol

Martin Hebel

On second thought, it’s just ADC data sent over anyway to FFT equations I believe. Ok..... hmmmm.

macrobeak

"Hi All,
For those that don't know me, I'm Martin Hebel, Associate Professor teaching technology (not engineering/CS) at Southern Illinois University and owner of SelmaWare Solutions (StampPlot/MakerPlot/StampDAQ software) and an early user (pre-release) of P1 including a book chapter in the Propeller text and XBee text using it, author of XBee Object and BS2 Function Object for P1. In any case... It's been about 6 years since I did anything serious with a Propeller."
Hi Martin,
Yes we know you, your work on StampDAQ and Xbee was very well thought our and professionally presented and has helped many of us.
If you apply the same standard to P2 it will be greatly appreciated and we look forward to it.

Martin Hebel

Thanks Macrobeak, much appreciated. I’ll see if I can add something worthwhile for the P2 users!

JRoark

Using an outboard synth to get into the GHZ region with a P2 should be pretty straightforward. I’ve been looking at this critter for an SDR-like project of mine, but there are many others depending on your needs. https://www.everythingrf.com/product-datasheet/526-326-8v97003

Peter Jakacki

It was also Martin's Forth code that I adapted for my VGA Mandelbrot plots.

Cluso99

Martin,
FWIW I did 1920x1080 VGA 1-bit code about a year ago. Worked quite well and I changed the forground/background colors per line. I was showing characters and clock pics on the display. Only problem with these resolutions as you would know is the memory required, otherwise it's doable.
rogloh Ozprop has released a driver (beta) for composite/vga/hdmi. Sorry Roger

ozpropdev

Cluso99 wrote: »

Ozprop has released a driver (beta) for composite/vga/hdmi.

Correction: That would be @rogloh's driver.

Martin Hebel

Thanks all, good stuff to look at!

Hope you don’t mean me, Martin, for Forth Peter- wasn’t mine! Though have enjoyed using Forth years ago!

Peter Jakacki

Martin Hebel wrote: »

Thanks all, good stuff to look at!

Hope you don’t mean me, Martin, for Forth Peter- wasn’t mine! Though have enjoyed using Forth years ago!

There was a Martin_H on the 6502 Forth forums and I thought it was you. My bad

kuba

HS USB should be well doable with a USB PHY chip. Those are not expensive and HS USB systems would use those - typically FPGAs and such. A USB PHY makes life much easier. It also makes FS and HS USB run over the same nibble interface, on same clock, just the nibbles are updated less often (think of something like wait states in Intel LPC). LS reverts to state-signaling, i.e. it doesn't decode data but just sends decoded bus states, still over the same interface. USB3 would be perhaps doable with a bit of discrete logic to widen the PIPE interface to 32 or 64 bits, lowering its effective clock to 125 or 61MHz (does P2 have enough pins for that?). As long as the turnaround can be done quickly enough, it may just work.

jmg

kuba wrote: »

HS USB should be well doable with a USB PHY chip. Those are not expensive and HS USB systems would use those - typically FPGAs and such. A USB PHY makes life much easier. It also makes FS and HS USB run over the same nibble interface, on same clock, just the nibbles are updated less often (think of something like wait states in Intel LPC). LS reverts to state-signaling, i.e. it doesn't decode data but just sends decoded bus states, still over the same interface. USB3 would be perhaps doable with a bit of discrete logic to widen the PIPE interface to 32 or 64 bits, lowering its effective clock to 125 or 61MHz (does P2 have enough pins for that?). As long as the turnaround can be done quickly enough, it may just work.

USB3 may be best managed with a part like FT600, that has a 16b FIFO interface. - but I'm not clear if the clock rules that has can be met by P2.

For HS-USB, there are also medium levels MCUs with HS-USB Phy included, and those may assist P2.
Or, maybe something like this is good enough ?
"The USB3500 is a stand-alone Hi-Speed USB Physical Layer Transceiver (PHY). The USB3500 uses a UTMI+ interface to connect to an SOC or FPGA or custom ASIC. The USB3500 provides a flexible alternative to integrating the analog PHY block for new designs."

Yanomani

Unfortunatelly, Microchip did just listed USB3500-ABZJ as EOL, effective 2020-03-08.

They didn't suggest any replacement, and I wasn't able to locate any USB3500-XXXX version, other than the "-ABZJ".

So recently it was (EOL), it isn't listed as such at any distributor's page.

https://microchip.com/mymicrochip/Reports.aspx

(excerpt):

https://microchip.com/mymicrochip/Data/JAON-05QLFX258/JAON-05QLFX258_Affected_CPN_03092020.pdf?TimeStamp=3/17/2020%206:42:12%20PM

jmg

Yanomani wrote: »

Unfortunatelly, Microchip did just listed USB3500-ABZJ as EOL, effective 2020-03-08.

They didn't suggest any replacement, and I wasn't able to locate any USB3500-XXXX version, other than the "-ABZJ".

So recently it was (EOL), it isn't listed as such at any distributor's page.

Well spotted - with those niche style parts, EOL would always be a background risk.

On the page, there are 'similar devices' links...
https://www.microchip.com/wwwproducts/en/USB3500
I'm not sure where UTMI+/ULPI sit on the evolutionary line, but I do see 'UTMI+ Low Pin Interface (ULPI)'
so maybe USB3370 ?

SaucySoliton

Circuitsoft wrote: »

RTL-SDR takes advantage of a debug mode in a particular Realtek DVB-T receiver chip to directly digitize I/Q modulation at any frequency. It is explicitly USB-HS, and so could not be hosted on the P2.

However, what I would probably do is take the RTL-SDR device, pull the Realtek chip off the board, and connect the I and Q inputs directly to smartpins on the P2 and read the data that way. You can also connect the tuner chip (there are several possible in an RTL-SDR device) to the P2 over i2c to program the recieve frequency.

+1 I would say this is much easier than trying to run the RTL-SDR over usb. Maybe it could do 250k sampling rate on a full speed USB port. I haven't tested that. Although I think the P2 could use an SDR accessory board. The P2 adcs have 40 dB of gain control built in.


The P2 will output useful RF signals at 1 GHz. As that is certainly not in the first Nyquist zone, you'll need a good bandpass filter. This TI paper looks like a good explanation of how it would work. ti.com/lit/an/slaa523a/slaa523a.pdf The P2's main PLL will add a noticeable amount of phase noise. This could be minimized by using as high a clock input as possible. I've tested 80 MHz and it seems to work fine. I would like to try 125MHz or more.