developing drivers for custom boards

More
11 Jul 2011 09:59 #11385 by andypugh
Replied by andypugh on topic Re:developing drivers for custom boards
btvpimill wrote:

I have modified Andy's pcl720.comp file, for what I think seems logical for an EPP driver. If someone doesn't mind looking it over to see if I have modified it properly that would be very nice.

Not being sure how parports work, that seems fine.

Assuming it seems correct, I have a question about using 2 cards (1 on each of 2 different ports). I think I need to create another set of pins, then somehow I need to use those for the read and writes of the second port.

You will be happy to learn that it is much, much easier than that. In fact it is already done.

just load your comp with

loadrt custepp ioadr=0x378,0x1028

And you will automatically get pins like:
custepp.0.pin-01-out
for the card at 0x378 and
custepp.1.pin-01-out
for the card at 0x1028.

All the handling of multiple cards is handled by the code that comp creates. You can even use your custom component like any other HAL component, so this will work too:

loadrt custepp ioaddr=0x378,0x1028 names=fred,charlie

will give you
fred.pin-01-out
...
charlie.pin-01-out
...

Please Log in or Create an account to join the conversation.

More
11 Jul 2011 12:07 #11389 by btvpimill
Replied by btvpimill on topic Re:developing drivers for custom boards
This is just awesome.

Now I suppose things like RESET thread will have to go away. And I assume it stands to reason my step speed will be the same if not slower using the port this way. but overall I think I will be much happier with the setup.

Please Log in or Create an account to join the conversation.

More
11 Jul 2011 12:27 #11391 by andypugh
Replied by andypugh on topic Re:developing drivers for custom boards
btvpimill wrote:

Now I suppose things like RESET thread will have to go away. And I assume it stands to reason my step speed will be the same if not slower using the port this way

There is no reason you can't add a "reset" function to the driver, to work in just the same way as the parport one does.
However, it might make sense to do reset in hardware.

Please Log in or Create an account to join the conversation.

More
11 Jul 2011 13:54 #11401 by btvpimill
Replied by btvpimill on topic Re:developing drivers for custom boards
Great idea. So emc will send the step high, then my card will reset it low after some finite time based on my driver needs. I like that alot!!

See, this is why I need to get these things ironed out before I write the code for my cards. At least the how it will work part.

Please Log in or Create an account to join the conversation.

More
11 Jul 2011 14:09 #11405 by andypugh
Replied by andypugh on topic Re:developing drivers for custom boards
Well, actually, now I think about it some more...
It might be easier to do it in EMC2, as the configuration of which pins need to be reset and which need to be left is probably easier.
You _could_ send a set of reset-mask bytes every thread, though. But then you might need to define a communications protocol.

Please Log in or Create an account to join the conversation.

More
11 Jul 2011 14:22 #11407 by btvpimill
Replied by btvpimill on topic Re:developing drivers for custom boards
Not sure about the protocol, but its no problem if I know what it wants to be. It will already have a very fundamental protocol in the fact that 4 bytes will be sent- and they will be read as such. So for instance R0 = steps, R1 = dir, R2 = outputs, R3 = spindle speed. For now I will assume all 4 reach the card as they should. I am thinking for error checking, maybe set or clear the MSB's for the 4 bytes read back. 1 is good transmission and 0 is bad. This will be based soley on receiving 4 bytes. if less or more are received then it is an error. Maybe that is not needed? The reason for using all 4 msb's is just in case something goes wrong reading back the info. If emc gets at least 1 byte it will know there is a problem.

On the other hand, the step pins will always be the same pins - not configurable. So unless I am missing something (good chance of that), seems like I could just always drive the steps low x-time after receiving from the port.

Please Log in or Create an account to join the conversation.

More
11 Jul 2011 14:37 #11408 by PCW
Replied by PCW on topic Re:developing drivers for custom boards
How about one address write to reset your state machine on the EPP remote
so it cannot get out of sync with the host, that is write the step signals with an address write
and the other signals with data writes/reads which increment your data register pointer

Please Log in or Create an account to join the conversation.

More
11 Jul 2011 14:49 #11411 by btvpimill
Replied by btvpimill on topic Re:developing drivers for custom boards
Oh so many great things I would never have thought of. so on the first outb instead of outb (R0,base+4) use base +3. That is just too easy. Thanks PCW.
For whatever reason, I was taking it at face value that if I did an address write, I needed to send an address. Doh! that will just use the address write line from the EPP port to signal to my card to reset the pointer no matter what.

Please Log in or Create an account to join the conversation.

More
11 Jul 2011 14:57 #11413 by andypugh
Replied by andypugh on topic Re:developing drivers for custom boards
btvpimill wrote:

On the other hand, the step pins will always be the same pins - not configurable. So unless I am missing something (good chance of that), seems like I could just always drive the steps low x-time after receiving from the port.

No, I don't think you are missing anything. That should work fine.

Please Log in or Create an account to join the conversation.

More
18 Jul 2011 13:53 #11599 by btvpimill
Replied by btvpimill on topic Re:developing drivers for custom boards
Still plugging away at this. Been BUSY at work so no real progress just yet. But I have another question. Assuming I reset the steps in hardware, won't I need to tell EMC/HAL not to worry with it? I get that not setting a reset will tend to that part, but how do I tell it to always generate the start but never worry about the reset? Or if I need to keep the reset thread in there, how to not actually send the reset to the port?

Or maybe I am half asleep (again), it is Monday morning afterall.

Please Log in or Create an account to join the conversation.

Moderators: PCWjmelson
Time to create page: 0.186 seconds
Powered by Kunena Forum