Propeller RAM

Beavis3215

When running a SPIN program in cog 0, using a variable, is the RAM for the variable in cog 0 ram or hub RAM?

potatohead

With SPIN, the variable is in HUB RAM.

The SPIN intrepeter is running in COG 0, and it is running your program from HUB RAM.

tomcrawford

SPIN variables are in hub RAM.

Beavis3215

If I am running very time sensitive program, is there a way to sync the running of part of the program to where the hub is pointing to cog 0? In other words is there a way to start a routine only when the hub is pointing at cog 0? Can I use cogID? Wait until cogID = = 0 cleverly placed?

potatohead

In general, using PASM is how this is done. SPIN runs slow enough that alignment with HUB access times does not make sense.

Time sensitive could mean, "needs to go faster", or it can mean, "needs to happen now", or both!

What are you intending time sensitive to mean?

Beavis3215

I have waitcnt delays in the millisecond to microsecond realm and I think that in waitcnt(Delay + cnt) that delay isn't always available when needed and therefore is sometimes 0, where it needs to be at least 381 to operate properly. See my homebrew EFI project for more details on what Im doing. This is a fixed timing ignition timing scenario to time a cam revolution, with 30 degrees before TDC cam timing being sensed, and calculate the delay necessary for the cam to roll an addition 30 degrees and fire a coil at TDC. I have not tested the output to be accurate yet, but it seems that the program has problems starting, but not running, at certain speeds.

potatohead

That seems like something better suited for PASM. I'll let others chime in with whatever SPIN tips they may have.

It may be the timing period is simply too short for SPIN to perform consistently on.

Beavis3215

Im studying PASM but testing the abilities of SPIN until im ready (beginner at SPIN, super beginner at PASM). I think you may be right. From what I can see, at certain cam speeds, fast of slow, sometimes the waitcnts hang up for the traditional 53 seconds. At certain speeds it syncs right up. Once I get it going it seems to operate at any moderate to slow speed. It seems like the cogid statements do make it much more stable, but not perfect. There is definitely an upper limit to rpm where it never runs, and a lower limit to where it never runs.

potatohead

Doing PASM for this is likely not hard. You might be well off to start thinking on it now. Once you have what you want to do clear, you can write a small PASM routine, drop it in a COG and talk to it via SPIN.

What you do is have the PASM look at HUB variables on a regular basis. The SPIN program writes and reads from those and handles non speed critical stuff, to keep it all easy.

One of those limits does not seem to make sense. On the slower end of things, SPIN should be fine.

Beavis3215

I tried substituting a pulse generator instead of the cam sensor, just to make sure the problem isn't hardware related, and there is definitely a problem with slow pulses. The hub freezes from a really long delay(waitcnt parameter too small). Its hard to put a finger on what is happening, but once it starts in runs slow, but it wont start slow. Somehow something isn't syncing up right.

Beavis3215

Question about PASM is it faster than spin because:
Spin converts to Assembly which converts to machine language(More time) and
Assembly converts to machine language(less time)

Is this fairly accurate, or not?

Dave Hein

Spin uses an interpreter that runs in the cog. The interpreter reads Spin bytecodes, and executes the functions defined by the bytecodes. This is much slower than PASM -- probably about 50 times slower. You can convert Spin to C using a utility called spin2cpp. C code is then compiled to PASM. However, this is still slower than PASM. If you compile the C code to cog PASM it runs about half the speed of PASM code. If the C is compile to LMM PASM that executes from hub RAM it will run about one-eighth the speed of PASM.

potatohead

That's close!

SPIN is compiled into byte code, which is a small representation of your program, intended to make the most of the RAM. SPIN is interpreted, meaning SPIN runs as a PASM program, which then runs your program as compiled byte code.

Yes, assembly language ends up being machine language, native to the COGS in the Propeller.

Beavis3215

I have experience in ancient C. How does one get started in C with propeller?

Dave Hein

In theory, Parallax provides a C development tool call SimpleIDE. However, I can't find it from the parallax.com website. Just google "parallax simpleide" and you can find it that way.

Bob Lawrence (VE1RLL)

In theory, Parallax provides a C development tool call SimpleIDE. However, I can't find it from the parallax.com website. Just google "parallax simpleide" and you can find it that way.

From the main web page select Learn and go down to Propeller C. Simple IDE is on the right.

http://learn.parallax.com/

http://learn.parallax.com/propellerc

http://learn.parallax.com/node/640

Dave Hein

Bob, thanks for posting the links. I would have expected SimpleIDE to be on the Support/Downloads page also, but there is no mention of it there.

Cluso99

Beavis,
IMHO you should be using PASM to do your timing control. Spin will not get you the timing results you require.
To send simple pulses out at specific times is simple and deterministic with PASM. ie the timing can be precisely repeated.
PASM can be simple if you are only sending out timing pulses. You can still use spin to perform calculations etc that are not timing specific. There will be plenty of help here on the forums to get you going with pasm.
If you look at the PASM instruction summary you will find almost all instructions are similar - they have a source and destination which provide two inputs to the instruction, and the result is written to the destination, replacing its original value.

Mike Green

When you try to wait for too short a time (less than the overhead in Spin or even in PASM), the hardware waits for a CNT value that has already passed. CNT wraps around and 2^32 is roughly 53 seconds with the default 80 MHz clock. The CNT value that was missed comes around roughly 53 seconds later.

Mickster

Have you considered Propbasic?

Easier than Spin and TRANSLATES directly to PASM

Propbasic doesn't get the attention it deserves here because, apparently, while JMP is cool, GOTO isn't LOL.

Beavis3215

I also have lots of antique basic experience, how does one get started in probasic for propeller?
Any Idea in the code above why the waitcnt phenomena would occur in different speed groups? It reminds me of using a radio tuner looking for a carrier wave. I can see the wave, and harmonics of the wave,but nothing in the middle. CNT seems to have passed even in very slow speeds. I think it may be a limitation of spin, where the frequency of the raw data vs. the frequency of processing the data causes harmonic windows where waitcnt gets what it needs.

Mickster

I'm not sure if the download link for PropBasic is in this thread but you can find it elsewhere on the forum (a bit pushed for time right now)

http://forums.parallax.com/discussion/149659/propbasic-how-to-use-propbasic-in-simpleide

Mickster

I have found Viewport to be very useful with PropBasic, also.

http://forums.parallax.com/discussion/135678/download-latest-version-of-propbasic-for-viewport-here/p3

Heater.

Quite so. JMP is cool, in assembler. GOTO is basically a JMP, not cool in a high level language.

Language wars aside I think PASM on the Propeller is the easiest assembly language ever and as it is nicely integrated into the Spin language system it is very easy to use in general.

This has the great advantage that Spin/PASM is what the Prop was designed for and what has the most support in terms of people who know it and available objects to use when you need them.

Mike Green

Looking at your code, you do a lot of calculations particularly involving multiplication and division to get Delay and the spark duration. These are slow since they're done in software ... there's no multiplication or division instruction. In PASM, they're on the order of several tens of microseconds. Spin interpreter overhead adds to that.

To get minimal wait times using WAITCNT, you have to really minimize these calculations, probably use some kind of table for approximations. Even in PASM, it's better to use table lookup in this sort of circumstance. For multiplication by a constant, there are optimizations using shifts and adds.

pmrobert

Re PropBasic: It's very similar to Parallax's PBASIC but with a few things changed up and added to support the Prop's multiple cogs, etc. It is very fast but does require treating it almost as a macro assembler of sorts. It doesn't have an IDE so you'll have to use an editor and a couple of batch files to automate your build/compile/load. Geany or Notepad++ work nicely. As an ECU-centric PB example I've attached a task fragment that emulates a 36-1 crank wheel.

' ----------------------------------------------------------------------
' TASK Code - WHEELSIGNAL
' ----------------------------------------------------------------------
TASK wheelsignal
	SWO		PIN 3 low 				' Simulated Wheel Output
	rpm		var long				'	
	teeth 	CON 36					' 
	tmpvar 	var long				' scratchpad var used for various transient purposes
	itg 	var long				' Inter Tooth Gap in usec
	pulsdur	var long = 100			' Output pulse duration, usec

	do
		' Methodology: usec/rev = (1000/(rpm/60))*1000
		rdlong curr_rpm,rpm		'Get current rpm from hub var
		'rpm = 6000					'or uncomment this for testing
		tmpvar = rpm/60 			' revs per second
		tmpvar = 1000/tmpvar 		' msec per rev
		tmpvar = tmpvar * 1000 		' usec per rev
		itg = tmpvar / teeth		' Calculate Inter Tooth Gap
		pauseus itg					' Here's the -1 missing tooth
		itg = itg - pulsdur			' Account for pulsedur when actually pulsing
		for tmpvar = 1 to 35		' Do 35 teeth
			pauseus itg
			high SWO
			pauseus pulsdur
			low SWO
		next
	loop							' Rinse, repeat
ENDTASK

Mickster

Heater. wrote: »

Language wars aside I think PASM on the Propeller is the easiest assembly language ever and as it is nicely integrated into the Spin language system it is very easy to use in general.

This has the great advantage that Spin/PASM is what the Prop was designed for and what has the most support in terms of people who know it and available objects to use when you need them.

I totally agree but it might be that the OP wants to simply "git-r-done" without having to jump through all kinds of learning hoops so I suggest what I find to be the easiest coding/fastest execution for the Prop.

Heater.

All depends which learning hoop you want to jump through I guess

Mickster

I prefer none!

Beavis3215

I'm not necessarily trying to git- r- done, just trying to get the methodology of how to git-r-done. As far as language wars, I have always been a goto kind of guy. I am intrigued by the idea of having look up values for delay, based on cam period T. I think I am going to focus on pasm for a while and see where I can go. My plan has always been for this EFI system to run on a lookup table map anyway, but for some reason I never considered doing ignition timing that way. Really good advice here, I appreciate it.

Beavis3215

Using the SPIN design, would it be better to work one revolution in advance. Instead of a short delay for the cam to roll 30 degrees, what about a much longer delay for the cam to roll 390 degrees? I know that this means that an entire cam revolution goes unrecognized, but may be acceptable as an approximation. I'm not stuck on the spin design, I'm trying to be innovative, while trying to learn pasm. Part of learning is failing miserably. Done a lot of learning lately. On second thought, waiting 390 would never work for the engine anyway. The system would fire the coil on every other cam revolution.