[2010-10-27 00:53:50] Anonymous said:
This object only includes a byte receive function with waiting? Is it possible to make it compatible with FullDuplexSerial? Reply

[2011-02-04 22:42:30] Anonymous said:
This is great -- faster & smaller than fullduplexserial. I took the liberty to modify it so that it's compatible with fullduplexserial. Leave the Assembly code alone and replace the Spin code with this: PUB rx '' 6 Stack Longs repeat until(available) return inputBuffer[inputTail++] PUB available '' 3 Stack Longs return ((inputHead - inputTail) & $FF) PUB rxfull '' 6 Stack Longs return (available == $FF) PUB rxflush '' 3 Stack Longs inputTail := inputHead PUB tx(character) '' 4 Stack Longs repeat until(outputTail <> ((outputHead + 1) & $FF)) outputBuffer[outputHead++] := character PUB str(StringAddr) '' 8 Stack Longs repeat strsize(StringAddr) tx(byte[StringAddr++]) PUB rxcheck : rxbyte if (available) return inputBuffer[inputTail++] return -1 PUB rxtime(ms) : t '' Wait ms milliseconds for a byte to be received '' returns -1 if no byte received, $00..$FF if byte t := cnt repeat if (cnt - t) / (clkfreq / 1000) > ms return -1 until available return inputBuffer[inputTail++] pub start (rp,tp,f,b) ' for compatibility with fullduplexserial: flags are not actually read return init(rp,tp,b) PUB init(receiverPin, transmitterPin, baudRate) '' 9 Stack Longs stop baudRateSetup := ((clkfreq / ((baudRate <# (clkfreq / constant(80_000_000 / 250_000))) #> 1)) / 4) baudRate := ((transmitterPin <# 31) #> 0) counterModeSetup := (baudRate + constant(%0_0100 << 26)) RXPin := ((|<((receiverPin <# 31) #> 0)) & (receiverPin <> -1)) TXPin := ((|<baudRate) & (transmitterPin <> -1)) inputHeadAddress := @inputHead inputTailAddress := @inputTail outputHeadAddress := @outputHead outputTailAddress := @outputTail inputBufferAddress := @inputBuffer outputBufferAddress := @outputBuffer cog := cognew(@initialization[0], @cog[0]) result or= ++cog PUB stop '' 3 Stack Longs if(cog) cogstop(-1 + cog~) 'mkb@libero.it Reply

[2011-05-11 17:54:44] Anonymous said:
Warning, this driver (rev 1.6) suffers from occasional data corruption. The author is aware of that fact. For details check this thread in the forum http://forums.parallax.com/showthread.php?129764-Key-File-System-Driver-Serial-Port-Problem Reply

[2011-05-16 01:51:57] Anonymous said:
This driver does not attempt to sample close to the center of the bit and quite often samples close to bit transitions. It therefore is unreliable even when the two systems that are communicating have tight clock tolerances. It appears from previous comments that the author has known about this bug for a few months but has failed to do the right thing and fix the issue. I personally spent 2 solid days debugging my system and ultimately replacing the driver completely. How many other folks have paid this price I wonder? Reply

[2011-07-30 02:55:20] Kwabena W. Agyeman said:
Sorry, guys - I've been busy working on a bunch of other projects that have taken my time away from this. I've updated the driver now and you should no longer have any problems. To above anonymous - I assumed people would stop using it until I could get arround to fixing it. Thanks, Reply

[2011-07-30 02:56:41] Kwabena W. Agyeman said:
BTW - I do not receive an email unless you actually rate the object. So, I haven't even seen the above dialog. Reply

[2011-08-30 14:53:06] Kwabena W. Agyeman said:
Please ignore the above comments. All previous problems have been fixed. Thanks, Reply