Simple Questions re calling objects

TimH

I'm a new user to the propeller but have a pro dev board and have managed to write a few Spin programs to test the Full Duplex Serial and also the Quadrature encoder objects.· Both worked with no major problems but now my questions concern the best way to combine these objects + code into a final product.

This is what I am working towards:

Using the FullDuplexSerial, object to continually read the serial pin, parse the received·string and then store a 32 bit variable extracted from the string that can be read by code running in another cog.· This means that the variable read by the FullSerialObject will be continually updated with the latest value. Code running on another cog would then read this variable being assured that it contains the latest data read.

Is this best done by modifying the FullSerialObject, adding the parsing code and making it loop or should I just start another cog which continally calls the FullSerialObject which is left unmodified.

2nd question is timing accuracy - using a 5MHz Xtal with the X16 ppl what accuracy can I expect using spin code. A simple calculation gives 1/80MHz = 12nS
If I created a delay of say 10mS could I expect a resolution of 12nS using a simple spin delay.

Tim S

Mike Green

You have cogs to spare, so I'd suggest you leave FullDuplexSerial unchanged and put all your parsing code in your main module. Also leave the quadrature encoder object unchanged if possible. The primary advantage in doing it this way is that you have two objects that work as-is. You don't have to delve into the internal workings of them and everything that's yours is in one source file.

Timing resolution is to the nearest clock cycle (12.5ns at 80MHz). If you use one of the cog counters to time an external signal, the timing accuracy is within two clock cycles (with up to one clock cycle to react to the leading edge of the signal and up to one clock cycle to react to the trailing edge). If you're timing something in software, there's a short delay as the Spin interpreter executes the statements to read the system clock (CNT), then another delay as the Spin program tests for the termination condition and again reads the system clock. The difference between the two CNT values is the elapsed time to the nearest 12.5ns.

Timmoore

I and a lot of people have the main cog - the one that initialized the serial port, etc. loop once its done with init, doing this type of processing. You often end up with the main cog starting cogs to do fast processing such as the serial port, encoder, etc and then sit in a loop and manage the other cogs - moving data between them is a common function of the main cog.
Spin is not particular fast 1 line can take 100s clocks. If you want tight timing either use counters or use a asm cog. I mostly use spin for non-time critical stuff and management functionally e.g. moving data between high speed cogs. A good example is if you do a waitcnt there is an overhead of ~384 clocks with spin