Ways Parallax could help 3rd party tools
ersmith
Posts: 6,052
Here are some ideas I have about how Parallax could help developers, particularly developers of third party tools like compilers and interpreters for the P2. This thread is intended for constructive suggestions, please... let's not rehash old problems.
(1) Please create a stand-alone PASM debugger! The current debugger is integrated into PNut / PropTool, so it is of very limited use with other languages and compilers. Moreover, everybody has to re-invent the debugging wheel. If we had a basic PASM debugger then at least all of the compiled languages would have some basic way to debug.
(2) Provide a set of standard functions for accessing P2 hardware, in the form of function / procedure calls that could be implemented in different languages or compilers. We successfully created a standard C header (propeller2.h) based on functions in an early draft of Spin2; fleshing that out even further and making it an official P2 standard would make it easier to port code between compilers and languages. In particular, we need some consensus (which really should come from Parallax) on names for things like bit reverse that are built in to the Spin2 language but which need to be functions in other languages.
(3) Provide "official" interfaces (e.g. in the form of Spin2 objects) for commonly used hardware like SPI, I2C, and serial. As much as possible the interfaces should avoid using any tricks or optimizations of the Spin2 interpreter, so that they can easily be re-implemented in other languages.
(4) A small thing, but symbolic: could we please change the Spin2 interpreter to use the same locations for clock frequency as all the other languages / code generators?
(5) Other ideas?
Comments
Bit reverse in particular is perhaps a dubious example, as our current
__builtin_bitreverse32is adopted from clang (i.e. de-facto-standard. Well, GCC actually lacks this particular one).Number 3 will certainly attract a lot more users that have a job but don't want to learn the hardware. Which is a large crowd.
FlexC has implemented the clang name, but has Catalina? (I don't think so). And how is bitreverse done in Forth, or Rust, or Go? Having some Parallax standard name for this will make moving code around a lot easier. We can keep the clang/gcc builtins too, but I think it'd be nice to have a P2 standard set of names.
(1), (2), (3) - yes
(4) yes, also define other standard system variables in the low memory.
(5) finish the manual! The P1 has an excellent manual and its form and structure may be used for a final P2 manual.
Number 4 isn't needed as fixed hubRAM addresses at all. All that's needed is to reference the symbols by name, or by function call. What really matters is just the service of knowing the set clock frequency and clock mode and baud and whatever else. So number 4 becomes part of number 3.
One thing I've discovered is important is the board config for oscillator source and frequency. This is a fixed build/compile time parameter, referenced separately from the runtime settable frequency and mode.
CLKMODE_andCLKFREQ_(with trailing underscores) is the symbols I've been using to derive such build info but I don't think it's fully supported by all compiler environments yet.Were it not for everyone in this thread plus others, I would be absolutely nowhere and so I can't thank you enough.
Asking a question is usually a last resort because I don't want to appear lazy but I get pulled in all directions with what I do and so find it very difficult to focus on really understanding everything about these awesome Propellers.
A "Propeller for Dummies" would be a dream come true.
Having stated that, I am also aware of what it's like to run a small business and putting a priority on the things that pay the bills.
Craig
Yes, please focus on things that all users need and that will hopefully increase P2 chip sales. Things like the assembler debugger are really awesome but I fear only useful for a very limited number of programmers or applications.
Documentation. IMHO it all starts with the docs. I’d be over the moon to have a P2 manual like the BASIC stamps and P1 manuals. Those were top notch.
Documentation.
My first Propeller applications were written with lots of Alt-Tab between the propeller manual and Propeller Tool. I still end up with both open today! (Although lately Flexprop often replaces Propeller Tool..) Absolute truth: There are dozens of Propeller-based controls out there in industry that would use some other solution without that awesome Propeller Manual!
I have board designs ready to go with P2, and I am itching to use those P2 capabilities and speed! but I just don't have the time to risk to pull the trigger and use them without clear at-hand documentation.
Second:
Debug is cool as Heck but I don't risk the time to learn it well because I can't always use Windows...
Edit:
I would eagerly pay for a good manual.. See the LUA business model...
My 2c worth ...
The original OBEX was one of the main things that made the Propeller 1 fly. The main benefit it offered was brilliant "reference" implementations, mostly written by Chip himself, who knew the chip better than anyone else. I guess this is a combination of points (2) and (3) in the list above. These reference implementations were easily extended, and also easily adapted to other languages because they were generally implemented in PASM, not SPIN - or at least mostly in PASM with thin SPIN "wrappers" which were trivial to reproduce in other languages.
The Propeller 2 needs the same.
Also, the current trend seems to be to couple PASM and SPIN even more tightly on the Propeller 2 than they were on the Propeller 1. This is great for SPIN enthusiasts, but it just represents another barrier to entry for others, who don't want to have to learn a new language just to be able to use a new processor.
Ross.
OBEX +1.
Remember the 'gold standard' effort? I loved that, even if it only gave me a lofty target when writing my own code. We have great examples right now, but there is just not the S/N ratio that made the original OBEX stand out (I speak of P1 objects as well..)
BTW. In the event I manage to retire before my life insurance kicks in I would surely contribute to such an effort...
Yes, we need a new OBEX.
I wonder why Google doesn't make some kind of configurable database to go along with Sheets, Docs, etc.
It wouldn't be hard to make a website that looks, works, and feels just like the old Obex, but for its underlying database uses either one big Git repository, or one per project. This would make both the Git and non-Git people happy.
Azure Dev Ops allows you to have individual projects. Includes a wiki. Works with GIT. Has issue issue/PBI tracking. Allows you to download as a zip via webbrowser. Even have a "blame" button to see who made the last change. It allows you to assign "owners" of the projects, etc. Also, it is free.
GitHub also has every single one of those features, but it doesn't seem to have been working out for Parallax. Why do you think things would be any different with Azure DevOps?
What I'm proposing is a special Git frontend that doesn't look like Git, but instead like the old Object Exchange. People who can't be bothered with version control can use it like they used the old Object Exchange, or people who'd prefer Git can interact with it via standard native Git commands. Maybe it can also transparently point to external repositories for people who want to host it somewhere else.
OBEX. Bring back the old way. That was what made it so useful. IIRC, it was taken down in part due to spammers and other undesirable issues causing it to be a maintainers nightmare. But as electrodude posts. why not bring back the OBEX using the original interface, just read only. Perhaps have a daily or weekly refresh for new contributions to show up and to discourage "bad actors" from trashing the site if their antics are dumped nightly with automatic refresh of the site. Perhaps an upload function to allow the sharing as in the old OBEX. That was the real secret sauce for those (including me) getting into the P1. I don't have skillset or time to write such a thing, but what's to stop someone else (not Parallax, we need the P2 docs finished) from creating a front end for extracting and creating an "OBEX" that looks and works like the old one?
Bring back the obex interface!
To keep the riff-raff out, maybe tie the ability to write/upload to the obex to a users board profile. If you are a user in good standing, you have write access. Otherwise it is read-only.
IMHO, any solution that forces a GIT-like access is a non-starter. Its just one more roadblock to getting to the good stuff.
@Electrodude when I looked at the GIThub repository for Parallax awhile back, it is done as a monolithic repository, so no one "owns" their objects/projects, as we did in OBEX. Maybe it is how it is organized in GIThub that makes it so difficult to find stuff. I don't know.
I know I like the UI in Azure DevOps a lot better than GIThub.
Kinda ironic when soft peripherals are what the Props are all about.
We know we need to get the OBEX running again.
Hi @ersmith ,
did you get something about a debugger from Parallax? They don't seem to have a SD card file system, so perhaps a deal is possible?