So Frustrated Again - Documentation of P2!!!

Christof Eb.

Hi there Parallax!
Do you know how frustrating the -beep- documentation of P2 is???

I am trying to implement/use the Goertzel Mode in Taqoz and have now spent several hours to try to guess.
In https://docs.google.com/document/d/1gn6oaT5Ib7CytvlZHacmrSbVBJsD9t_-kmvjd7nUR6o/edit# page 31, there is
1111 dddd 0ppp p111

Then on the page 32 there is a table about ppp. Only 3 p????
"For modes which involve less than 8 pins, lower-order %p bit(s) in D[19:19..17] are used to further resolve the pin number(s)."
Oh yes, fine, but HOW on earth for DDS/Goertzel?

Then on page 31 we have:
%PONMLKJI_HGFEDCBA_ponmlkji_hgfedcba
What is the meaning of this reversed alphabet supposed to be at all?

The example on page 37 pins 0 and 1 are used, so no help there.

On page 36: "with the lower bits being the sum of the %T bits and the topmost NCO bits."
I do not understand what this shall mean.

The distributed and unclear documentation of P2 is so very much frustrating! What use is it to pay for a processor with all these SMART modes, if you have to spend days to find out, how they might work?
I sadly cannot recommend to use P2 to anyone on these circumstances.
Christof

pik33

These letters means different bits, so this: %PONMLKJI_HGFEDCBA_ponmlkji_hgfedcba means 32 different bits and this: %dddddddd_cccccccc_bbbbbbbb_aaaaaaaa means 4 different bits, every of them repeated 8 times as in the pattern

Goertzel, in page 37:

The four-pin input block is selected by the %pppp bits in D/#[22:19],

You have 4 pins used in this mode, P2 has 64 pins, so there are 16 banks of 4 pins and 4 "p" bits are needed to selet the bank.

But yes, the proper "Propeller 2 manual" and set of "Propeller 2 Application notes" - as it was done for a P1 - is needed.

Christof Eb.

@pik33 said:
These letters means different bits, so this: %PONMLKJI_HGFEDCBA_ponmlkji_hgfedcba means 32 different bits and this: %dddddddd_cccccccc_bbbbbbbb_aaaaaaaa means 4 different bits, every of them repeated 8 times as in the pattern

Goertzel, in page 37:

The four-pin input block is selected by the %pppp bits in D/#[22:19],

You have 4 pins used in this mode, P2 has 64 pins, so there are 16 banks of 4 pins and 4 "p" bits are needed to selet the bank.

Unfortunately your answer gives me more things to wonder about.
So the table on page 32 is not valid here? It says "in EVERY MODE".
And in this case the pin groups are non-overlapping?
And pppp refers only to the input pins? "INPUT block"
How do I define the output pin?

evanh

There certainly is a lot of small details to setup a streamer. Bear in mind I've not used either of these streamer modes, but some notes from a quick read:

For DDS output, you're driving DAC outputs. There is the four %dddd bits for selecting various channel mappings of the streamer's four DAC channels. And then those channels, named X0..X3, have to be routed via the pin modes of a group of four consecutive (I think) pins you want those channels to be piped to. Config gets a little messy.

For Goertzel input, it requires ADC PDM bitstreams. Therefore a number of ADCs would need configured, bypassing the smartpin, to supply the bitstream at full sysclock. Not the scope smartpin mode, that's different again.

The %pppp bits here are used only for ADC input pin group selection. 1-of-16 four-pin groups.

evanh

A suitable pin mode to get ADC raw PDM bitstream:

    wrpin( pinnum, P_ADC_10X )

A suitable pin mode to route a DAC channel to a DAC pin:

    wrpin( pinnum, P_DAC_990R_3V | P_CHANNEL | (cognum << 8) )

Ariba

@"Christof Eb." said:
...
And in this case the pin groups are non-overlapping?
And pppp refers only to the input pins? "INPUT block"
How do I define the output pin?

Yes the pin groups are not overlapping, you select a 4 pin group with pppp bits. For these group the 4 bytes of the LUTram are mapped to the 4 pins.

The input and the output pins are the same. Normally you either output a DDS frequency or analyze an input frequency via ADC and Görtzel. You can also do both on the same pin to measure the damping of a certain frequency, but then you are limited to the 4 possible output impedances of the DAC (990, 600, 123, 75 Ohm).

Andy

VonSzarvas

Some other references:

This doc has a table with the Built-In Symbols for Smart Pin Configuration that I often like to refer to for a clean view of all the bits : https://docs.google.com/document/d/16qVkmA6Co5fUNKJHF6pBfGfDupuRwDtf-wyieh_fbqw/edit#heading=h.3lni8j2y6qpx

And in Jeff's latest manual he's covered the SmartPin topic in an alternative way : https://docs.google.com/document/d/1_b6e9_lIGHaPqZKV37E-MmCvqaS3JKYwCvHEJ-uCq8M/edit#heading=h.whuv85gp7nps

Christof Eb.

Ah, some other guessers (sorry) thank you.

@Ariba said:

The input and the output pins are the same.

At the moment I do not think so! DAC channels are defined by their WRPIN command. Here you have to specify the cogid of the data source. But guessing goes on.

@VonSzarvas said:
Some other references:
....
And in Jeff's latest manual he's covered the SmartPin topic in an alternative way : https://docs.google.com/document/d/1_b6e9_lIGHaPqZKV37E-MmCvqaS3JKYwCvHEJ-uCq8M/edit#heading=h.whuv85gp7nps

Hahaha! Very funny!
Have you had a look into that paper? Streamer and DAC channels (setdacs) are not covered at all.

VonSzarvas

@"Christof Eb." said:
Hahaha! Very funny!
Have you had a look into that paper? Streamer and DACs (setdacs) are not covered at all.

What, the doc that says "Manual - Draft 20211015". ?
The idea of sharing that was to just take what you can from it (or not); sometimes a little piece is enough to complete the puzzle.

Sorry I didn't understand fully what you wanted. I'll leave the topic for someone else to help you.

Ariba

@"Christof Eb." said:
Ah, some other guessers (sorry) thank you.

@Ariba said:

The input and the output pins are the same.

At the moment I do not think so! DAC channels are defined by their WRPIN command. Here you have to specify the cogid of the data source. But guessing goes on.

Yes you have to use WRPIN to specify the low level pin mode (DAC, ADC, both). But you need to do this setting for the pins that you have specified for the DDS/Görtzel mode.
A year ago I was able to output a sine wave with the DDS mode, just by looking at some examples. Now I don't remember the details. But it should be possible to find the infos.

Andy

Christof Eb.

@pik33 said:
....
You have 4 pins used in this mode, P2 has 64 pins, so there are 16 banks of 4 pins and 4 "p" bits are needed to select the bank.

But yes, the proper "Propeller 2 manual" and set of "Propeller 2 Application notes" - as it was done for a P1 - is needed.

Thank you very much, the "16 banks" input led me to ignore the "overlapping 8 bits" and experiment with a bank number 11 and then 10. This was very helpful in the guesswork.
Christof

ManAtWork

@"Christof Eb." said:
Do you know how frustrating the -beep- documentation of P2 is???

I am trying to implement/use the Goertzel Mode in Taqoz and have now spent several hours to try to guess.

Hi Christof,

I don't know why you want to use Taqoz for this. I haven't used it for anything else than some very simple tests in the serial terminal. I find it very confusing and wouldn't recommend it for any project requiring more than several lines of code. But I think I'm quite experienced with the Goertzel mode. I've managed to use it successfully in several applications: capacitive sensors, encoders and QPSK modulation. We're located not so far away. So if you bring some beer along with your questions I think I could explain how it works and how the streamer has to be set up. But I use Spin and Pasm and have no idea about Taqoz.

ManAtWork

But I totally agree. Finishing the P2 documentation should be the #1 priority for Parallax. I haven't heard anything abou it since March this year....

Christof Eb.

@ManAtWork said:
I don't know why you want to use Taqoz for this. I haven't used it for anything else than some very simple tests in the serial terminal.

This is off topic of course and I don't want to convince anyone about Forth.
The advantage of Forth is, that it combines speed with an interactive language. To be fast it has to be simple, which makes it a bit confusing. On the other hand, the advantage is, that you always have a simple user interface built in. This you can also always instantly use to debug. This leads to the effect, that you write small snippets of code, which can be tested directly effortless. And this leads to the effect, that you constantly make small progress. I use Forth for ESP32, on top of Arduino-CC too and even with a project for Raspi4. It is nice to have a common language for all of these platforms. :-) In my experience Forth is a much better compromise for an interactive language on a microcontroller than Micropython.
To use Goertzel we all have to use assembler at P2 because of all the very special instructions, so this is the common boat here. Nice offer with the Nachhilfe by beer, thank you, we'll see...

ManAtWork

You're right, every programmer has his own favourite programming language. I just wanted to say I can't help you with Taqoz. But the instructions, registers, smart pin modes and so on should be the same for Goertzel in any language.

Phil Pilgrim (PhiPi)

Here are the facts of life, regarding documentation:

1. Writing documentation sucks. You've just completed a very heady development phase, everything finally works, the champagne has finally been poured and run out, the guests have left the party, and now you're left alone in the dark with this hideous task.
2. Without documentation, you don't have a product, just a mere gadget -- a device. Oh, sure, the fanboys will moon over it and try to figure it out, but try selling it to customers who count for real income. Nope.
3. Writing documentation requires discipline. Let someone else weed the garden, clean out the barn, or whatever other avoidance tasks appeal to you. Stop. You have to sit down, strap yourself in, and just do it.
4. The best -- and worst -- people to assign documentation tasks to are the developers of the device. Best, because they are the ones who have the most intimate knowledge of the gizmo. Worst, because they're the ones least likely to have the discipline to complete the task. They would rather add features like "Parameterized OBJ Instantiations" or some such, or start work on the next iteration, than to buckle up and finish the job they started years ago.

A perceived lack of P2 documentation is not going to get Parallax anywhere with this device to turn it into an actual product. It's up to the P2's primary developer to overcome this perception with solid, comprehensive documentation. I hope he's finally up to the task.

-Phil

frank freedman

I mostly agree with Phil's points. BUT NO!!! Don't even think of having Chip do the final documentation. They need to hire a real writer with the experience to be able to write clear and usable work that customers follow in as short a time as needed to do this. Developers can't usually do this, too many new ideas and off task they go. Let the writer write and let the writer pin down the developer as often as he needs knowing he may have to occasionally Velcro the developer to a chair in his office on (more than a few?) occasions to get the job done. There are quite a few out in the forums that could very effectively review the docs as the project progresses. That could lower the cost and maybe help proofing the text and validating/contributing examples for possible use in the final documentation.

AJL

@"frank freedman" said:
I mostly agree with Phil's points. BUT NO!!! Don't even think of having Chip do the final documentation. They need to hire a real writer with the experience to be able to write clear and usable work that customers follow in as short a time as needed to do this. Developers can't usually do this, too many new ideas and off task they go. Let the writer write and let the writer pin down the developer as often as he needs knowing he may have to occasionally Velcro the developer to a chair in his office on (more than a few?) occasions to get the job done. There are quite a few out in the forums that could very effectively review the docs as the project progresses. That could lower the cost and maybe help proofing the text and validating/contributing examples for possible use in the final documentation.

+1

ManAtWork

@"Phil Pilgrim (PhiPi)" said:
Here are the facts of life, regarding documentation:

1. Writing documentation sucks. You've just completed a very heady development phase, everything finally works, the champagne has finally been poured and run out, the guests have left the party, and now you're left alone in the dark with this hideous task.
2. Without documentation, you don't have a product, just a mere gadget -- a device. Oh, sure, the fanboys will moon over it and try to figure it out, but try selling it to customers who count for real income. Nope.
3. Writing documentation requires discipline. Let someone else weed the garden, clean out the barn, or whatever other avoidance tasks appeal to you. Stop. You have to sit down, strap yourself in, and just do it.
4. The best -- and worst -- people to assign documentation tasks to are the developers of the device. Best, because they are the ones who have the most intimate knowledge of the gizmo.

I fully agree.

Worst, because they're the ones least likely to have the discipline to complete the task. ...

Well, it's not only the discipline. The original developpers often know very well how it works but they don't know very well what doesn't work. Because they "always press the right button" they have no idea what problems and misunderstandings may arise and what questions the customers come up with. And they are very efficient what is a good thing when coding but not when writing documentation. Users with less background information might not understand the short descriptions full of technical terms.

So it's a good idea to let at least somebody with less skill proofread the documentation to find out what needs more detailed explanations.

ke4pjw

@ManAtWork said:
Well, it's not only the discipline. The original developpers often know very well how it works but they don't know very well what doesn't work. Because they "always press the right button" they have no idea what problems and misunderstandings may arise and what questions the customers come up with. And they are very efficient what is a good thing when coding but not when writing documentation. Users with less background information might not understand the short descriptions full of technical terms.

So it's a good idea to let at least somebody with less skill proofread the documentation to find out what needs more detailed explanations.

I deal with this on the daily at my job. Separation of duties with a cohesive team produces quality. It's good to have a team with Rockstars, and not so good to have a team with Cowboys. Cowboys and Rockstars are great, when it's just them, but their quality usually has a ceiling.

Wuerfel_21

TFW your documentation consists entirely of obscure song lyrics and various permutations of "yeeee haaaaw!".

Most companies don't hire Pirate developers, they're tired of the lwasuits.

Maciek

Some will hate me for saying that but...

Lack of proper documentation or, even worse but not that rare, lack of any documentation is a proof of poor management. And that does apply not only to software development.
I witness that daily.

You'd be very surprised to see how highly creative people get when you ask them the reasons for not preparing proper documentation. The managers are the best inventors in that respect.

The fingers of my left hand are enough to count all of the occassions over the 9 year period when the author of a (pretty good) documentation asked by me why on earth he even bothered said "because I actually need it and I need it to be good". I was shocked to hear that at first but as it later turned out, he was also the occassional mainainer of that code. I have never ever heard such statement from any developer I know and I know a big bunch of them.

JRoark

@Maciek said:
Some will hate me for saying that but...
Lack of proper documentation or, even worse but not that rare, lack of any documentation is a proof of poor management.

It can also be a sign of Life Happening (tm).
I once had a client call me lazy because something wasnt happening on the timeline he wanted. I was in radiation barfing my guts out when I read that email. Sorta changed my perspective on deadlines… and clients.

Patrick1ab

I remember this forum entry / announcement from end of last year, where many were craving for documentation and examples:

https://forums.parallax.com/discussion/174203/what-can-parallax-achieve-for-you-in-2022-come-on-tell-us#latest

Unfortunatelly there is not much left of the year 2022 to reach this target :-(

Edit: Wait a second. I just saw official document releases on the P2 documentation webpage. Haven't checked so far, if these are just snapshots from the existing Google documents or if they are completed in terms of no chapters missing or placeholder.

Maciek

@JRoark said:
It can also be a sign of Life Happening (tm)....

True, but I was refering to the usual course of things.

What you describe is a rather unusual circumstance every sensible person will hopefuly undestand. I have never encountered such an explanation as yours. Things happen in life. In mine too.
And some clients are, well...unsympathetic, to say it politely.

JRoark

New docs have indeed landed at propeller.parallax.com. Not “preliminary” or “interim”. These are released docs. Ken & Jeff & Stephanie came thru!
Whoo hooo!!!

Wuerfel_21

It doesn't say "preliminary", but it is. Try finding out about MOVBYTS or SEUSSF or MIXPIX.

JonnyMac

It's an initial release -- every manufacturer does it, and makes improvements as warranted. Waiting on the perfect version is why P2 development was extended to 14 years.

JRoark

@JonnyMac said:

It's an initial release -- every manufacturer does it, and makes improvements as warranted. Waiting on the perfect version is why P2 development was extended to 14 years.

Agreed. Cant name the number of times I’ve looked at a data sheet and said “wait, what? Has that changed?” Yup, it has. Usually for the (much) better. Example: I have an early release of the DS3231 RTC. It was ~10 pages. I also have that same sheet in a later release that is 20+ pages.

I’m VERY happy to have officially released docs.

Christof Eb.

Hm, is it a good sign, that the documents are no more called preliminary???? I fear: no.
I did not find better information in these documents regarding Goertzel, Streamer, WRLUT.

@"Ken Gracey" , is Parallax still actively working on these Documents?

I do ask this, because I again have lost about 3 hours this week just because of a restriction of the command WRLUT is not mentioned in the docs. (Or maybe hidden very well, you never know.) https://forums.parallax.com/discussion/174969/pasm-question-wrlut#latest .

I am quite convinced, that P2 could be a mains to reduce complexity in projects and therefore could make things more easy for your customers. Well it could, but for P2 you have to learn the special language SPIN2 (at least to understand examples), PASM2 with a huge number of special instructions. And when you are willing to learn them, you discover, that in the now official Assembly Language Manual not even a very often used WRLONG is covered in detail.

RossH

These days I enjoy writing the documentation almost as much as I enjoy writing the software. One without the other seems like only half a job.

Bu perhaps I am just getting old