Making better use of COGs
AGCB
Posts: 327
in Propeller 1
As I see it this program is already using all 8 COGs and I still have things to add. Can I use the CTRx s of a cog to do simple timing tasks simultaneously? Is there a way to get more done with less COGs?
Thanks
Aaron
PUB init tv.start(0) 'TV_Text ow.start(10) 'One-wire routines I2C.init(SCL,SDA) 'for RTC and HUM21D humidity cognew (RTCcog,@RTCstack) 'looks like there may be 2 instances of I2C object cognew(windSpeed,@stack) 'counts pulses from annemometer cognew(counter,@countstack) 'for controlling program events cognew(fanTimer,@timeStack) 'tracks furnace fan run time
Thanks
Aaron
Comments
Cheers,
Jesse
Usually yes.
I'd be very surprised if there isn't a way you can combine cogs.
Do you know the minimun period for the annemometer pulses? Can you combine the annemometer cog with the timekeeping cog?
If you post an archive of your program, I bet you'd get suggestions on how to combine cogs.
Are you using an external RTC chip? If yes, no need to use a cog since you have at least one second between any changes in the RTC.
As Ada pointed out, you may be able to use a counter to handle the events of your anemometer. I have a time object that measures the delta in system clock ticks that I use for scheduling events. I've attached it and my Spin I2C code. I've deployed both these objects in commercial products.
Let's say you wanted to collect the anemometer counts and the time every second. With my time object you might do something like this
pub main setup repeat if (time.millis => 0) time.adjust(-1000) process_data pub process_data rtc.rd_time(@secs) windCounts := phsa phsa := 0Over the years I have found that even though Spin is supposed to be slow, you can get a lot of work done in what humans consider a very small amount of time.
-Phil
Do all objects in the Propeller Library use a COG? If not, how do I know which do or do not?
Q.2
I know how to set up the CTRx 's but I've always done it in a separate COG. I tried to do it in the INIT method but it causes the program to hang. How am I wrong?
@Phil Pilgrim (PhiPi)
I'm using magnets and a 3144 Hall switch. I assumed this put out a clean signal but see the datasheet says 2 us rise and fall times
@Peter Jakacki
....So you could get the background cog to maintain the countdown timer values, and automatically execute code if set, maintain a runtime millisecond counter, and also use this together with the RTC value which only needs to be read once at reset or each day. That way apps can access the time of day and date without having to I2C it each and every time. Is that what you want to do...
The timer I think I can figure out but I'm not quite understanding the RTC part.
@JonnyMac
So I can take the parts (methods) I need from an I2C object like yours and put them in the top object to use as needed?
Thanks
Aaron
The Spin code for a background timer cog is very simple really. I will see if I can post something.
Did you notice this?
I'm pretty sure windSpeed, counter, and fanTimer could be combined to a single cog. You could probably add the RTCcog to the same cog.
The program should easily be able to handle more tasks.
btw, reading the rtc every second will not always appear smooth because sometimes you read it on the cusp and your display may seem to stall or jump. Better to increment the time of day in software and just read the RTC every day or every hour, but not once a second.
The windspeed hardware counter may need hardware debouncing if you are using reed switches. Alternatively let your timer cog run much faster and simply prescale the slower events but check the pulse inputs in software which will be slow enough that it will in effect debounce it. However a simple capacitor across the reed switch should help if you are using a pullup/down.
@Peter Jakacki
I'd still like to see basically how you do the timer with RTC setup. I think I understand the basics but a snippet would help!
Thanks to all for your time.
Aaron
I created an array of pulsecounts with the last and latest reading being named pulsecount itself so it was easy to do a longmove rather than one by one. Remove all your cognew calls that are mentioned in TimerCog routine. There is lots more you can do to your code to make it cleaner and meaner and way easier to maintain. ReadTemperature could be called every second as well from the TimerCog. The granularity might have to be reduced from 1ms to 10ms to allow enough time to do all that processing, so adjust the code accordingly.
VAR long pulsecounts[7],pulsecount PUB TimerCog | millisec ' replace all these cognews with cognew(TimerCog,@stack) ' cognew (RTCcog,@RTCstack) ' cognew(windSpeed,@stack) ' cognew(counter,@countstack) ' cognew(fanTimer,@timeStack) 'Set up the counters ctra := %01110 << 26 + pin1 'counter A in NEG edge detect mode frqa := 1 'increment 1 per pulse phsa~ I2C.init(SCL,SDA) ' Timer cog has control of I2C ReadRTC repeat waitcnt(clkfreq/1000) millisec++ ifnot millisec//1000 ' once every second OneSecond pub OneSecond ms++ if ms == 512 ms~ FT++ ' fan timer WindSpeed timbuf[seconds]++ ' maintain seconds rather than reading the I2C RTC every time if timbuf[seconds] == 60 ' read rtc every time the seconds overflow ReadRTC pub WindSpeed | i longmove(pulsecounts,pulsecounts+4,7) ' shift counts for new entry at end of array pulsecount := phsa phsa~ speed~ repeat i from 0 to 7 speed += pulsecounts[i] speed /= 8 pub ReadRTC I2C.readbytes(RTC,0,@timbuf,7) IF INA[17] ==1 'DST/CST switch for daylight savings time timbuf[hours] := timbuf[hours] - 1 'this will be summer (spring ahead) IF timbuf[hours] == $0A 'correct for these ↓ 3 odd displays (0A, 24, 1A) timbuf[hours] := $10 ELSEIF timbuf[hours] == $24 timbuf[hours] := $00 IF timbuf[day] == SAT timbuf[day] := SUN ELSE timbuf[day] +=1 'show as next day++++++++++++added 05:27 10/APR IF timbuf[hours] == $1A timbuf[hours] := $20Yes, I combined all that into one timer cog etc since it was fairly easy to see that none of this code was doing anything much, but this code is the software version of the ratsnest prototype that really needs to be replaced with a whole new version rather than reworked.
I do want to learn! I am not a pro, just a hobbyist having fun. I am totally self taught via book or web. I do learn lots from looking at code posted by the pro's though much of it I do not understand. I read the forum often.
What do you mean by " it would be better to know the outcome"? Are you asking what I am trying to do as an end result? I have attached a screenshot of the monitor which should explain a lot. As you can see there are many pieces of data to be dealt with and inserted yet and a more friendly eye pleasing screen too.
The last 5 of my discussions were related to this project.
Thanks for your input
Aaron
I talked about this in my presentation on the Propeller and programming in Spin. Something I repeated in that presentation is: The root word of specification is SPECIFIC.
You can see that presentation here. You might pick up one or two useful tips.
--
It's usually better to keep a project constrained to a single thread, unless you're isolating something (e.g., a generic object) that can be used across multiple applications.