Is There a 9-Bit Literal Workaround?
lardom
Posts: 1,659
in Propeller 1
I had a major success with my brushless motor driver two days ago and I was excited. I ramped the motor in Spin and then called the Pasm object once it was fast enough to run closed loop.
Today I decided to check for any speed difference between the Spin loop vs the Pasm loop. The Spin loop was clearly faster. Pasm switches quickly and I want to delay commutation for 30°.
I thought I could have a Spin cog calculate the delay and pass it to the Pasm cog but finding a way to get around the 9-bit literal limit is tougher than I thought.
Comments
Why use literals? Just put the full 32 bit value you want to use in a register and use that register instead.
Yes, instead of
add reg,#value
you wouldadd reg,avalue
where you define avalue as a long in your cog codeavalue long 1000
etcThat's it. Thanks Peter.
For an E-bike, an electric paramotor or even a car alternator where motor speed changes I would want to update rotor position.
??? What I suggested is exactly the same as what Peter suggested. Don't use a literal, use a COG memory location instead. You can still update values with it!
I wanted to know how to get an update instruction from the Spin cog to the Pasm cog witout violating the 9-bit limit. I'm thinking how could I pass a value as the motor changes speed. The answer is to pass a pointer to a register 'within' the cog.
I have very little understanding of how assembly works so understanding that small detail was key.
You want your Spin code to update a register in a cog while the cog is running?
You will need a hub variable so that it can be updated and then your cog code should do a rdlong cogreg,hubptr iirc where hubptr is another long in cog memory with the address of the hub variable.
I will dig up some code for you but Eric had answered correctly first up, but I guess you needed a bit more how-to info.
Yes. I want the Spin cog to monitor transitions on an i/o, say, every 200ms and then pass that data to the Asm cog. so that the Asm cog can adjust the amount of delay. At the moment commutation is occurring 30° too early.
At the moment I'm doing simple tests with an led. I'm learning a few things about "rdlong". I'm also doing a test to see if I can use data from a Spin DAT block.
@Peter Jakacki you are absolutely right about ersmith.
@ersmith Over the years I've said some stupid things to professionals like you in this forum fully aware that their knowledge and ability was way beyond my own and I've regretted it.
Please accept my apology. I acknowledge that what you said was correct.
Awesome! You're well on your way then. Ain't pasm fun
@lardom: Really, don't worry about it -- I was more puzzled than anything, and I'm sorry if my reply seemed a bit testy. Peter's answer was much better than mine anyway, since he gave an explicit example of how to use the register. Sometimes it's easy for us to forget that not everything obvious to us is obvious to others!
Take care,
Eric
I am learning to come to terms with the way my brain works. I've seen your username in discussions related to the development of the P2. Engineers are talking to engineers. I have a terrible time trying to decipher the assembly section of the Propeller manual. Somebody has to translate it for me. In a sense it's like a learning disability. If you say something to me the idea rolls around in my head and at some 'later' point the light will go on.
Now that I'm beginning to understand things a little better it's starting to 'click'. In a different thread somebody told me something and when i awoke the next morning it 'clicked'. The motor has to 'ramp' to a new speed.
I learned new information in this thread and the same as before, when I awoke the next morning it 'clicked'. Since the motor has to 'ramp' to a new speed all I really need to do is to send the Pasm cog a zero, one or a two which means "no change", "increment" or "decrement". It amounts to two instructions, 'add' or sub one 'long' from another 'long.
I love this stuff. One of my challenges is not to burn my bridges in the process. Thanks again.🙂
I thought initialized longs were set in stone at compile time. From what I learned in this thread I did a test that incrementally blinks an led faster. It then occurred to me that the Pasm cog could monitor the input states of two pins controlled by the Spin cog which means I don't even have to access the hub. A cmp instruction is what I needed! Thank you.