P1 spin on the P2

KC8DKT

I have flexgui and PNut but flex finds a truck load of errors in just about all of the OBX drivers in the PAsm code that I just do not fully understand. I got some of it fixed where it would still run on the P1 after I did the edits to try and fix the errors Flex found but still working on it.

Can or WILL the P2 be able to run P1 Spin/PAsm from the P1 with out a code rewrite ? I know clock speeds, timings, and Pins may need tweaked but aside from that will the P2 run P1 code AS IS ?

If it works on the P1 will it work on the P2 or will their be a way to convert it? The flexgui says it does this but its finding a lot of errors when the code is running fine. My part of the code is checking out ok aside from 1 line but the OBX drivers seem to have a truck load of problems converting.

Would love to pick up a P2 for the added speed and fun but flexgui does not look like it can get the code converted to run on the P2 and its my under standing the P2 does NOT run the old P1 code.

Yes I have searched for this info. All the posts talk about it "WILL" at some point or "Flexgui" can do it now by converting it and that's not working for me it seems. God I suck at Asim… I spent the better part of a day fixing just 1 ADC driver from the OBX because its about 80% Asim before Flexgui would convert it.

ersmith

P1 assembly code has to be manually translated to P2 assembly code, unfortunately. Flexgui can (and does) support compiling the Spin part, namely the PUB, PRI, CON, and OBJ statements, but the actual assembly code part in the DAT section must be translated by hand; the P1 and P2 assembly languages are just too different.

KC8DKT

Thanks for the info...

KC8DKT

Will the P2 code have a walk through like the P1 Spin did that you know of? The P1 Asim never had books or pdfs like the P1 Spin did making it much harder for a noob to pick up. The P1 Spin had books and PDFs every where you looked. I jumped over to the P1 from the BStampPE because of all the info I found to help get me started. Sucks P1 Asim never seemed to have as much info to help noobs.

Cluso99

P1 ASM conversion is tedious to say the least, If you don't know what you are doing then it ain't gonna translate well. Anything using the counters, freq, video needs to be rewritten as the hardware is completely different. Some pin assignments we're using have moved to the upper 32 pins meaning a code change. But by far, the biggest problem is that there is no direct equivalent of the jmpret/call/ret instruction - this requires manual changing for each and every case it's used, and in most cases it means two instructions to replace one, so you better have code space or you'll have to use lut (or hubexec). Unfortunately I asked too late to get an equivalent in P2 - this is really the game-changer instruction. Also there is no 'NR' bit in the instruction space, so anywhere this is used will require a look and workaround - not too difficult but again a pita tho' the advantages outweighed the disadvantages. Also, you cannot necessarily do a MOVI (now called SETI), and any movi/movd/movs (now seti/setd/sets) (self-modifying code) needs an extra instruction between modification and execution due to pipelining. And you cannot easily disable an instruction by changing the condition bits = 0000 like on P1 because this is now utilised to do an implied return after the P2 instruction executes. This also means longs within your code (used for smaller variables) that had the condition bits = 0000 so they didn;t execute, will now execute giving unexpected results.
So, there isn't and probably never will be a translator program

P1 SPIN conversion is less tedious. Of course there are gotcha's and some things will just not work. Basically anything to do with counters, the freq registers, and of course the video are completely different in P2. You need to change all calls without parameters to xxx() and you need to define the result for the return of a long in P1. So the PUB/PRI becomes name(parameters) : result and optional | localvars
PUB someroutine(optional_someparameters) : result | optional_localvars
Most of this conversion is straightforward but it does take time.
Then there are a number of minor differences that result in compile errors - it's a try, tweek, repeat cycle.
So it's a

Having said all this, there are many good points about the P2
But it's a steep learning curve if you want to use many of its' new features. I think we need to look at the P2 in two different ways...

The P2 simple PASM model (similar to the P1)
* Basic main instructions (ignore the complex ones) ie the P1 equivalents plus a few extras
* Basic hardware (ignore the smartpins) ie DIRx/INx/OUTx and the few direct pin extensions
* Utilise the P2 OBEX style objects as black boxes

Master these before advancing to the next step...

The P2 extended PASM model (the new P2 features)
* The new PASM complex instructions
* The LUT and HUB including lutexec and hubexec
* The Smartpins and their capabilities
* The pin DACs and ADCs
* The Streamer and its' uses

KC8DKT

Try, tweek, repeat cycle was all I did today just to get 1 file fixed to still work and convert with out errors.

The P2 looks like it will be fun if I can find enough info to help get started like the P1 Spin had. I was kind of shocked that it still only had 8 cogs though. Was hoping for more, the rest looks great. Love the 13bit ADC smart pins and speed bump. Just hope the P2 Spin2 has enough info for dumb people like me to use it like the P1. LOVE the PropMinis.

Ariba

It would help if you say what ADC object you tried to convert.

I think it makes not much sense to convert an ADC object from P1 by just using the new Spin and PASM instructions.

If your P1 object drives an external ADC chip, the PASM will be there to make a fast communication like I2C or SPI. With P2 this is not necessary, either Spin is fast enough, or you can use a smartpin to make it faster than P1 ever could do.

Or your object makes a SigmaDelta ADC on P1 with external resistors and the counters. This will never work on P2, because the counters do not exist anymore. But the P2 has very good ADCs implemented on every Pin. They are better, faster, and simpler to use.

Both options will NOT use an additional cog on the P2. The P1 had to start another cog just for PASM code.
So you can do much much more with the 8 cogs of the P2, compared to the P1.

Maybe it's a good thing, that the P1 objects not work unchanged on the P2, otherwise we would have a lot of very inefficient objects for P2.

Andy

Roy Eltham

A large amount of the P1 Counter functionality now exists on each P2 smart pin. You should be able to do most things with a P2 smartpin that you could do with the P1 counter stuff.

Also on the P2, you can configure and run/service many/all smart pins from one cog, where as on the P1, you had 2 counters per cog, and if you needed another one you had to use another cog, up to a maximum of 16 counters configured and using all 8 cogs

I do agree with Ariba that it's probably a good thing that P1 PASM driver stuff doesn't just work on P2, because the P2 way is better but different enough to require rewriting.

KC8DKT

This started out as an easy and quick fix to an off the shelf DB Meter for my audio stack. It has kind of turned into a much larger project now. The P2 looks like it can do a lot more I just have no clue if I can redo the code to work on a P2. Guess I will just have to grab one and find out. The spin for the P1 has a truck load of info and starter books, I hope the same is true for the P2s Spin2 code. The project now has 4 audio inputs (Front left Center Front right and Sub) with a 11x44 RGB screen and 8 RGB external led strip hookups on the back. I was about to finish up the Rack box its being mounted in for the stack but now I am thinking of holding off till I check out the P2 demo board and see how diff the spin2 is. I started with a Pie but it started getting bogged down. The PropMini is doing a great job but I am out of cogs and just about out of code space but was thinking of off loading the DAT info to the upper eprom if I have too. I have the user settings and menu system already in the upper rom so it should not be too hard.

On the other hand the P2 is easier too use SDCards with from what little info I have seen online in the forums. The speed boost would be fun as well I think. I did not get billed for the P2 Demo board yet so hoping they still have some in stock and downloading all the files off the new obx for the P2 will be enough to get me started. With SPIN, I know very little about asim, I can do some mods to files but no chance if I have to start from scratch.

evanh

You can still do an ADC with external R-C by setting up the low level pin pair to do the two pin drive and modulation, and then also an associated smartpin to absorb the resulting bitstream similar to what the prop1 counters did. There is a lot more specialised options for bitstream handling now.

The physics is the same but the configuration and access methods is completely new.

PS: It can even be done with a single pin by using one of the internal resistor drive options.

evanh

Learning machine code (assembly) is best done architecturally, imho. Learn how CPUs fetch and decode instructions, utilise registers and main memory, what the steps in execution are, how the synchronous clocking system interacts with flip flops and how gates are inherently asynchronous.

After that, all CPUs are readable.

KC8DKT

LOL, thanks evanh but I am way to dumb for asim type langs, I had a hard enough time with PSpin. I do a lot of change this and see what happens till I get it working and hope I do not see smoke. It was hard enough for me to get the ADC to return the Freq, Power, and tempo info.

Hoping the P2 Spin2 is close or at least as easy to understand as it is on the P1 and has as much info in the PDF under the help menu.

evanh

Asm, there's no "i" in the short form. Actually there's no "i" in the long form either.