[LinuxCNC/linuxcnc PR#385] bspi fixes

#1 – andypugh 于 2017-12-25

Looks OK to me, and I am prepared to assume you have tested it at least as much as I tested the original.

#2 – sleepybishop 于 2017-12-25

@andypugh , thank you for taking a look at this during the holidays. do you know why it was disabled from the build system?

also i’de very much like to pick your brain about using the dbspi interface via the same code and other ideas you’ve had for the bspi driver, are the forums the best place for that?

#3 – andypugh 于 2017-12-25

On 25 December 2017 at 22:43, Joseph Calderon
wrote:
>
> are the forums the best place for that?
>

No, for anything that you want the devs to see, the developers mailing
list is the place to discuss it.
(Most of the developers don’t have the time to look through every forum
post to see if it is relevant to them)

—
atp

#4 – andypugh 于 2017-12-25

On 25 December 2017 at 22:43, Joseph Calderon
wrote:
>
> do you know why it was disabled from the build system?
>

No, and I can’t see if it ever was. I believe it was caught by a blanket
“.comp file” rule, but it isn’t easy to see where that might have changed.
(and a git-bisect might be painful, as I suspect that a “make clean” would
be required)

—
atp

#5 – jepler 于 2017-12-27

~~~~
ifeq ($(BUILD_SYS),uspace)
COMP_DRIVERS += hal/drivers/serport.comp
else
COMP_DRIVERS := $(wildcard hal/drivers/*.comp)
endif
~~~~
[that is in src/hal/components/Submakefile]

without checking, my prediction is that it’s never built on ‘uspace’ builds. Perhaps you and the original poster are reporting results of uspace builds, rather than traditional rtai builds.

#6 – sleepybishop 于 2017-12-27

yep, im on a custom uspace build. thanks.

#7 – sleepybishop 于 2017-12-29

i committed both those changes to the original branch.

#8 – jepler 于 2017-12-30

@sleepybishop thanks. I also fixed both of those indepedently of you, so we can consider those problems resolved. (the signedness problem at ea31e4f2a and the include path problem at f2a01b8bc)

In the future, when additional commits are needed to fix a problem in an already merged pull request, remember that you need to create a fresh pull request even if it is for the same branch as the original pull request.

#9 – sleepybishop 于 2017-12-30

@jepler great, thank you.