Interfacing the PIC to a computer

[Jay.slovak]

ok guys. this is the complete story:
there is a PIC controlling a stepper motor for the steering; there is another PIC controlling the gas and brake pedals for the speed; there will be 2 or 3 PICs connected to sensors around the car, and all these PICs have to send their data to the pentium and receive orders from it all the time. what is the best way to connect the mother board to the PICs?
is it clear?

A single fast PIC can do all that. Try using a PIC18F452 running at 40Mhz clock speed (10Mhz crystal X 4). The problem with using multiple PICs is that although each PIC is running a single task, the overhead for communications will probably rob you of any gain.

The easy way is to use the serial communications port running at the highest baud rate you can set the PIC on. You can also use an RS-232 to RS-422 in a multi-drop arrangement to several PICs. There is also application notes on CAN (controller area network) on Microchip's website.

There are also PCI to microcontroller adapter chips available out there. I can provide a link once I get to the office.

If you can manage to produce a PCI interface, why not control the I/O directly from the PC? Except maybe for the stepper motor controller, you can do I/O directly from the PC port. You may have to write a device driver for the PC operating system however. :shock:

HTH

I don't think we should even think of using PCI for this application. Serial will be sufficient for few servos. We should look for the simplyest solution, not for the best looking. 8)

 

[Nigel Goodwin]

it will not be wireless. the pc will be on the car. the program run by the pentium will be probably written in C++ under linux. will the serial port be appropriate for such a real time application? it is extremely important that information about the obstacles around the car don't reach the pc too late!

As I mentioned before, this is a VERY SLOW application, anything mechanical is going to be slow - so there's no need for incredibly fast communication between devices.

If it's taking 500mS to move the steering wheel, what does it matter if it takes 1mS or 1uS to send the information?.

'Real time' is governed by the outside world, this moves relatively slowly, PIC's and PC's both work a great deal faster - both PIC's and PC will be spending the vast majority of the time just wasting time, slowing themselves down to match the 'real world'.

I mentioned the Mythbusters car, this was radio controlled - which means that the FASTEST possible change takes at least 20mS - this makes the car drivable, and no slower than it would be if manually driven.

 

[motion]

I don't think we should even think of using PCI for this application. Serial will be sufficient for few servos. We should look for the simplyest solution, not for the best looking.

That's for the thread starter to decide. Let's not be too patronizing to decide what's good for him/her. Just offer what's out there and let him/her decide.

 

[Nigel Goodwin]

That's for the thread starter to decide. Let's not be too patronizing to decide what's good for him/her. Just offer what's out there and let him/her decide.

The whole point of asking for suggestions is to receive them!, if he didn't want them he wouldn't have asked!.

Building a PCI card isn't a good solution to the project as stated, so why would we suggest it was?.

Where building a PCI card (or simply buying a suitable one?) 'might' be useful is in using the PC totally to control the car - no PIC's or other controllers, everything done in the PC, and interfaced through a PCI card (or cards).

 

[motion]

Where building a PCI card (or simply buying a suitable one?) 'might' be useful is in using the PC totally to control the car - no PIC's or other controllers, everything done in the PC, and interfaced through a PCI card (or cards).

That is exactly what I suggested. That is why I would not rule out using PCI entirely, specially if the requirement is to use a PC.

 

[Jay.slovak]

Where building a PCI card (or simply buying a suitable one?) 'might' be useful is in using the PC totally to control the car - no PIC's or other controllers, everything done in the PC, and interfaced through a PCI card (or cards).

That is exactly what I suggested. That is why I would not rule out using PCI entirely, specially if the requirement is to use a PC.

I think using Paralel port of the PC would be a good compromise Between PCI and USART+PIC solution. Paralel port could controll more than 8 devices, and that would be sufficient for this project.

 

[motion]

There was I time I studying ways to interface to the PC using the PCI bus and one of the things I came across was PCI card which can display the diagnostic POST codes of the PC.

**broken link removed**

I bought a sample to study and it contained just a couple of GAL chips and PIC clone chip to drive the display. You can probably implement a similar interface for your project. This card might not exactly meet the PCI bus signaling specs but if you're after a hobbyist PCI implementation, this is one idea to consider.

 

[Jay.slovak]

There was I time I studying ways to interface to the PC using the PCI bus and one of the things I came across was PCI card which can display the diagnostic POST codes of the PC.

**broken link removed**

I bought a sample to study and it contained just a couple of GAL chips and PIC clone chip to drive the display. You can probably implement a similar interface for your project. This card might not exactly meet the PCI bus signaling specs but if you're after a hobbyist PCI implementation, this is one idea to consider.

That card is just displaying POST informations that are present on the PCI bus. To make the Interface we need is harder, it will require more than GALs, you also need to write suitable driver and software for it, because that PCI card needs to communicate with CPU (unlike that POST card).

 

[motion]

To make the Interface we need is harder, it will require more than GALs, you also need to write suitable driver and software for it, because that PCI card needs to communicate with CPU (unlike that POST card).

Of course it's harder but I am just pointing out the possibilites. Anyway, I think reading from the card shouldn't be too much harder than writing from it, unless your mind is already closed to that idea.

 

[Jay.slovak]

To make the Interface we need is harder, it will require more than GALs, you also need to write suitable driver and software for it, because that PCI card needs to communicate with CPU (unlike that POST card).

Of course it's harder but I am just pointing out the possibilites. Anyway, I think reading from the card shouldn't be too much harder than writing from it, unless your mind is already closed to that idea.

As I said, the POST card is just showing what's happenning on the PCI bus. It has no connections to the CPU or memory. And it is gonna be VERY difficult to start building such a special card from scratch. There is no difference between reading and writting, main problem is just to make it work with all the IRQs, DMAs, Addresses, BIOS and OS.

 

[checkmate]

Of course it's harder but I am just pointing out the possibilites. Anyway, I think reading from the card shouldn't be too much harder than writing from it, unless your mind is already closed to that idea.

Jay is right. The PCI interface part would make your entire project look like child's play. Most of the customised interface cards require at least a CPLD, not to mention a customized kernel driver. And those who have written drivers before should understand that it's one of the most difficult aspects of PC programming. I don't know about Linux drivers, but at least for WDM drivers, it's hell.

 

[Jay.slovak]

Of course it's harder but I am just pointing out the possibilites. Anyway, I think reading from the card shouldn't be too much harder than writing from it, unless your mind is already closed to that idea.

Jay is right. The PCI interface part would make your entire project look like child's play. Most of the customised interface cards require at least a CPLD, not to mention a customized kernel driver. And those who have written drivers before should understand that it's one of the most difficult aspects of PC programming. I don't know about Linux drivers, but at least for WDM drivers, it's hell.

Finally somebody understands how difficult PCI really is...

 

[Dan East]

I would avoid PCI for more reasons than I care to count.

For starters, if this is supposed to be mounted in a vehicle, why not use a laptop instead of a desktop machine? Going the PCI route would prevent that flexibility in the future. Of course modern notebooks have mini-PCI, but the physical connectivity is completely different.

Dan East

 

[YAN-1]

Dear everyone,

After carefully reading all your suggestions and recommendations, my partners and I are now seriously considering the serial port solution instead of going for the PCI. Not that we don't like challanges, but the project itself is huge enough that we need to find easier solutions for some of its parts. But I was wondering:

Would it be difficult to set the baud rate under linux?

What is the longest possible time that it could take for 3 bytes to reach 3 different PICs from the PC through the serial port and also for about 4 bytes to reach the PC from the PICs assuming that I will use a master PIC to receive the bytes from the PC and then distribute them to the other PICs and the same PIC to take the bytes from the other PICs and send them one by one to the PC as well?!
I'm not sure about the most suitable baud rate and the PICs available are the 16F628, the 16F876, and the 16F877.
Thanks.

 

[Jay.slovak]

What is the longest possible time that it could take for 3 bytes to reach 3 different PICs from the PC through the serial port and also for about 4 bytes to reach the PC from the PICs assuming that I will use a master PIC to receive the bytes from the PC and then distribute them to the other PICs and the same PIC to take the bytes from the other PICs and send them one by one to the PC as well?!
I'm not sure about the most suitable baud rate and the PICs available are the 16F628, the 16F876, and the 16F877.
Thanks.

I can assure you, that it's a very short time, for example if BaudRate is 9600, than it takes about 3.1 mS, that's pretty short. And with Baudrate of 115200 it takes 0.26 mS...