BasicMicro - Forums

Second attempt: first one the server failed on submit? Will start with data from Lynxmotion posting this time...

Build 2.0.0.6 (and prior ones as well)

Real quick update on high speed. I know from the past that specifying a baud mode of i115200 did not work properly with the SSC-32. So I thought I would experiment a little. I know that I115200 compiles to 0x4011, where the high nibble of 4 is for the invert. the 0x11 or 17 is the number of .5us units of time that each bit takes.
That is 2000000/115200 = 17.36... As I mentioned before the 115200 appeared to actually output at 125000 (at least according to my logic analyzer), So I decided to try a baud mode of: 0x4012, with a real simple test program:


The logic analyzer again said that P16 had a baud calculated at 125000 and it had P17 calculated as 117647, if I tell it to use the baud rate of 115200, it still properly identifies all of the characters that were output. I also modified the program to instead use 0x4013, the auto-baud feature guessed the baud as: 111111. If I manually told it to use 115200, it again showed the right characters, but I noticed that where the analyzer said the sample locations was appeared to be closer to edges (more likely for errors).

So next step is to try recompiling the CHR3 with SSC-32 with cSSC_BAUD set to 0x4012 and change the jumpers and see if it works...
Update: I updated the CHR3 as I mentioned and it appears to work with the baud mode I mentioned above...

Notes: compiling with 115200 (0x4011) says the pulses should be 8.5us in length. The measure length was 8us. The 0x4012 should have pulses of 9us, but measured 8.5. It is almost like there is an off by 1 error in calling a delay loop of 10 cycles. This probably would not impact lower speed as the percentage off would not be as much...

Ken - Also the manual should probably mention how the data like: Parity, Inverted, Open Drain, Baud rate is encoded on the Baud mode.


Kurt

I'll see if I can find the off by 1 error in the calcs as soon as I can.

_________________
Tech Support
Basic Micro - Robotic Technology Evolved

Maybe something like this for the PIC?



Yeah, different chips, but some of these instruction cycle time and timer calcs get a little strange...

It's probably better to calc at the max speeds to get and verify constants, and then divide down for the slower rates. That way, the errors divide down as well.

Am I making any sense??

Alan KM6VV

_________________
Visit:
http://groups.yahoo.com/group/SherlineCNC/
http://tech.groups.yahoo.com/group/HexapodRobotIK/

I've fixed this and done some other tweaks to the serin/out commands. The +1 error was caused by my counting one pass of the delay loop as overhead and then adding the delay loop time. This was only an issue in serout. I unrolled some code which means the commands are a little bigger(about 50 bytes split between serin and serout). Also the top speed successfully tested for serin was 156250bps without timeouts enabled and 125000bps with timeouts enabled. 156250 was too fast with timeouts enabled so the max bps will be somewhere between 125k and 156k. Serout appears to work upto 166666bps. But since serin can't work that high I wouldn't recommend going past 156k.

_________________
Tech Support
Basic Micro - Robotic Technology Evolved

Sounds great!

Kurt

Great fix, and much appreciated!

Alan KM6VV

_________________
Visit:
http://groups.yahoo.com/group/SherlineCNC/
http://tech.groups.yahoo.com/group/HexapodRobotIK/