Confused about synchronous communications

Thanks,

I'll check it out. Unforutnately I have much more work to do because the driver I was using for port communication(Inout32) with C# was taking

For your i2c communication it seems like you don't you any interrupts or polling? If thats the case then I shouldn't have any problem. Although I'm reading up on kernel mode drivers in windows at the moment I really don't want to go that route if I don't have too.

Thanks, Jon

Well, I have looked at some others codes and all they do is bang the bits outs. I'm sure this method works 99% of the time. Most likely I will do this too but I want to get it as fast as possible.

Biggest problem I have though is if I have to poll or use interrupts to do any of these protocols(that is, basically if I have to be a slave). In that case I'm pretty much screwed because there is no easy way to do that in windows(the polling is easy but very unstable). But I'm sure I can do atleast ICSP which is my main goal.

Thanks, Jon

On a sunny day (Fri, 21 Sep 2007 16:46:53 GMT) it happened "Jon Slaughter" wrote in :

i2c has the advantage that it works on a multitasking system (Linux or mswindows). If the communication is interrupted by a task switch, the system will just wait a few milliseconds. 'polling' does not apply here, as you can change the clock (scl), and then read the input (sda), so you have full control. The routines have a delay that you can set (soft delay), in a more modern version in Linux one could use usleep(), a non-clockspeed dependent delay.

On a sunny day (Fri, 21 Sep 2007 16:50:51 GMT) it happened "Jon Slaughter" wrote in :

If you want to play slave, then I highly recommend using a separate micro controller with buffer (say fifo), if you want to avoid writing interrupt routines. Even in real time Linux interrupt latency can be > 10uS. I dunno about mswindows. If however you use an external hardware buffer, you can signal it has data, and have the PC read the lot at once.

Normally in i2c I only use the PC as master.

You could go to a garage sale, pick up a used PC for $10.00, and run DOS on it and bit-bang to your heart's content. :-)

Good Luck! Rich

Yeah, I was eventually thinking about doing this but I first want to be able to program PIC's and a few other devices using ICSP, I2C, and SPI. Once I get a working program that does what I want I'll think about trying to make it better. Since PIC's support USB, SPI, I2C, Serial, etc... its pretty easy to get data to and from them but I first need to be able to program them and I want to play around with some of the debugging features and stuff.

Its just that windows makes this a bitch to do. In dos it would be a piece of cake...

Well, I'm not sure I understand the protocol completely. For example, it has an awknowledgement but I'm now sure how it works. Because in this case the slave has to set the data pin but the master is controlling the clock. There are cases also where the slave will hold the clock line low to interrupt the master. I don't see how I can solve these problems easily in windows without interrupts and polling. Its going to be more work than I thought. Hopefully though I can get ICSP done pretty easily and then I'll probably use a pic as a proxy for the other two protocols since they have it built in.

Thanks, Jon

What I plan on doing is timing how long it takes to send a bit to the port... actually it takes about 3us in my C++ non-managed code using a kernel mode driver and it about 7us in C#. I'll time a delay routine so I know just how much to delay. The only problem is that task switching will, in general, extend these delays quite a bit. But if I don't have to poll then its no problem.

Essentially if all communications is governed by the clock line, the master is the only one that can control it, and arbitrary frequency shifts in won't screw up the communications then its no problem.

I believe all are true but I'm not 100%.

Thanks, Jon

On a sunny day (Fri, 21 Sep 2007 14:12:16 -0500) it happened "Jon Slaughter" wrote in :

Yes that is so, in tha tcase yo uneed to allow clock high and poll it.

As far as PIC programmer, the simplest one on parport I know about is noppp, I think this is the link:

Be aware that if you use an external micro, you can read a byte or bytes at the time, either via parport or serial port, and do not have to change IO several times for a bit, so you gain a _lot_ of speed.

Thats a problem then. Because when polling I do not know the rate at which I'm polling so I have no way of knowing how to seperate the bits if they do not change.

I'm sure I can do some logic to determine the frequency but because of windows and its task switch it could cause some strange problems. (I could even miss out on some bits.... I suppose though if I do not have to poll much then it shouldn't be that big of a problem)

I have used WinPic successfully to program some pic18's but had some problems on other pics. It also, AFAIK, doesn't support the new pic24's which is what I'm mainly after. They use ICSP and Enhanced ICSP and AFAIK the old pic's don't support EICSP.

The main thing I'm trying to achieve is write an ICSP programmar that also has the ability to debug code using JTAG. Although I'm sure I could just use mplab to do that. I also want to be able to control the data transimission rate. With WinPic its just a slider that doesn't tell you much about how fast its going.

I plan on profiling the computer to determine the avg data rate and use that as a guide(it can be much worse but it would help some).

Actually right now I'm looking how to write kernel mode drivers so who knows if I'll ever finish this project ;/

Yeah. And you don't have to worry about task switching or anything like that so timing is pretty easy.

Thanks, Jon