PropBasic and LMM

tritonium

Hi
I'm having great fun with PropBasic and now feel the need to use LMM to make more room available, or rather, run larger programs. I was under the impression you could mix LMM code and normal code on the same cog but I am now coming to realise that this is not so- its either one OR the other but not both. In fact thinking more about it I dont see how one could do such a thing as the LMM code is executed by a small assembler (m/c) routine in the cog pulling in code from the hub (long at a time?) and (somehow) executing from there, and consequently at much slower speed. This of course leaves a lot of program space in that cog not being used (except perhaps for vars? specified in the code), and it seemed a waste- but I dont see how a cog could be switched from one mode to the other without inventing new opcodes.
I tried adding LMM to the start lable but although it compiled and uploaded ok it did not run, and I expect that the time critical sections (spi talking to SD card) were to blaim.

Having said all that- my question is- is this correct, or have I got it all wrong?

I need to put the time critical stuff in one cog (task) and use LMM for the bulky but non time critical stuff in another cog. I can if I like, write ALL the code in ONE program, but with the use of tasks- one for LMM and the other for speed, using flags and shared memory in hub.

Hope all that makes sense?

Dave

pmrobert

You can run either LMM or native code on any cog - but not both in one cog. Can you dedicate a native code cog for your SPI purposes? I've done that and it works very nicely. Bean has very kindly made available some libraries for SPI/SD and several other peripherals you may want to look into.

-Mike

jones

I've done exactly what you are contemplating, using one LMM cog for bulky stuff like user interface and separate cogs, loaded as tasks and running cog code, for time critical stuff. That works well using hub vars and flags as you stated. You're assumption is correct, the cog either runs your code or the LMM kernel, but not both.

I have been able to run I2C in LMM in one case, but in others I've had to move the I2C comm into a separate cog running cog code. Never was able to understand why, and because I had the cog available, I didn't spend much time on it. Presumably it was a speed or latency issue, but I couldn't confirm that. I've never tried SPI in a LMM cog so I can't add anything.

You can put all of your code in one program as you suggest, or keep the source for each cog in a separate file and use LOAD "filename.pbas" in the main program for each cog other than main. I think some of Bean's examples show that method. Your program will load one cog automatically, so the "main" cog won't need a task definition, but the other cogs will. It can be the main cog that runs LMM or one of the others. You can also run more than one cog in LMM if you have enough hub ram.

Bob

tritonium

Hi
@pmrobert and @jones.
Thanks vm for your quick replies- sorry for my slow response I've been organsing my head and wrestling with SD code.
Well its good to know I havent gone mad and all is as I thought! I have the examples of others to imitate when it comes to using "LOAD" for each cog other than main- I just havent tried it yet.
Beans Basic is fantastic but it is just different enough that I have to look up syntax and 'ways' of doing things. What I do now when starting a new program, is to copy and rename an old program with all the syntax examples in, and then comment out all the code (keep the boiler plate stuff) and use it as a reference for the syntax in my new code- works well. When I have sufficient new code I can delete the commented out stuff and tidy up.
We do owe a vote of thanks to Bean for his efforts in giving us this easy way of programming the prop- without it I might well have just lost interest.
Dave

Cluso99

It is possible to mix cog PASM code with LMM code but you will have to do this yourself.
In fact I have run LMM code and SPIN together too. This is how my zero footprint Spin and PASM Debugger works.