worthy of a new obj? is it worthwhile?
ok. I thought I'd throw together an object that would run debug commands on a separate cog (thus not slowing down --much-- the cog that is giving me the info). But I've caught a snag, and I'm sure it is something simple.
Here is what happens: the LCD clears, then 0 is displayed, one second later 1 is displayed, then it hangs (most likely until the internal clock loops back) for a minute or so then 2 is displayed, and it continues, but at the pace of 1 every minute, rather than 1 every second.
Can someone else run this code, or tell me what I am doing wrong?
The object:
While this may not be the best way to do this, it will work for my uses
Post Edited (Bobb Fwed) : 9/25/2008 8:46:33 PM GMT
Here is what happens: the LCD clears, then 0 is displayed, one second later 1 is displayed, then it hangs (most likely until the internal clock loops back) for a minute or so then 2 is displayed, and it continues, but at the pace of 1 every minute, rather than 1 every second.
Can someone else run this code, or tell me what I am doing wrong?
CON _CLKMODE = XTAL1 + PLL16X ' 80MHz clock _XINFREQ = 5_000_000 ' 5MHz Crystal DEBUG_DISP = 1 ' display debug terminal DEBUG_P = 4 DEBUG_BAUD = 19200 ' only 19200 with 80MHz clock DEBUG_LINES = 4 OBJ DEBUG : "DEBUG" PUB debug_test | i DEBUG.init(DEBUG_p, DEBUG_BAUD, DEBUG_LINES) REPEAT i from 0 to 500 DEBUG.dec(i) waitcnt(clkfreq + cnt)
The object:
OBJ lcd : "serial_lcd" ' driver for Parallax Serial LCD num : "simple_numbers" VAR long val1,val2 byte ntype long debugstack[noparse][[/noparse]500] ' cog stack byte cogon, cog PUB init(pin, baud, lines) ' initiate cogs stop cogon := (cog := cognew(debug(pin, baud, lines, @val1, @val2, @ntype), @debugstack)) > 0 PUB stop ' stop cogs if already in use if cogon~ cogstop(cog) PUB debug (pin, baud, lines, val1Addr, val2Addr, typeAddr) lcd_init(pin, baud, lines) ' start up the LCD obj lcd.cls REPEAT REPEAT UNTIL byte[noparse][[/noparse]typeAddr] <> 0 ' repeat until ntype is changed CASE byte[noparse][[/noparse]typeAddr] 1 : lcd.putc(long[noparse][[/noparse]val1Addr]) 2 : lcd.str(val1Addr) 3 : lcd.str(num.dec(long[noparse][[/noparse]val1Addr])) byte[noparse][[/noparse]typeAddr]~ ' reset back to 0 to "wait" long[noparse][[/noparse]val1]~ long[noparse][[/noparse]val2]~ PUB lcd_init(pin, baud, lines) : okay okay := lcd.init(pin, baud, lines) PUB putc(txbyte) val1 := txbyte ntype := 1 PUB str(strAddr) val1 := strAddr ntype := 2 PUB dec(value) val1 := value ntype := 3
While this may not be the best way to do this, it will work for my uses
Post Edited (Bobb Fwed) : 9/25/2008 8:46:33 PM GMT
Comments
Change the following:
You should·also reverse the order of the repeat loop. You are using the byte[noparse][[/noparse]typeaddr] as a flag between processes, so their order is normally important. This is not your problem though because you are waiting for 1 second anyway. But get into good habits or you will spend hours trying to find this one.
It works as a drop-in replacement for the Debug_Lcd object, but it uses a cog to reduce load (and time) on the "source" cog. I will find it very useful as I rarely use all my cogs in my work, but I wonder if others may find it useful.
It will remove wait times for debug commands that are more than a couple ms apart (at 80MHz) and will always reduce the wait time for single debug commands.
Please let me know if this is object worthy, this would be my first "official" object, so what would the next steps be? Also, are there any changes to the code that should be done?
Post Edited (Bobb Fwed) : 9/25/2008 8:57:22 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com·- Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto fo SunSPOT, BitScope
www.sxmicro.com - a blog·exploring the SX micro
www.tdswieter.com
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com·- Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto fo SunSPOT, BitScope
www.sxmicro.com - a blog·exploring the SX micro
www.tdswieter.com