for the control-line the enable and direction lines are tied -- enable to gnd (always enable) and dir to vcc (always gate A to B)
so they're using it as a unidirectional buffer
for the data lines, the enable is tied to gnd (always enable) but I didn't determine what the direction line is tied to
with only the control-line '245 installed, it also lives through the read function
did you have to unsolder the chips?
no, they're socketed (happily)
wow, thats rare these days
I bet the 245 dir pin is driven by some tiger local bus signal
are the 8255's socketed?
yes they are too
you think it would be interesting to unsocket them and put in both 245s?
did you already try pulling them (with the 245 installed)? ISTR you mentiioning that but I'm not sure
no, I haven't done that yet
yes, assuming some assumptions are right
assumptions being that the 245 is between the tiger and the 8255s
245 pointing at empty sockets = nothing happening
I'm pretty sure of that
8255 pointing back at the tiger when it wants to use the bus = problem
that would point you directly at 245 dir issues
no, the 245 would still drive the tiger data bus even if its inputs were floating
whether or not the 8255s are there
or are you telling me that this will say whether it's 8255 bus or tiger bus?
right - if you still get the problem it exonerates the 8255 and points a finger at the dir line
if it's two things driving one bus, it could be tiger + 245, or it could be 245 + 8255
yeah, but the latter would (I think) not mess up the tiger register reads
you'd have contention on the far side of the 245, the near side would be OK
although I'm a little confused because the registers in the tiger shouldn't be on the local bus at all
I figured over-current somewhere was killing the chip -- in fact, until I saw the configuration registers read back earlier, I assumed the tiger320 was dead and gone, not just a little bit dead
* jepler wonders if he swapped the '245s around between the sockets
(I didn't track which was which when I removed 'em)
they're fairly hard to kill
there are also more "interesting" things that could make it not work when you have contention
for example, if one is driving high and the other low, there will be a pulse of current that could cause ground bounce on one chip or the other and disrupt things that nominally have no connection to the bus where the contention is
this is interesting -- the dir input of the data bus '245 is an output of the control bus '245. If I can believe the silkscreen, it's XRD# which I've taken to mean the 8255-bus version of the tiger's RD# signal
that sounds reasonable
there's another chip I could unsocket: 74HCT139 which is a 2-to-4 decoder. I believe its outputs are connected to the CS# lines of the 8255s
without that one, the 8255s should never driver the data bus
yep - are the 8255's CMOS? if so, you should pull their floating enable inputs high
if TTL they'll be high by themselves
here's a thought: there are local bus addresses that would correspond to the unused output of the '139. that's a way to get nothing to drive the 8255 data bus while having all the chips socketed
I'm not sure what the idea here is
if you accessing certain addresses is the problem, you can just remove those accesses and see if it stops crashing
that lets me leave everything in the sockets, have nothing driving the 8255 bus, but have the 245 drive the tiger320 bus
how is changing the addresses a better test?
do you have a fairly repeatable crash condition now? or is it still random?
the 8255s are marked "82C55AC" and I don't see a convenient way to tie their CS# lines high but this will work just as well for pointing the finger at the 245 <-> tiger bus
for me, it happens almost instantly after installing the read function
(on a very few occasions I've been able to observe in 'halcmd show' that the read function takes on the order of 2 seconds before it died entirely, but usually the crash is too fast for that)
other than all the annoying reboots, that is good
and the problem now is that I keep bending the card bracket on each insertion .. maybe I should unscrew it
at work we're trying to troubleshoot a problem (in france, on stuff that has been modified by others) that happens between once a day and once a week
sounds like me with the hardy/amd64/rtai kernel
well, except the france part
when RD# is going high, the 8255 will continue driving its outputs for up to 75ns while '245 is guaranteed to start driving its outputs after only 20ns. Does that 55ns matter?
hard to day - it is certainly something that a good designer would try to avoid
the question is, are we dealing with the work of a no-good designer, or a good one who has determined that in this case it's OK?
OK, doing the reads at offset 0xf0 (no 8255 should be driving) does not crash, doing reads at offset 0xc0 (8255 should be driving) does
these are dip chips?
yes, the 8255s are socketed DIPs
about the only surface part is the tiger320
you don't happen to have a dip clip so you could scope them do you?
I realized that with the crashing and all it would be kind of hard anyway
I was thinking trigger on the RD line, and probe ground, vcc, etc looking for bounces
as well as probing the data lines looking for contention (levels that are neither hi nor low)
it really seems odd that contention on the 8255 side could bust things
when you read from the address that doesn't crash, what do you get? 0xFF?
if the I/Os aren't back-to-back, the machine stays up
(adding a printf of the value input is enough)
very very interesting
this has to be more than just local bus contention anyway - to take down the PC it has to somehow propogate to the PCI bus
when I read from the non-crashing address I get 0x00 consistently
a timing thing, or a wait state thing...
when I read from the crashing address, the first time I got 0xff. Then I modified the program to outb() the loop counter to the same address and I got different results
oh and this time it locked even with a print and a delay
which means maybe you are reading back a value from the previous write, floating on the data bus
no, I am not sure about that. if the 8255s ports are in output mode (not sure what mode they're in by default) then this would in principle read back the same value
here are a few lines from the output before the crash. first digit of each pair is value read, the second is the value written just before (stupid order, I know): ff a9 / fe a8 / ff a7 / fe a6 / ff a5 / fe a4 / ff a3 / 45 a2 / ff a1 / fc a0 / ff 9f <crash>
so let me just note that there's a pretty high correlation in last-bits but the rest is less clear
only one bit in the readback is toggling
so "bits" is a bit optimistic
oh, didn't see the 45
sorry, should have starred it or something
should have read it or something
lemme get this right - when you read (only) you get 0xff, and at least if you do a printf it doesn't crash
when you write and read, you get the data you showed me, and it crashes
if I do 256 inb() back to back it crashes immediately. If I have something else (like printf or udelay) it doesn't consistently crash. It did eventually crash when the loop consisted of outb / inb / printf / udelay(1000)
so outb is not a neccessary condition for the crash
no, I don't believe it is
consecutive inb's will do it, as will outb immediately followed by inb
before I did any outb(), the read-back from 8255 was consistently 0xff, which is what I would expect having read the datasheet again
try a delay between the outb and the inb, and otherwise exactly the same as the last time
(when a reset condition is set, the digital I/O are set to input mode but there is some kind of pull-up type device)
so if it was working right I'd be reading 0xff all the time
maybe the condition is "any access immediately followed by a read" or even any access followed immediately by any access
I've never had it lock up on reads, and I'm pretty sure that's sam's experience too
on writes you mean?
so that probably rules out write-write
yes I think so
we know read-read will do it
the functions are fairly symmetrical -- (read, trivial amount of computation) * (up to 9 repetitions) or (trivial amount of computation, write) * (up to 9 repetitions)
and we think write-read will do it, but maybe its really just individual reads plus dumb luck
in hal that is
I've always wondered how I/O reads are handled
the frontside bus is so much faster than PCI
I/O writes can be posted, and the CPU carries on
does the CPU have to halt while a PCI read is happening? or does it do some kind of out-of-order execution while waiting for the data
I don't know about PCI but I've looked carefully through the tiger datasheet and it looks like the device on the host bus has to deliver the response in specific number of PCI bus cycles (I configure for 15 bus cycles, following the sample code)
I suspect but don't know that the CPU doesn't speculate ahead of inb
inb/outb are signs of low-performance hardware, there's no point in making the CPU fast in that case
in the case of our code, it can't speculate very far - I suspect the very next line uses the result of the inb
that's true as well
so the CPU does an inb, and the frontside bus goes into wait states
then the PCI bus cycle starts, and it goes into wait states
then the local bus cycle starts
but the tiger isn't waiting for any signal from the 8255. no matter what happens on the local bus, it just latches that value after XXns and puts it on the pci bus
ok, that was my next question
and that comes to the heart of the weirdness
it seems that no matter what the tiger grabs, it should be able to put that on the PCI bus without bringing down the whole machine
if I read the datasheet right, it simply asserts local bus READ# for XXns and latches the data from the local bus at -10..+5ns from the rising edge of READ#
OK, so you want a loop that is outb(); delay(); inb(); printf(); ?
yeah - maybe add a delay after the printf too, if you think the printf can happen quickly
delay, out, delay, in, print
the 15 clock delay that you programmed the tiger for (following the example) - can that be made longer?
no, 15 is the highest
(more than one "tested" hardware design has fallen on its face when purchasing got a batch of chips from another vendor and the delays changed
if you could add more delay it would be an interesting test, but if you can't you can't
with a couple of udelay(100000) it hasn't crashed yet but it does spuriously read back non-0xff
that 100000 is in uS? nS?
so 100mS between reads, only 10 per second?
when you had no delay it could do thousands or tens of thousands per second, right?
without delay and print, yes
that muddies the data a bit
you had one run where "out, in, print, delay" crashed it, right?
that migh have been after a few hundred cycles
we can't rule out something as simple as "a random timing issue that gives a 1 in 10000 chance of crashing on any read"
yes, I agree.
have you tried it in a (very) different machine?
what if you make the udelay about 20 instead of 100000
20uS is still very many PCI cycles, and very very many instructions
cradek: I don't have a dev environment, but I did try the livecd on another machine and it locked just like it does on this machine and like it does for sam
ok, 3 machines kind of rules out machine specific stuff
oh right, sam too
(well, sam thought it was correlated with toggling inputs but I don't know what to make of that)
is this two different boards? the one you have and a different on at sam's? or did he send you the one that causes problems?
jmkasunich: he bought 2+ boards and sent me one.
so they are probably from the same batch
but not the same board
but they are not the same board
does their software work?
I dunno if anybody has (or can) try it
I don't have any software
there's a document in thai that shows a delphi program doing some kind of operation with the board...
nor do you likely want to infest your PC with delphi
I was wondering specifically if anybody had tried on of these two boards
if its a batch related timing thing, their SW might break too
sounds like not a practical test
the "out. delay. in, delay, print" run still going?
I changed the program
I'm doing inb() from the no-op port, no delays, prints once every 65536 operations.
it's now done about 83 million and is still going OK
so banging the snot out of it
yes as fast as I can
and you had reliable crashes when doing 256 no-delay bursts of inbs, right?
(to the 8255 address)
so, we KNOW the 8255 address is needed to make it crash
I feel pretty safe saying that
we're not sure if time between accesses matters
it could be a 1 in 50000 thing and the keeps us from getting the couple hundred K that we'd need to know
now 270 million inb()s from the no-op port .. I am satisfied that this will not crash the machine
I was satisfied at a million or two
4 or 5 orders of magnitude better than the 256 bursts is pretty significant
from the tiger's point of view there is no difference between the ports, right?
no; it has a 4-bit host address bus
the 8255s take a0, a1 and the '139 decodes a2, a3 into chip selects
whan a2=a3=1, there's no 8255 getting a chip select
when you read the no-op port you get zeros, right?
a hundred million of 'em
as far as I saw during that run
unanswerable question - what would happen if the local bus was pulled up and reading the no-op port returned ff?
I thought I saw a 01 scroll by at the beginning of the first run after a mixed outb/inb program but I didn't recreate it and so I didn't mention it
there's actually a spot for a pull-up resistor pack on the 8255-side data bus that isn't populated, but I don't have any SIP resistors to put in there.
which side of the 245 is facing the tiger? A or B?
so a low on DIR drives the tiger
yes, I think so -- the signal silkscreened XREAD# is what drives that 245 input.
what is the tiger P/N? (or do you have a URL for the datasheet)
[01:33:40] <jepler> http://www.tjnet.com/software/download/data_sheets/Tiger320_data_sheet.pdf
what will HCT logic do with floating inputs?
IOW, nothing predictable
and sometimes things not nice - if it sits halfway between rails the chip can draw excessive current
often the capacitance of the traces can hold the previous value for quite a while
famous oops - write a memcheck that writes a value to an address and then immediately reads back from the same address to check - can pass with no memory installed
outb(0xff); inb() isn't turning up nonzero reads
in this case the 245 is enabled all the time....
I think that means that the far side bus doesn't get a chance to float
you might write ff to it, but then the local bus (tiger side) is driven to zero by the tiger between cycles
that drives the far side to zero, and thats what you read on the next cycle
yeah I can see that
OK, this test crashed after 1690 read()s. let me reboot so I can be sure to get the rest of the details of just what I ran ...
datasheet says you can use memory or IO, and ISTR swp talking about that
I never had luck with memory-mapped access
as in it crashed? or just never got any data back from the 8255s?
outputs never appeared
wow, this is a little bridge
didn't realize the local bus was 8 bits
yeah -- 3 8255s are about its limit of complexity
there's some kind of clocked serial bus too, but I have no use for that
I notice that they set the subsystem ID stuff using pullups and downs on the data bus
this is the program I ran last: http://emergent.unpy.net/index.cgi-files/sandbox/crashme.c
the internet says that outb() to port 80 gives typical 1usec delays (ISA bus speed, just like parport)
the internet suggests that usleep() in userspace is inaccurate for short delays so I chose this method instead
v was always nonzero and when it crashed the last line on the console was 0xfffff965 meaning that it had done 1690 (+-1) cycles
offset c0 is an 8255, right?
c0, d0, e0 are 8255s, and f0 is nothing
?0, ?4, ?8, ?c are the 4 registers of each 8255
oh I was off a bit in the # of cycles because the count starts at 256
I noticed the shift of address lines
OK, multiplied the delay by 100 and it crashed at ffffff52b -- something like 3000 reads
not a statistically different number
you said v was always non-zero
that means it printed every time?
yes, I suppose it was printing every time
so the difference in delay might not be as great as I thought
the print delay is probably longer than the outb(80) delay
but we know the delay was at least 1ms in the second test that died after 3000 reads
(2000 outb(0x80, 0x80))
probably more like 2ms
yeah - so its unlikely to be the actual timing that matters
more likely just the sheer number of reads
if we're averaging one crash per a couple thousand reads, it might look good in a test that does 10 reads/second
"good" would still be stretching it
well, it could take a couple hundred seconds to show up
dunno how long your test runs were
"huh, it crashed after 5 minutes -- well, that's windows. "
I don't see what else to try
either this board (and sam's) is bad, or the whole board design is bad
all bus-mastering, interrupts, and power management stuff is disabled, right?
I dunno. I assumed that the power-up settings were OK except for the ones set in the delphi program I read
but even if I could turn off an interrupt that was being spuriously generated, there's still the fact that it doesn't seem to reliably read the 8255 bus
it would be nice to be able to stick a scope on it
but triggering on the crash would be quite a trick
[01:59:49] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/regs.txt
this is the power-up state
well, it's what I read after booting into linux
will take a bit of datasheet reading to figure out what that all means
as far as I've checked it matches the power-up state from the datasheet
you're only writing to 00, 02, and 03, right?
yes, I believe that's right
The difference between the DMA end address and DMA start address will be the amount of data
that is to be transferred by the DMA. If the start address is “X” and the data transferred is “n”
what is this: outb(0x00, base+offset+3*4);
bytes, the end address will be “X + n - 4”. The minus 4 is needed to point to the very last location
as the first location is 0 and not 1.
that would set the control register of an 8255 to "all ports output" if it worked
(I don't think the paste above is pertinent, I just thought it was a terrible explanation of the dma address range)
that it is
this test program in userspace- but it still causes a hard lock of the entire machine?
_nothing_ on the local bus should be able to do that
pci_write can cause that, when the wrong registers of the PLX chips are twiddled
oh, we were talking about the difference between the time it takes the 8255 to release the bus and the time it takes the 245 to turn around and start driving after a read...
ok, I didn't read closely enough then
I think thats a non-issue - during the read, <somedata> is coming from the 8255 and going to the tiger
when the 245 turns around, its gonna see <somedata> floating on the tiger bus, and send that back to the 8255
which will match what the 8255 is driving until it releases the bus - no contention
I believe DMA, watchdog, and interrupts are all turned off in the power-on state and in the regs.txt dump .. I don't see anything else I can do there
we may be fighting a losing battle - the card may simply have hardware issues
it would be a good datapoint if sam could somehow test it with their software
I'm done for the night
even a single lockup running their code, and its "this card sucks, don't buy one, and we're not gonna waste our time anymore"
jmkasunich, SWPadnos, cradek: thanks for your help with this
especially you, jmkasunich
thanks for trying
you're the one who had to keep hitting reset (thats gotta suck after a while)
oh - you're welcome, for what little I've done. thanks for the (gargantuan) effort you've put in
I've been running the i/o programs for Futurlec's PCI8255 on W2k
There's several programs, all really the same, just developed on VB/Delphi/VC
All have same format, a widget with 3 rows & columns
each is a port, and under the post is a READ and a WRITE btn
each has a text field for display/or entry as case may be
none blows up, reads always return FF, writes dotn care what i put into the text fields
i dont have hdwr hooked up but will try to find flatbands, dipswx, leds and stuff to test with
i can also post the software somewhere if any one wants it.
I've asked teh futurlec people to release the source of the drivers but havent heard anything
its 2am g'nite
btw: i need this box to test with if i need w2k so my moniker may be diff for a while
skunkworks_: good morning .. you should check the logs
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2008-05-06.txt
skunkworks_: actually starting at the end of -05-05.txt
jepler: thanks. reading now.
holy smokes - this is going to take some coffee..
Thanks for all your work. (and every ones..)
I will see if I can get their software working.. (I might have to get it directly fromt them as I don't know if I can find or have the cd)
oh - tom seems to have tried it.
I think he should try the hal driver and see if his machine locks up. (maybe as jmkasunich had said - was a bad batch)
what's a good invocation for find to find files newer than 2 months?
* skunkworks_ would have thought that he copied the cd to his computer at some point.
alex_joni: something like find ... -mtime -60 ?
I wonder if setting that timing register down to 3 or so would help
all their examples use the "1 1" setting for 15 cycles.
yeah, that's true
if the source fragments in the pdf files I've found can be trusted
is that in PCI clocks or some other "local bus clock"?
I feel bad that something that should have been easy turned out to be such a cluster f$ck
SWPadnos: "When a PCI read cycle takes place .. the READ# signal will be active for 3-12 PCI cycles, the actual number of cycles is determined by the setting of bits 4 and 5 in the internal register 0x00."
(yes, it says 12, not 15)
15 is outside that range ??
I was thinking that the tiger chip may be stupid and drive the data lines while it's pausing before the read
if the 8255 has a 75ns max time to output, then you only need 3 PCI clocks to guarantee that the output is valid
that would reduce bus contention duration if the tiger is dumb
but we determined the problem was on the 8255 side of the '245s
... if the tiger holds the 245's in the wrong direction during the delay ... :)
the 8255 and '245 can probably sink a lot more current than the tiger anyway
elsewhere, T_p, command pulse width, is documented as taking min 80ns, max 640ns which is 21.12 cycles at 33MHz .. confusing
is that for the serial bus?
doesn't matter really
that's the time READ# or WRITE# is asserted on the local bus
just trying to figure out what 15 "cycles" actually is ..
one of the tests you did had the control '245 plus all the 8255s installed, right (ie, only the "data" '245 removed)?
yes. that setup never locked up.
since the tiger chip got screwed sometimes (reading all FF, etc), it also could have been screwed enough to fubar the PCI bus
I think the windows demo software is strictly user event driven, with the possible exception that there may be a timer used for reading port status
in one of the samples there's a 100ms timer for reads when you place the port in input mode. I don't know which sample tom1 may have been using.
the delphi code also runs in ring 3, so I/O instructions will be slower
a power-related problem probably wouldn't surface as often with a 100ms scan time
caps would have enough time to recharge, etc
I got lockups with delays of ~2ms + printf() to console, didn't test bigger than that
looks like you tried 100ms, and had no lockups
but sometimes got back "non-0xff data"
tomp: have you tried the hal driver for the 8255 card yet?
ello, i tried all 3 examples, bc/vb/delphi. what should i test?
oh, on linux? i thought you needed win$ testing
To rule out a bad batch of cards? (jeplers and mine where bought at the same time)
ok, it's it the car now, can try after a trip
hmmm. always sync before testing moidified realtime/kernel code
I've thought about adding a 'sync' in halrun for just that purpose
I've put 'loadusr -W sync' in hal files too
yes, either of those methods would have helped :)
not much is lost. at least it seems that make clean ; make ; sudo make install will fix it
oh I always use RIP
this is for an embedded system using HAL
the power supply thing
oh -- fixing bugs in it or something?
I thought that project was done
it was, until new specs arrived
oh I see
I hope new money arrived with the new specs
it should, once I finish and bill
new bill :)
man I should get back to offs
jepler: maybe you can join efforts with awallin?
alex_joni: right now I just need to find and fix some bugs
and I need to stop taking on new projects and get back to old ones
quick - everyone send jepler some new hardware.. ;)
right - I never got around to ordering 7i43s (then Seb Kuzminsky showed up)
yeah and I am thrilled about that
hmmm. I wonder if it's possible to use the parallel port on the 7i43 as an I/O port - ie use USB for communication and the parport for extra I/O
skunkworks_: could you pastebin a hal file with the desired cfg for the pci_8255?
what is the cfg syntac for pci_8255? i tried loadrt pci_8255 cfh="0xB001 IIIIOOOOIOIO" count=1
tomp2: modinfo /path/to/pci_8255.ko
thx (modinfo new 2 me )
SWPadnos: interesting question
I asked Pete - we'll see what he says
modinfo pci_8255 tells me "parm: io:I/O addresses of 8255s (array of int)"
does it mean base address(es) card(s) or chip's?
The code says
// relay off (active-high), cs low
WRITE(0x10, io[i]+3, 0);
and since there's only 1 relay, it must be the card addr right?
careful when reading the code
there are some global vars, some defines that make those globals look like locals, and local vars with similar or identical names
ok, so it the array of card addresses or chip address?
and those defines (like comp has, for pointer dereferencing etc) are midway through the code
just look carefully ;)
that particular write is to a tiger320 control register, and sets the relay and chip select output states before setting the directions to output (on the next line)
in that case, io is the card address, so io[i] would be the i'th card base address
peteW says no, the DB25 can't be used as I/O
[22:16:18] <tomp2> http://imagebin.ca/view/2EKEb16.html
loadrt pci_8255 io="111100001010" dir="0xB001"
and all the fx's addf'd to servo thread
[22:20:57] <tomp2> http://imagebin.ca/view/2EKEb16.html
loadrt pci_8255 dir="111100001010" io="0xB001"
used ETT's suggested PCI_TREE to determine base address
dir should be of the form 0xfff where each bit specifies a direction for a certain group of pins; io is almost certain to end 00, not 01.
there's also no guarantee that the io address is the same if you ran "PCI_TREE" on a different OS or with the card in a different machine
use lspci -v in linux instead
PCI_Tree said 0XB001
i can do that too
but its now a windows box
and the 0xffff...
will try that too
also the realtime threads aren't running, since e.g., ...b6 and ...b6-not are both FALSE -- that would be impossible in normal usage
0x000 will give all inputs and 0xfff all outputs, or vice versa (not sure)
why arent the rt threads running ( how to check ) ?
I don't know
but the most likely way for a pin and its -not to both be FALSE is if the function is not running
the indication of fred = !fred is why, ok
got a cfg string that you used handy? for next reboot to linux?
your io= will be different from mine
so I don't see that it will be that helpful
i'll use lspci for io
loadrt pci_8255 io=0xc000 dir=0x888
can you send me or tell me where to get one of these windows demo programs? I think I have a machine with windows that I can put the card in ...
i can send or upload the files and a card
i just did loadrt pci_8255 io="0xB000" dir="0xA59"
Ok, that should give a mix of inputs and outputs
it's running and i got 3 dialogs.. registering pci*255.0.0 .. 91 b0c0 and then 2 more
i still have pci8255.0.0.a0 and a0-not both false
pop ups with OK buttons
its running now
oh -- I guess if you're running this in emc2 those diagnostic messages will pop up as dialogs
(I always just use 'halrun', I don't start a full emc .. but do whatever you know best)
dont you want me to do anything ;) ( what i know best ...)
don't sell yourself short
lemme see if i got the cd files on the windows partition of that box
the output of 'halcmd show thread' will probably let me tell whether the functions I'm interested in are running
[23:13:25] <tomp2> http://pastebin.ca/1009873
i dont see any mention of 8255
yeah you'd have to addf it
(this is sneakernet with thumbdrives)
oh I see
that's about as inconvenient as rebooting every 2 minutes
which has been my experience trying to troubleshoot this thing
i'm getting the .ahl now
I think I may have found the demo programs in exe form
[23:20:46] <jepler> http://www.ett.co.th/downloada.html
(unless pc8255 and pci8255 are different products, not just typos ..
.. maybe not
no, it's for some older card, not the pci8255
the halcmd show thread http://pastebin.ca/1009887
versus the AXIS hal Show Configuration utility http://imagebin.ca/view/A9PodecW.html
i did have the addf's commented out
i did take a picture of the gui showing functions not threads
OK, I can explain what you're seeeing in the screenshot
that lists all the available functions, whether they've been added to a thread or not
in fact you can see by the number "0" before the name that those are not on a thread
as opposed to those that show "1" there, which are on a thread
ok, i can paste the .hal next ( cuz i dont see why they aren;t being added )
skunkworks: tomp also has one of these cards in an emc machine and he's trying to help troubleshoot it
it's slowed down by the fact that he has to sneakernet each screenshot or paste
looks like he needs to add the read funtions to a thread :)
* skunkworks act like he knows what he is doing
yep I'm pretty sure that's the missing step before he can have his machine lock up like ours do
meanwhile I was trying to get ahold of the windows test programs .. thought I'd found them on one of those thai-language websites but it was the wrong thing
I saw that on the logger.. I emailed futurlec but I think it would be quicker to get it from tom
[23:35:26] <tomp2> http://pastebin.ca/1009897
it looks to me as if i addde them and they didnt get added
looks like in the screenshots the functions have "-" while your paste has "_"
though I have to admit I would expect that to error and not continue starting emc
(dont believe what i type)
here is the hal file I use to lock up my machine: http://emergent.unpy.net/index.cgi-files/sandbox/8255.hal
just put it in your ~, change the I/O address in your favorite editor, open up a terminal, and type 'halrun 8255.hal'
after a few seconds, that reliably locks my machine up
emc dies, pci_8255,write not found ( i had probs with write_relay & write_all so I cut to the chase and only addf'd write & read )
should be pci_8255.write not pci_8255.0.write correct?
urff, reading back...
there are several different write functions .. it is all a bit confusing and over-engineered. pci_8255.write-all writes all connectors and the relay. .write-relay writes the relay open. .0.write, .1.write and .2.write write one 8255 each.
that hal file worked for me exactly as I uploaded it, with emc 2.2.5.
well, "worked" as in locked up the system :-P
".0.0"? two .0's ? as in pci8255.0.0.write thread from your paste ...will try that
well .. whatever my paste says ..
maybe the functions are for the individual ports of the connectors? I just remember that I made it too complicated.
I call it elegant