Listen, we need to have faith in this design. It's a great design. Frankly, the analog capabilities are insane great, and that will drive sales and uses of this chip. As for games, and other expectations, forget them. People will do things a bit differently on this chip, and when they do, it will be robust and attractive to others. The vast majority of P1 users use library code and it's easy, robust, gets things done. A minority of P1 users push it, and they often contribute more library code.
(besides, for games? This thing is a freaking playground! Trust me, no worries on that.)
P2 will play out exactly the same way. And as it does, that simple nature will be there. The difference is more depth. Don't let that depth get in the way of the vision and or set expectations that run counter to what this whole thing has been about. Please.
My suggestions are:
Get the test analog chip, validate it, pay the $50k and do what it takes to begin synthesis with the highest chance of success.
That $50k is our feature lock. The world is telling us to quit messing with it. Great! What we've got is pretty awesome, and very highly differentiated from everything else out there. Know what that means? It makes no sense to begin to compare and meet expectations set by everything else out there. Right? This is by design, deliberate, and that die is cast.
From there?
Chip, you should complete a lean, SPIN with in-line PASM. Make only the changes needed for SPIN to make sense on the larger memory model. We discussed a lot of advanced stuff. Forget it. That can be a revision / addition to the language over time. Make a baseline SPIN+PASM that can be the basis for library code, framework for PASM drivers, etc... and make this simple, like SPIN is today. One file, the works. Keep this lean, simple, so that library code can be used in other environments, including improved SPIN over time. Let the software community handle this. KISS on SPIN+PASM is super valuable for baseline, library code everyone will need and benefit from.
Throw everything out of SPIN that you can, leaving only the easy, useful nubs. This baseline SPIN+inline PASM is the foundation, library, driver, systems code. The smaller and simpler it is, the more easily it can be programmed in, and that also means it will be easier for others, who will build more advanced things, to take that code and use it and build on it. It also means a simple, useful, self-hosted image will be possible. Great. Nail all the basics with one simple effort. And finally, the smaller and simpler this all is, the easier it is to say it's done. Needs to be done.
It can and will be improved later, but our library code, getting the goodies people need to get started need to be written and written on something that will remain stable. This is the closest, easiest to achieve thing. Very important. This is the single most significant factor in the overall success of P1. Driver code written on day one is usable today. I cannot over emphasize just how valuable and important that really is.
All of us need to test / debug. No new features. Really. It's time. We need to find what's broken, if things are really broken and make what is there robust as all get out. Doing that will matter more than any little optimization will. And I'll be frank, the vast majority of users will not care about that optimization, and or will have done it differently surprising us and making that optimization redundant, or marginalized anyway. Have some faith. It's been a long road.
Every ask costs $50K, so don't do it. Debug and mean it.
Anyone with a testing framework could publish, and others could take it and start exercising things.
From there, the moment we can say feature lock and mean it, and I think that $50K is a nice, effective feature lock, real tool production can begin.
Parallax + interested others discuss both C and Blockly and kick off the minimum projects needed to bring those environments to the P2. There is no need to tie SPIN to any of this. Software filters, translators can be made, and will be made, and that's all going to work out just fine.
Anyone interested can begin to build driver / library code just like we did for P1. That code will be baseline, offering up good capability, but no where near the max capability, just like P1. And there are a bunch of things we can do. Video, sound, serial, USB(?), demos on test, measure, analog capture / sample, analog out, math, graphics, PS2 keyboard (worth it, simple), mouse, SD card, basic filesystem support. All of that can be done in the baseline SPIN, and the moment C gets to a place where it makes sense, make the tools that translate a lot of that over, and since it's in-line PASM, it can largely get sucked right in, useful.
Truth is, we don't even know what that max capability is! Just like P1, software will drive a lot of new stuff, and it will be used by people as it happens. Let that happen, and remember, for it to happen, people need a baseline set of stuff they can get going on right away.
We are here, end of a long road. We have a great design. People want it. And they want it for the highly differentiated design. It scratches itches that the other stuff does not, and that is why we did this in the first place! No backing out now, or it's all for nothing! I'll tell you right now, that does not sit well with me AT ALL.
I know people using P1 for products right now who want the P2 and not a damn thing we've got in the can puts them off.
Have some faith here. It's largely done. A ton of second guessing right now will undo a ton of work. Labors of love. And it will kill plans, that spark we need from people to be successful. Don't do it.
@potatohead
I am with on this. I am not the greatest at writing code but I would be happy to work on making projects work with the p2
@evanh
I am attempting to start with ctra, phsa. Wanting to port this code over from P1.
Looking for a simple start with wrpin, wxpin and wypin example to start any of the modes.
Thanks
TAQOZ has lots of modes to set the smartpins. One of the simplest is setting a pin to a frequency, after selecting a PIN you simply type or code the frequency that you want. For example I want pin 8 to output 1 MHz I type:
TAQOZ# 8 PIN 1 MHZ --- ok
The source code to do this has been available for years (literally) in my P2 Dropbox folder. The basics look like this:
WRFNC is a combination of WRPIN and combining I/O modes such as pullups etc but NCOCNT is what is required to convert the desired frequency into a counter value. I use 64-bit precision here but you can get away with 32-bit maths for some stuff.
BTW, if you don't try to translate the Forth code but simply read it left to right and visualize what's on top of the stack as it is being pushed and popped, then you will get the sense of it. For instance SETNCO accepts two parameters "val" and "mode". WRFNC is basically equivalent to WRPIN most of the time so "mode" is %1_00110 from NCO which WRFNC shifts into the correct position etc before it does a WRPIN. then 1 WXPIN simply writes a 1 to the selected WXPIN and WYPIN takes the parameter that is left on the stack which is the count value that was calculated from NCOCNT. That's it!
--- WRPIN in combo with modes - float, shift, combine, wrpin, low (DIR=1)enables smartpin
pub WRFNC ( MMMMM -- ) F 2* _pinmode @ OR WRPIN L ;
The rough equivalent PASM for this WRNC is: (except pinmode is really a hub variable)
dirl pinreg ' F
shl tos,#1 ' 2*
or tos,_pinmode ' _pinmode @ OR
wrpin tos,pinreg ' WRPIN
drvl pinreg ' L
@"Peter Jakacki", you know I really like you but sometimes...
@pilot0315 is asking for a PASM example of using smartpins. A TAQOZ example does just make sense if you allow TAQOZ to be included and used by other languages, what you sadly are not really willing to provide.
What is needed to do so is - for you - quite simple, for people not literate in FORTH simply impossible.
Needed is a TAQOZ blob using the first 64K, adhering to the standard at providing current clocksettings in lower HUB, NOT using any pins at all until told so, NOT using serial pins, but the mailbox you showed me positioned at the last long of that 64K.
It is sad that TAQOZ is not relocatable, but one can get around that with a jmp at location 0 in HUB and restoring the first long of the binary after jumping over it.
If you would provide that blob, the includable TAQOZ, people using C, PASM, BASIC, SPIN or Python would be able to use TAQOZ while staying in the language of their choice, not bound to use the language of your choice for their main project.
This also need to include a change to lsio which sadly resets the smartpins for serial back to TAQOZ, even if one does not want TAQOZ to use serial.
I am begging you now for year(s?) to do so, I do know that you understand the concept, you just stubbornly want people to go full blown TAQOZ regardless if they want to or not.
And again and again I am telling you that this is a BIG mistake. Having a TAQOZ subsystem available to other languages (and the mailbox is proven to work nicely between COGS) would be a tremendous help and would allow a living and growing amount of TAQOZ scriptlets to be run from other languages, shared in the OBEX and Posts like yours.
Just for the cost of one COG, the first 64K of HUB and your willingness to provide it.
@Pilot could just include a TAQOZ object and write taqoz.send("8 PIN 1 MHZ") and would be up and running.
Yes I do understand that you will not need it, yes I do understand you want more people to use TAQOZ. But this IS actual the way to get people to use it, as long as they can keep themselves in the comfort zone of their own language and STILL use TAQOZ.
What I not understand is why you are so vehemently against it.
Wow, it seems the more that one does, and the more that one tries to help, the more one becomes "responsible"!
Since nobody seems to have replied I wasn't going to go into some other language but used TAQOZ as an example. I'd rather teach a man to fish then keep on feeding him every day, until I can't.
However, there is nothing stubborn about my attitude, I do what I can, and hopefully everyone else will do what they can. What a happy happy place it would be then. Sure, I could add this and do that, but considering the volume of work I have made freely available, even just on the P2, who has bothered to even try it? So I don't hang around hoping people will try it, I do it because it works for me and with just as much effort I dress it up and make it available and also try to answer questions.
What is the problem? Maybe if more people just tried it then they would see how easy it actually is and make the changes themselves, for what works for them..
@"Peter Jakacki"
I am one to fish. I appreciate the taqoz examples. I am trying to stay with the p2asm and p1asm TAQOZ is probably great but I have no refereces for it. I in the last year learned PropC and c++. Wanting to really get assembly language down pat. As I noted befor old days of :fortran, basic, cobol, "hated cobol", watfour and watfive.
At this time wanting to stay with one subject the smart pins so I can understand them. Then next to the next subject. I am trying to write tutorials for myself and then later share them.
My version of sodoku.
Thanks to all for your help. Just please bear with me for my questions.
I teach flying and aircraft mechanics. I tell my students that the only way to learn is to make mistakes under controlled conditions. That is how we learn.
@pilot0315 - please note that I could have used pseudo language or just a description but instead I provided a learn by interacting language that is built into the P2 ROM, and also a snippet of equivalent PASM.
Ok, so I've given you the fishing line and a place to fish, all you need to do is cast and wait.
I will try to convince you a last time and then shut up and leave you and TAQOZ alone, like a lot of us do. Maybe for the reasons I mentioned.
@ersmith did a lot of work to make multi-languages in one Project possible. You are not interested in that, fine. A lot of other people are interested in other languages besides FORTH but could USE snippets and get USED to TAQOZ/FORTH.
You are just avoiding the obvious answer by stating:
"What is the problem? Maybe if more people just tried it then they would see how easy it actually is and make the changes themselves, for what works for them.."
That is sadly a wrong statement. It is easy for YOU, not for the average Guy used to program C or Spin or other algol like languages.
I tried over several MONTH to get TAQOZ to cooperate with other Languages in the same Project. It does work but I am NOT able to get TAQOZ to leave the serial Pins alone. Your Mailbox works perfect but just on top of still using the serial connection. I think I have several threads and posts about it. But sadly I am to stupid to do so.
Sadly I am also to stupid to understand how I can convince TAQOZ to 'forget' its original serial connection and JUST use the mailbox. I am sadly also to stupid to understand where and why 'lsio' resets the serial pins back to console after execution.
And to ground you a bit, TAQOZ is easy for YOU, because you wrote it.
I would really like to include TAQOZ in my projects, harness the power it has from a language I know. Even giving it the low 64K and a COG to do so, like I give a COG and some HUB space to a serial driver, a VGA driver, a whatever driver needing a COG and some HUB ram. This is the beauty of a Propeller that you have multiple COGs able to run independently.
But if I need to get stuff done, I can not afford to write every thing NEW in a NEW language. I usually start with stuff I know, add needed objects out of the obex or my own repository. And I would like to integrate TAQOZ too.
In my opinion a reasonable way to work with already existing stuff and one of the key features of P1 and P2. The LEGO system, plug some objects together and write some glue code around it. Amazingly fast and easy to do.
Thanks @ersmith now even doable with objects written in C to include in a BASIC main, Basic objects in Spin, whatever you want is available to you.
It would be WONDERFUL if one could use TAQOZ in that mix. But you - again - stubbornly want people to write EVERYTHING in Forth. Sadly.
And state - basically - that we are to stupid to see the light and embrace Forth completely. Sadly.
I do completely agree with you that you put a lot of work in there and made it freely available, but you complain that " who has bothered to even try it? "
I did and failed miserable again and again. But having a scriptable TAQOZ object able to include into my PASM/C/BASIC/Spin program could change that usage of TAQOZ dramatically.
Not writing EVERYTHING in FORTH, just using it side by side with my main program.
If you do not want to support this, fine. It is just sad to waste that nice opportunity to integrate TAQOZ with all the other languages supported by the P2.
And if you do not provide this, nobody else will be able to do so. So AGAIN - TAQOZ kernel without using serial but mailbox would be the hen's teeth.
I don't think any of us (myself included) have grasped well what Pilot needs to do.
For the target memsic 2125 chip, whats needed appears to be the "counting high states". Every P2 smarpin can do this, so whats needed is the smartpin config - which is then easy to translate into any language.
@msrobots,
Unfortunately I don’t think TAQOZ can be easily called from other program languages, otherwise I am fairly sure Peter would have demonstrated this. If my assumption is wrong, Peter can correct me.
I'd guess he's now after example code ... I think Pilot is struggling with assembly in general. There is lots of subtle details that is commonly learnt by all, we just "know" and don't describe it in any comments because it would be verbose knowledge that "everyone" knows already.
Forth is a good example case for us more experienced to see what Pilot is struggling with. Peter knows his TaqOz better than his own hands but it is so different to everything else for programming that most others just look blankly at the code samples he posts.
@msrobots,
Unfortunately I don’t think TAQOZ can be easily called from other program languages, otherwise I am fairly sure Peter would have demonstrated this. If my assumption is wrong, Peter can correct me.
Well Peter wrote some 5 liner for me to convince TAQOZ to use a Mailbox, I can just not get rid of the serial connection. As far as I understood him this mailbox thing is already there to let TAQOZ run multiple instances on different COGs.
I just don't have the grasp to understand TAQOZ enough to shrink it down to leave the pins alone until told different.
Tbanks for understanding. I am struggling with the smartpins. Looking for a couple of well documented examples to launch the spartpins. I found, see attached, by @ozpropdev. I asked a question in one of the threads about the following:
This is one of the lines of code: wrpin #%1_00110_0,#56 'nco frequency mode
This one is from @abisher: pMode := %0000_0000_000_10100_01000000_00_00000_0
My question is this. The abisher version looks like it follows the protocol in docs. (D/# = %AAAA_BBBB_FFF_PPPPPPPPPPPPP_TT_MMMMM_0)
1. Why is the ozprodev version shorter.
2. If one can shorten the line of code how is that done.
3. If you only use the firdt couple parts, I think that is what is happening, is the remainder automatic.
4. Is the ozprodev a shortcut?
What started this is that I am trying also to port over some p1asm to run different sensors that have p1asm drivers.
I am also writing myself a tutorial in P2asm. Was doing o.k. in P1 pasm and still learing but now have to change gears. If I am succesful I will share this tutorial for critique.
Also about TAQOZ, I do not need to learn a new language until I master the one I am learning now. So I thank you guys again.
Thanks.
Martin
I am struggling with the smartpins. Looking for a couple of well documented examples to launch the spartpins.
Yes, the SmartPin DOCs are terse at best, and certainly need working examples for every mode. This has been suggested/requested before, but Chip is really the only one well enough placed to do this.
I found, see attached, by @ozpropdev. I asked a question in one of the threads about the following:
This is one of the lines of code: wrpin #%1_00110_0,#56 'nco frequency mode
This one is from @abisher: pMode := %0000_0000_000_10100_01000000_00_00000_0
My question is this. The abisher version looks like it follows the protocol in docs. (D/# = %AAAA_BBBB_FFF_PPPPPPPPPPPPP_TT_MMMMM_0)
1. Why is the ozprodev version shorter.
2. If one can shorten the line of code how is that done.
3. If you only use the firdt couple parts, I think that is what is happening, is the remainder automatic.
4. Is the ozprodev a shortcut?
leading zeros are somewhat optional, as the numbers resolve to upper bits zero anyway, so including them is just a matter for clarity.
in PASM the binary code itself is identical, unless you strike a case where the shorter form fits into an immediate opcode ( iirc 9 bits of constant can be encoded smaller ) - above that, 32 bits are needed
If a design uses a lot of smart pins, that can become a lot of init constants to store somewhere.
Most posts from 2017 are still valid as there is little change since the ES verilog and ROM was frozen for the ES chips. And changes since for the new chip due shortly are minimal.
BTW there has been no source of the final ROM posted. AFAIK chips booter was not changed, my Monitor code is unchanges and the same address, some tweeks to the SD boot code. Not sure if TAQOZ was updated ???
Pilot, are you clear on the shortening of numbers thing now?
Perhaps the binary 0/1 base makes things more confusing. Shortening binary numbers follows the same rules as decimal base, eg adding 00900 to 00030 gives 00930, as does 900+30=930=00930
Basically, the leading zeroes are redundant, but trailing zeroes are necessary
The other thing is that Chip has coded the P2 design in a way that zero means 'default config' for many things. For instance the pin redirect bits AAAA and BBBB - setting these to 0000 means they just do the default thing of not redirecting to a neighboring pin. Because these upper bits are zero, we can use the 'shortened' number where the leading zeroes are not expressed (causing them to be interpreted as zeroes)
This is one of the lines of code: wrpin #%1_00110_0,#56 'nco frequency mode
This one is from @abisher: pMode := %0000_0000_000_10100_01000000_00_00000_0
My question is this. The abisher version looks like it follows the protocol in docs. (D/# = %AAAA_BBBB_FFF_PPPPPPPPPPPPP_TT_MMMMM_0)
1. Why is the ozprodev version shorter.
2. If one can shorten the line of code how is that done.
3. If you only use the firdt couple parts, I think that is what is happening, is the remainder automatic.
4. Is the ozprodev a shortcut?
Oz's version is just less verbose for faster reading.
This is a good example of one of those small details that "everyone" already knows. Number systems. Binary base has same mechanics as decimal base. Just like 25.76 is the same number as 025.76, in the above examples of binary the leading zeros impart no numerical value. They are, in effect, not there. Writing them in the source code is a way to match up with the original documentation to show clarity.
PS: The underscore's also impart no numerical value. There for clarity again. It allows breaking up a long string of digits into smaller groups.
EDIT: Oops, now I read Tubular's very similar reply.
@msrobots,
Unfortunately I don’t think TAQOZ can be easily called from other program languages, otherwise I am fairly sure Peter would have demonstrated this. If my assumption is wrong, Peter can correct me.
You would not really CALL it like in other languages.
Ìt is more ĺikè having a service running in its own COG that you send text commands to via pipe ( serial. Or maiĺbox) and you get the printout back as text. And of course we can suppress the prompt.
@msrobots,
Unfortunately I don’t think TAQOZ can be easily called from other program languages, otherwise I am fairly sure Peter would have demonstrated this. If my assumption is wrong, Peter can correct me.
You would not really CALL it like in other languages.
Ìt is more ĺikè having a service running in its own COG that you send text commands to via pipe ( serial. Or maiĺbox) and you get the printout back as text. And of course we can suppress the prompt.
If you are just wanting to call TAQOZ to say, dump memory, or similar, then the MONITOR will do this for you. It supports strings, hex, etc and can even be called to input a string, with your own prompt too. And you can load an SD file and optionally run it too. The MONITOR and SD are a set of "callable" routines.
But if you want a powerful programming language, TAQOZ will do this.
Either can be called from the ROM when booting, after the boot ROM autobauds.
No. I have attempted to use the full statement to change some of the parameters in the ozpropdev code to see if I could get saw tooth or any other.
To no avail.
Pilot,
I've run Oz's example on the ES EVAL board. LED 56 and 59 alternate at a regular slow rate, maybe 0.5 sec per toggle. I assume you've got the same.
When you say sawtooth, do you mean you want to see a fade on those LEDs? Or do you have an oscilloscope to watch the pin voltages with?
EDIT: Ah, or did you just replace Oz's %00110 = NCO frequency mode setting with a %01001 = PWM sawtooth mode setting? Here's Oz's code modified to do the equivalent job but using the PWM sawtooth smartpin mode:
dat org
hubset #1 'rcslow
wrpin #%1_01001_0,#56 'pwm sawtooth mode
wxpin ##$2_2800,#56 'frame period (2) and base period ($2800)
wypin #1,#56 'pwm output (50% of frame)
dirh #56
wrpin ##%1111 << 28,#57 'input selector = inverted, pin - 1
rep #2,#0 'repeat forever
testp #57 wc 'get pin 56 state
drvc #59 'send inverted state to pin 59
I think I am getting it. Have been messing with the code today and am making some progress. I appreciate the help and I will post some code for critique.
Thanks
Comments
@potatohead
I am with on this. I am not the greatest at writing code but I would be happy to work on making projects work with the p2
TAQOZ has lots of modes to set the smartpins. One of the simplest is setting a pin to a frequency, after selecting a PIN you simply type or code the frequency that you want. For example I want pin 8 to output 1 MHz I type:
The source code to do this has been available for years (literally) in my P2 Dropbox folder. The basics look like this: WRFNC is a combination of WRPIN and combining I/O modes such as pullups etc but NCOCNT is what is required to convert the desired frequency into a counter value. I use 64-bit precision here but you can get away with 32-bit maths for some stuff.
BTW, if you don't try to translate the Forth code but simply read it left to right and visualize what's on top of the stack as it is being pushed and popped, then you will get the sense of it. For instance SETNCO accepts two parameters "val" and "mode". WRFNC is basically equivalent to WRPIN most of the time so "mode" is %1_00110 from NCO which WRFNC shifts into the correct position etc before it does a WRPIN. then 1 WXPIN simply writes a 1 to the selected WXPIN and WYPIN takes the parameter that is left on the stack which is the count value that was calculated from NCOCNT. That's it! The rough equivalent PASM for this WRNC is: (except pinmode is really a hub variable)
@pilot0315 is asking for a PASM example of using smartpins. A TAQOZ example does just make sense if you allow TAQOZ to be included and used by other languages, what you sadly are not really willing to provide.
What is needed to do so is - for you - quite simple, for people not literate in FORTH simply impossible.
Needed is a TAQOZ blob using the first 64K, adhering to the standard at providing current clocksettings in lower HUB, NOT using any pins at all until told so, NOT using serial pins, but the mailbox you showed me positioned at the last long of that 64K.
It is sad that TAQOZ is not relocatable, but one can get around that with a jmp at location 0 in HUB and restoring the first long of the binary after jumping over it.
If you would provide that blob, the includable TAQOZ, people using C, PASM, BASIC, SPIN or Python would be able to use TAQOZ while staying in the language of their choice, not bound to use the language of your choice for their main project.
This also need to include a change to lsio which sadly resets the smartpins for serial back to TAQOZ, even if one does not want TAQOZ to use serial.
I am begging you now for year(s?) to do so, I do know that you understand the concept, you just stubbornly want people to go full blown TAQOZ regardless if they want to or not.
And again and again I am telling you that this is a BIG mistake. Having a TAQOZ subsystem available to other languages (and the mailbox is proven to work nicely between COGS) would be a tremendous help and would allow a living and growing amount of TAQOZ scriptlets to be run from other languages, shared in the OBEX and Posts like yours.
Just for the cost of one COG, the first 64K of HUB and your willingness to provide it.
@Pilot could just include a TAQOZ object and write taqoz.send("8 PIN 1 MHZ") and would be up and running.
Yes I do understand that you will not need it, yes I do understand you want more people to use TAQOZ. But this IS actual the way to get people to use it, as long as they can keep themselves in the comfort zone of their own language and STILL use TAQOZ.
What I not understand is why you are so vehemently against it.
Mike
Since nobody seems to have replied I wasn't going to go into some other language but used TAQOZ as an example. I'd rather teach a man to fish then keep on feeding him every day, until I can't.
However, there is nothing stubborn about my attitude, I do what I can, and hopefully everyone else will do what they can. What a happy happy place it would be then. Sure, I could add this and do that, but considering the volume of work I have made freely available, even just on the P2, who has bothered to even try it? So I don't hang around hoping people will try it, I do it because it works for me and with just as much effort I dress it up and make it available and also try to answer questions.
What is the problem? Maybe if more people just tried it then they would see how easy it actually is and make the changes themselves, for what works for them..
I am one to fish. I appreciate the taqoz examples. I am trying to stay with the p2asm and p1asm TAQOZ is probably great but I have no refereces for it. I in the last year learned PropC and c++. Wanting to really get assembly language down pat. As I noted befor old days of :fortran, basic, cobol, "hated cobol", watfour and watfive.
At this time wanting to stay with one subject the smart pins so I can understand them. Then next to the next subject. I am trying to write tutorials for myself and then later share them.
My version of sodoku.
Thanks to all for your help. Just please bear with me for my questions.
I teach flying and aircraft mechanics. I tell my students that the only way to learn is to make mistakes under controlled conditions. That is how we learn.
Thank you for the support. Please read my previous post.
Ok, so I've given you the fishing line and a place to fish, all you need to do is cast and wait.
No wars please. I understand what both of you are trying to do: SHARE THE INFORMATION.
Thanks
I will try to convince you a last time and then shut up and leave you and TAQOZ alone, like a lot of us do. Maybe for the reasons I mentioned.
@ersmith did a lot of work to make multi-languages in one Project possible. You are not interested in that, fine. A lot of other people are interested in other languages besides FORTH but could USE snippets and get USED to TAQOZ/FORTH.
You are just avoiding the obvious answer by stating:
"What is the problem? Maybe if more people just tried it then they would see how easy it actually is and make the changes themselves, for what works for them.."
That is sadly a wrong statement. It is easy for YOU, not for the average Guy used to program C or Spin or other algol like languages.
I tried over several MONTH to get TAQOZ to cooperate with other Languages in the same Project. It does work but I am NOT able to get TAQOZ to leave the serial Pins alone. Your Mailbox works perfect but just on top of still using the serial connection. I think I have several threads and posts about it. But sadly I am to stupid to do so.
Sadly I am also to stupid to understand how I can convince TAQOZ to 'forget' its original serial connection and JUST use the mailbox. I am sadly also to stupid to understand where and why 'lsio' resets the serial pins back to console after execution.
And to ground you a bit, TAQOZ is easy for YOU, because you wrote it.
I would really like to include TAQOZ in my projects, harness the power it has from a language I know. Even giving it the low 64K and a COG to do so, like I give a COG and some HUB space to a serial driver, a VGA driver, a whatever driver needing a COG and some HUB ram. This is the beauty of a Propeller that you have multiple COGs able to run independently.
But if I need to get stuff done, I can not afford to write every thing NEW in a NEW language. I usually start with stuff I know, add needed objects out of the obex or my own repository. And I would like to integrate TAQOZ too.
In my opinion a reasonable way to work with already existing stuff and one of the key features of P1 and P2. The LEGO system, plug some objects together and write some glue code around it. Amazingly fast and easy to do.
Thanks @ersmith now even doable with objects written in C to include in a BASIC main, Basic objects in Spin, whatever you want is available to you.
It would be WONDERFUL if one could use TAQOZ in that mix. But you - again - stubbornly want people to write EVERYTHING in Forth. Sadly.
And state - basically - that we are to stupid to see the light and embrace Forth completely. Sadly.
I do completely agree with you that you put a lot of work in there and made it freely available, but you complain that " who has bothered to even try it? "
I did and failed miserable again and again. But having a scriptable TAQOZ object able to include into my PASM/C/BASIC/Spin program could change that usage of TAQOZ dramatically.
Not writing EVERYTHING in FORTH, just using it side by side with my main program.
If you do not want to support this, fine. It is just sad to waste that nice opportunity to integrate TAQOZ with all the other languages supported by the P2.
And if you do not provide this, nobody else will be able to do so. So AGAIN - TAQOZ kernel without using serial but mailbox would be the hen's teeth.
It is up to you to do or don't, I simply shut up.
Mike
For the target memsic 2125 chip, whats needed appears to be the "counting high states". Every P2 smarpin can do this, so whats needed is the smartpin config - which is then easy to translate into any language.
Unfortunately I don’t think TAQOZ can be easily called from other program languages, otherwise I am fairly sure Peter would have demonstrated this. If my assumption is wrong, Peter can correct me.
I gave Pilot a general overview a few days back - https://forums.parallax.com/discussion/comment/1473443/#Comment_1473443
I'd guess he's now after example code ... I think Pilot is struggling with assembly in general. There is lots of subtle details that is commonly learnt by all, we just "know" and don't describe it in any comments because it would be verbose knowledge that "everyone" knows already.
Forth is a good example case for us more experienced to see what Pilot is struggling with. Peter knows his TaqOz better than his own hands but it is so different to everything else for programming that most others just look blankly at the code samples he posts.
Well Peter wrote some 5 liner for me to convince TAQOZ to use a Mailbox, I can just not get rid of the serial connection. As far as I understood him this mailbox thing is already there to let TAQOZ run multiple instances on different COGs.
I just don't have the grasp to understand TAQOZ enough to shrink it down to leave the pins alone until told different.
Mike
Cluso's monitor I think is meant to have callable subroutines but I haven't noticed any stickied links to documentation.
http://forums.parallax.com/discussion/169815/smart-pin-mode-4-pulse-out-question#latest
http://forums.parallax.com/discussion/169935/smartpin-mode-10000-reading-360-servo-feedback#latest
P'rahs those who have covered other modes (or covered these better) could add pointers.
@Tubular
Tbanks for understanding. I am struggling with the smartpins. Looking for a couple of well documented examples to launch the spartpins. I found, see attached, by @ozpropdev. I asked a question in one of the threads about the following:
This is one of the lines of code: wrpin #%1_00110_0,#56 'nco frequency mode
This one is from @abisher: pMode := %0000_0000_000_10100_01000000_00_00000_0
My question is this. The abisher version looks like it follows the protocol in docs. (D/# = %AAAA_BBBB_FFF_PPPPPPPPPPPPP_TT_MMMMM_0)
1. Why is the ozprodev version shorter.
2. If one can shorten the line of code how is that done.
3. If you only use the firdt couple parts, I think that is what is happening, is the remainder automatic.
4. Is the ozprodev a shortcut?
What started this is that I am trying also to port over some p1asm to run different sensors that have p1asm drivers.
I am also writing myself a tutorial in P2asm. Was doing o.k. in P1 pasm and still learing but now have to change gears. If I am succesful I will share this tutorial for critique.
Also about TAQOZ, I do not need to learn a new language until I master the one I am learning now. So I thank you guys again.
Thanks.
Martin
Yes, the SmartPin DOCs are terse at best, and certainly need working examples for every mode. This has been suggested/requested before, but Chip is really the only one well enough placed to do this.
leading zeros are somewhat optional, as the numbers resolve to upper bits zero anyway, so including them is just a matter for clarity.
in PASM the binary code itself is identical, unless you strike a case where the shorter form fits into an immediate opcode ( iirc 9 bits of constant can be encoded smaller ) - above that, 32 bits are needed
If a design uses a lot of smart pins, that can become a lot of init constants to store somewhere.
Chip's posts here got me nervous until I realized they were from 2017...
BTW there has been no source of the final ROM posted. AFAIK chips booter was not changed, my Monitor code is unchanges and the same address, some tweeks to the SD boot code. Not sure if TAQOZ was updated ???
Perhaps the binary 0/1 base makes things more confusing. Shortening binary numbers follows the same rules as decimal base, eg adding 00900 to 00030 gives 00930, as does 900+30=930=00930
Basically, the leading zeroes are redundant, but trailing zeroes are necessary
The other thing is that Chip has coded the P2 design in a way that zero means 'default config' for many things. For instance the pin redirect bits AAAA and BBBB - setting these to 0000 means they just do the default thing of not redirecting to a neighboring pin. Because these upper bits are zero, we can use the 'shortened' number where the leading zeroes are not expressed (causing them to be interpreted as zeroes)
This is a good example of one of those small details that "everyone" already knows. Number systems. Binary base has same mechanics as decimal base. Just like 25.76 is the same number as 025.76, in the above examples of binary the leading zeros impart no numerical value. They are, in effect, not there. Writing them in the source code is a way to match up with the original documentation to show clarity.
PS: The underscore's also impart no numerical value. There for clarity again. It allows breaking up a long string of digits into smaller groups.
EDIT: Oops, now I read Tubular's very similar reply.
You would not really CALL it like in other languages.
Ìt is more ĺikè having a service running in its own COG that you send text commands to via pipe ( serial. Or maiĺbox) and you get the printout back as text. And of course we can suppress the prompt.
Nope. There wasn't any space
If you are just wanting to call TAQOZ to say, dump memory, or similar, then the MONITOR will do this for you. It supports strings, hex, etc and can even be called to input a string, with your own prompt too. And you can load an SD file and optionally run it too. The MONITOR and SD are a set of "callable" routines.
But if you want a powerful programming language, TAQOZ will do this.
Either can be called from the ROM when booting, after the boot ROM autobauds.
No. I have attempted to use the full statement to change some of the parameters in the ozpropdev code to see if I could get saw tooth or any other.
To no avail.
Thanks
I've run Oz's example on the ES EVAL board. LED 56 and 59 alternate at a regular slow rate, maybe 0.5 sec per toggle. I assume you've got the same.
When you say sawtooth, do you mean you want to see a fade on those LEDs? Or do you have an oscilloscope to watch the pin voltages with?
EDIT: Ah, or did you just replace Oz's %00110 = NCO frequency mode setting with a %01001 = PWM sawtooth mode setting? Here's Oz's code modified to do the equivalent job but using the PWM sawtooth smartpin mode:
I think I am getting it. Have been messing with the code today and am making some progress. I appreciate the help and I will post some code for critique.
Thanks