default baud rate and clock frequency for P2?
ersmith
Posts: 5,909
in Propeller 2
Just wondering what folks' opinions are on the default clock rate and frequency for P2 programs. On P1 a lot of programs ended up using 115_200 baud and 80 MHz. Early P2 development tools either defaulted to this (p2gcc) or used 230_400 and 160 MHz (fastspin). That was fine for development, but now that we've got (approximately) final hardware and we've seen that things are stable at a higher clock frequency, I wonder if we should establish a kind of informal convention for baud rate and clock. It would just be a convention, of course -- particular applications may have particular requirements on clock frequency or baud, and naturally they'll use whatever is appropriate. But it would be convenient if the tools and terminal emulators defaulted to some widely used values.
Here are some thoughts on baud rates:
For clock rates, I honestly don't know what the current thinking is. 160 MHz was definitely a conservative choice (probably too conservative!) motivated by the convenient fact that it was twice the common P1 clock frequency. But I think a higher frequency might be better for many applications. Do we have a sense now of a "safe" upper bound? At one point the chip was spec'd to 180 MHz, but I think we're up to 252 MHz now?
Again, all this is just thinking about conventions or defaults. I'm definitely not trying to suggest that all applications must all use the same clock speed or baud rate! For programs where neither of these really matter, though, what should we pick?
Here are some thoughts on baud rates:
115_200: matches common P1 baud rate, but is slow 230_400: double P1 rate, so convenient, and good for bit-banging. But slow for file transfers and such. 921_600: I think some terminal programs max out at this. Decent speed 2_000_000: max that the ROM bootloader supports?921_600 seems like a good compromise between speed and widespread support. OTOH for tools like loadp2 that we have control of perhaps 2_000_000 is better, especially if we're doing things like serving files or doing TCP/IP over serial. The only drawback of these higher speeds would be that bit-banged serial becomes tricky, but honestly for P2 people should be using the smart pins for serial I/O so I think that's a very minor consideration.
For clock rates, I honestly don't know what the current thinking is. 160 MHz was definitely a conservative choice (probably too conservative!) motivated by the convenient fact that it was twice the common P1 clock frequency. But I think a higher frequency might be better for many applications. Do we have a sense now of a "safe" upper bound? At one point the chip was spec'd to 180 MHz, but I think we're up to 252 MHz now?
Again, all this is just thinking about conventions or defaults. I'm definitely not trying to suggest that all applications must all use the same clock speed or baud rate! For programs where neither of these really matter, though, what should we pick?
Comments
I tend to run the serial link rather slow: 230k. That setting just seems to work best for me across multiple platforms, operating systems, and generations of computers.
If you want to enable video, 252MHz is only really good for official digital HDMI/DVI output at VGA resolution. It may be just a subset of people who want/need to use that.
Another reasonable clock speed choice that still supports analog video might be 200MHz - with that rate you could get both analog VGA at 25MHz and SVGA at 40MHz and potentially close to XGA 65MHz dot clocks (using 66.66MHz) using simple integer dividers of the base P2 frequency. It would also let you run the existing HyperRAM board at its rated speed for 200MB/s which is handy.
If there is going to be a default we'd probably want to pick some rate that also is known to work fine with USB in case there are any dead zones there (from memory I think there were a few frequencies that garryj encountered some timing issues).
Ideally people can write objects that work over a range of clocks by patching their code appropriately, though in some cases that makes things rather difficult, and for some synchronous applications that may not be possible.
What will limit many is thermal or power restrictions. If they don't want to use any heat-sinking for example, then the die will get warmer and they may be limited in clock frequency.
As for a spec, the OnSemi rating is now at 175 MHz. 250 MHz would be a convenient spec for Parallax to support given the desire to list DVI/HDMI output as supported.
loadp2 has defaulted to 2Mbaud for downloads for a while now, and I haven't heard of any issues. After the download it switches to whatever the user specifies for the terminal speed, which is usually 115200 or 230400. But if the download is working well then there's probably no reason not to run the terminal at the same speed.
I think 115200 is a good default baud rate. It is supported on virtually every system, and the rate is sufficient for most purposes. When a higher rate is needed, such as for transferring large files, it can be set by the program.
If it were to change then I'd suggest we shift to say 921,600 (8*115200), or 2M baud. Haven't looked to see if PCs/Macs will work at 2MB or if they need to be some binary multiple of 300 or 1200??? @jmg - you there?
As for xtal, IIRC P2D2s are 12MHz, P2-EVALs are 20MHz, so 0.5/1/2/4MHz could be a common divide by base.
148.5MHz was a sweet spot for VGA IIRC, so 297MHz might be a nice overclocked speed ???