jmkasunich_ is now known as jmkasunich
dang... I think I need 9 bits to configure a GPIO pin
why so many?
[01:06:28] <jmkasunich> http://pastebin.ca/493979
to tell the driver how to present the pin to HAL
why do you need to not export the invert params?
I'm trying to allow both a general config (pin controlled by hal pins/params) and a specific, less cluttered one (pin configured at driver load time, fewer HAL pins)
why not just select the HW options and then export everything appropriate?
maybe I'm missing something in the paste
seems like some of it effects HW function and some is just export options
actually everything there is controlled by the driver, the FPGA config is the same always
yes, that I understand
if the user just wants a totem pole output
why not just specify that and export all appropriate pins/params?
why all the separate export options?
flexibility... what you are saying makes sense, although it would require a detailed listing of the options
there are 512 combinations in that listing, not all of them make sense
If I enumerated them, I might have less than 256
you might be able to compress the selection to an input option and an output option
then use a few bits each
then maybe you can get it into 8-bits
I have a hunch its not gonna compress as much as I hope
many of the bits in the initial pastebin are orthogonal
let's list input and output options
inverting and open collector, for example, would apply to all outputs
for output you have off, totem, open-col, tri-state
with and without inversion
yes, and an invert bit for all
what are the input options other than off, and on?
tri-state gets messy, because then you have to decide where the OE is coming from
wouldn't you just export an OE pin for that?
so 2-bits for input with inversion bit
and 3 for output with inversion bit
I'm thinking that someday (maybe sooner than later) there will be an FPGA (VHDL) block that does SPI or something else that needs to be able to tri-state under FPGA control, not HAL control
that's only 5 total
how would that block get connected to the pins?
this would happen through the driver config?
like HAL within the FPGA?
it would happen in VHDL
if it's in VHDL, then why do you need config bits for it?
there would be the VHDL block that does whatever, and the VHDL block that is a "pin driver" (containing all the GPIO registers and inversion logic and OC logic and such
and you would be able to route the SPI block to any IO pins and configure them dynamically?
the pin driver would have "internal output", "internal input" and "internal OE" ports that could be connected to something in the FPGA, or not
no, not dynamic
when then, at VHDL synth time?
you'd decide in the top level VHDL that "pins 2, 3, and 4 are connected to SPI port 1"
then the only option after place-n-route is to say "I'm not using SPI 1, let me use those pins as GPIO"
but why isn't all that args to the comp instantiation in VHDL then?
sounds like the SPI block would just take over IO control of the pin when it's enabled, and the GPIO would have control when not
because most folks don't have the VHDL tools, or don't know VHDL, or both
I don't follow
you write the VHDL
and you assign the SPI to some pins
and the signals get connected
and you have a flexible pin driver that takes some args
maybe you tell it there are 2 control sources and it creates muxes or whatever
then everything gets synthed and routed
and the only user option is who controls the pin
SPI, or GPIO
the problem is that there are too many variations
for SPI, what you are saying makes perfect sense
for stepgen there are problems tho
are you trying to provide routing flexibility at run time?
not routing, just config
where do the problems come in?
for example, stepgen - if I'm driving geckos, I want an active low step pulse, and open collector output
(since the FPGA can only drive up to 3.3V)
ok, but stepgen would have to have control signals for the IO pin to use that
so even tho stepben "controls" the pin, I still need to be able to acces the "OC" and "invert" capabilities of the GPIO pin driver
oh, I think we are mixing things up a bit
the GPIO block is what I was calling the user level IO block
then you have your SPI and stepgen blocks
and then some type of configurable IO block
the IO block gets controlled by the SPI, stepgen, or GPIO
ok, the config IO block would be what I'm calling the pin driver
so the pin driver would have bits (or hal params) for off, on (totempole), OC and tristate
so the IO block probably exports are IO cell control pins and maybe instantiates muxes and select lines as well for IO pin sharing
I don't think the pin driver would ever be exported directly as HAL pins/params, although the GPIO block may look very similar to it
^are IO^all IO^
I was thinking of the pin driver and GPIO block as one and the same... splitting them might have some advantages
another thing I was trying to allow is letting you export a HAL input pin for a physical pin that is either an input to or an output from some internal thing (stepgen, encoder, SPI, etc)
that would let you use scope or meter for testing (within their respective bandwidth limits)
IOW, see what your stepgen is putting out, or see what is coming from your encoder and going to the FPGA encoder counter
maybe build some type of crossbar for that and have all the internal pins go to it too
the ADI DSPs have a configurable IO crossbar
it allows 20 external pins to be routed to any of the internal function blocks
I'm having this conversation in an attempt to find a simpler solution to my problems, not make them harder
and there is another one that routes internal connections between blocks
that would get expensive on the 5i20
wide muxes are very expensive
yeah, but you're trying to do a lot
if you want it simple, maybe have a coulple of muxes on diag pins and call it a day
I'm content for each pin to be either a single specific function (step, dir, spi-data, spi-clock, encoder-phase-a, etc) or GPIO
then you can select 2 or so signals to look at
the other option, although not preferred, is to use tristate inside the FPGA
not sure if the xilinx part supports it, but most do
the hardware for reading any hardware pin as a HAL input is gonna be there regardless, so allowing any pin to be exported as an input is a cheap and easy way to get diagnostics
I don't want to take the diag thing any farther than that
Oh, I thought you were saying you might want to route some internal signal to a pin so it could be viewed?
sorry, I wasn't clear
when I said scope and meter, I meant halscope and halmeter
so I was thinking only put that capability on a few of the pins, not all of them
if you have a physical scope, you can already access all the 72 pins
right, but what about internal signals, or do you not need that?
I wasn't thinking of that - a VHDL developer might want something like that, but users won't
the VHDL developer will most likely be happy with the simulation
users will say "why ain't my fscking encoder counting" and a logical first step is to see if there is something arriving at the input pins
I was thinking there might be some internal sigs that would be usefull for user level diag
but I don't know what you have in there so it's just speculation
that would vary on a module by module basis - stepgen might have some that encoder won't, etc
crap, I'm supposed to be on a call
and they can be exported to HAL by the stepgen-specific driver code
I'm going to bed... would be nice to discuss this some tomorrow - it really helps to be able to talk things thru
ok, I'll take a look
didn't realize you were back
just got the kids to bed, almost ;-)
u still up?
how will the internal functions be enabled/disabled?
stuff like SPI, stepgen, etc.
stepgen is the only one I have working now
but it is an option for it to be disabled?
it has a 2 bit mode register: off, step/dir, up/down, and quadrature
I think I would lean towards having an internal function take over control, rather than oring it with GPIO
there are a few bytes in the config ram that say "enable (and export the hal pins for) stepgen N"
a proper mux instead of an OR gate
I think it will save much debug headache, and probably won't cost anything in terms of xilinx gates
I agree, but that means more bits of config info, not less
I think the xilinx blocks will do a mux with the same resource usage
why, you already have the mode bits for stepgen
they would control the mux
oh, I see what you are getting at
so when stepgen is enabled, it controls the IO pins
the reason I wasn't thinking that way is that the stepgen is a self contained block with just two output pins
so if no internal function is using the pins, then the gpio function gets them by default
I could certainly add a third that says "I'm enabled"
right, it's internal, and I'm sure there are enough internal routing resources
in a way, there is already half a mux in the stepgen
if you don't take the simple approach of export everything, is the config for the IO going to be put in the 1K of data?
when disabled, its outputs are forced to zero
and how does the user set that data, is there some tool?
there is a simple file format, like so:
how does the tool know what the options are? Is it specific to the driver?
its not that fancy a tool (yet)
# specify the bitfile:
## use size.bit
# protocol version
# board type code
# stepgens have 5 byte blocks
# byte 0: block type, 10/11 = vel mode or position mode
# bytes 1-2: base address (in the FPGA)
# byte 3: pin number for step/up/phaseA
# byte 4: pin number for dir/down/phaseB
10 w0x400 0 1
10 w0x410 2 3
that file says "start at address 4, store 1, 1, 10, 0x400, 0, 1, 10, 0x410, 2, 3"
so the tool parses some info from the bit file?
there would be more of the same for the rest of the stepgens, then the as yet undefined codes for GPIO config, etc, etc
the tool doesn't parse anything
the user writes (or more likely modifies) the file format above, with ye olde text editor
so who reads this file?
the "tools" are just used to merge that file with the bitfile and get it loaded into the FPGAs ram
but the tool puts it into a binary form with the merge?
the xilinx format breaks the bitfile into chunks - they use 5, 4 have info about the file, the 5th has the bitstream... I just added a 6th for the config ram data
and my version of the loader loads the bitstream first, then reads the 6th chunk and writes that into the FPGA's ram
but what's the format of the config ram data? it's not ascii is it?
my config ram data? the 1K? its binary
right, so there is some grammar the tool understands and the usre write, then the tool converts it to binary and merges it with the rest of the FPGA config?
so the user really needs to know the low level register bits as that's what the current language looks like?
yeah, at this point they have to know that "10" is the code for a vel mode stepgen, and that the next two bytes are the HW address of that stepgen (determined in the VHDL), and that the VHDL connects it to pins 2 and 3
I'm still struggling a bit with the separation of the FPGA implementation and the HAL view of it
however, the most common thing they'd do with a stepgen line is comment it out, which results in the driver not exporting any stepgen stuff and the stepgen remaining disabled
so its not too painfull
I think they are still a bit too merged
it seems like at the low level you want to config the HW/FPGA
then on top of that you want a HAL view of the HW
you may be able to determine the HAL view from the config, but most likely it will not be ideal
so you really want a second layer of config info for the driver HAL exports
well, the goal is to define the config such that I can determine it
"config" in this case means that 1K ram block
but the register bits that are optimal for the FPGA implementation, may not be so hot for specifying the HAL view
yes, so maybe that block is two parts
one for FPGA register values, and one for HAL view
not sure I follow you
the config ram simply tells the hal driver "there is a stepgen at FPGA address 0x400"
there is stepgen specific code in the driver that knows what that means
if the FPGA register values map pretty well to the internal signals needed to control the IO cells, that may not be a good specification for the HAL view
for instance, the user may not want the input pins/params
in this case, three writeable regs and one readable one, with rate, three time values, mode, and enable, packed into them
but you won't have any way to know that
that kind of thing is exactly the issue that I've been talking about all evening
I understand that, I was focusing more on the gpio HAL view
so at the low level there is some reg init data that sets up the FPGA
then I think some higher level HAL config data might be appropriate to avoid the name space polution you are concerned with
I want to stick a couple bytes in the 1K block that let the user say "for I/O pin 26, I want a HAL input pin so I can see what is going on, I want the pin to be driven by the stepgen, and I want it active low, open collector"
do you want the user to see the HW/HAL separation or you want to treat it as one from his point of view?
"for I/O pin 31, I want a HAL output pin, and a HAL output-enable pin"
I think you lost me again
there is lots of HW/HAL separation
for example, the HW will put 24 "output-enable" pins in a single register
when the user writes the config file for the tool, do you want him to be aware of the separation of config data, or should the tool do it?
there may only be HAL pins for a few of them, the others are static, defined by the config ram
when he's writing the config file, he should be thinking in terms of "pin N should do this"
and not care that in the HW, pin N is processed in parallel with 23 others
right, so does the user specify the value for the reg, then the HAL view, or does he just specify what he wants for each pin and the tool builds reg values and HAL view?
he specs what he wants for that pin
my original 9 bit value was how I was gonna do that
it would be something like:
pin number, 9bitcode, another pin number, another 9bit code
ok, so the tool will separate out the reg values and build them, so it won't be like the previouse example you gave of just specifying values to write to the register
no, the tool just sticks the bytes in the fpga ram
the driver reads them at insmod time and interprets them
for a single GPIO connector (24 pins) there will be a series of 24 bit bitmasks in the driver
ok, it may be simpler to let the tool do more work, then the driver can just load reg values and read some nice bit mask of HAL exports
when the driver sees a code for pin 17, it will modify bit 17 of the various masks as needed
why not push that work to the tool and simplify the driver?
that means putting more knowledge in the tool and less in the driver
and right now I'd rather have it all in one place
(we've had this argument before, and I'm too sleepy to argue it again)
it would make the driver simpler and save resources
(we've had this argument before, and I'm too sleepy to argue it again)
I'm just thinking you have limited 1K space and don't want to waste it being verbose
I hear you
I agree that I don't want to be verbose
thats why I was bummed that I needed 9 bits
I am forcing the user (at least right now) to work with bitfields, and the result is pretty darned compact
a tool could simplify life for the user later
if the tool did some processing, the 1K could be an array of reg init values, and a bit array of HAL exports
but that would put more knowledge in the tool
I initially started out thinking array (and smart tool)
but that is really rather limiting
if you want a higer level view for the user, I can make a quick parser for you so you don't need to deal with bit masks at the user level
suppose I eventually wind up with 20 possible VHDL blocks
stepgen, encoder, pwm, SPI, serial A/D, serial D/A, digital I/O expander, etc, etc
either the user needs to know the details of each block, or the tool does
so you just push the knowledge to the user if he has to figure out the bits
I'm certainly open to nicer tools at the user level, but ultimately the data needs to be packed into something that is compact and documented
how many FPGA configs do you plan on supporting?
is it going to be just one config that gets morphed, or are you going to have multiple to optimize functionality?
configs as in unique top-level VHDL, resulting in a unique mix of blocks that have been placed and routed?
a few that try to please 95% of the user base
with the other 5% free to get the xilinx tools and build any combination they want
I'm thinking the main "mainstream" one will be 8 PWM, 8 encoder, and 8 stepgen, mapped to pins such that you can use any or all of those functions
so how does the tool know which config it's targeting, or does that knowledge get pushed to the user too?
or turn off any/all and use the pins as GPIO
there is a "## use foo.bit" line at the top of the file
"use" means "merge this config ram info with that fpga bitstream"
so does the tool do any error checking, or is that left to driver load time?
driver load time
hmm, not too user friendly there
we need to use some words more precisely
I have two tools right now - the ".ram+.bit => .fpga" merge tool, and the ".fpga => 5i20card" loader
there can also be a tool that is more user friendly and generates the .ram file
that tool would do lots of checking
ok, I think that would be good
the merge tool is intentionally just a merger of binary data, it has no idea what the data means
my first thought would be to have a generic tool that is driven by some descriptoin of valid options for a config and fully checks what the user has put in the file
this is for the high level tool
that would be nice
I don't know how to write it though ;-)
but that will distribute some of the knoledge, but I don't think that's bad
I can help you with that
with or without that tool, there has to be a format for the .ram file that the tool and the driver agree on
why not make that as simple as possible to meet the needs?
my goal for the moment is to establish that format, and have it not so obscure that you absolutly NEED the high level tool to write it
where did you see the problems with the config data array approach?
is that because you don't have the high level tool yet, or some other reason?
if you're only dealing with the 8 stepgen/8 encoder/8 pwm/everything else GPIO case, arrays are fine
where do you see it breaking down?
if you want to allow a VHDL capable user to build a bitstream with 3 stepgens, 5 PWMs, 3 of another kind of PWM, 4 encoders, 2 DACs, 4 ADCs, etc, then it gets messy
a stream handles that much better
I'm not sure I see the problem
the driver simply parses the stream - 1 byte says "this is a stepgen", the parser calls "export_stepgen", that reads the next byte or few, and exports whatever HAL stuff is needed for the stepgen
wouldn't each of those modules have byte multiple registers that need writing with data?
oh, I was still thinking along the lines of separate HW init data and HAL export data
but I see where you're going
each of those modules will have a "export" function in the driver, to export the relevant HAL pins and associate them with the relevant structure members in HAL memory
each block will also have one or more RT functions, that do whatever is needed when you read or write to that block in RT
for stepgen, it includes stuff like limiting velcoity anc accel, scaling, etc
so you want to see more of a structured stream, and the driver will determine the HW config and appropriate HAL exports fomr it?
that could certainly work, but you might get more HAL namespace polution that you want
but that may not be so bad
just depends on how good the .ram protocol is
maybe what's needed is more filtered views of HAL namespace ;-)
yeah, no argument there
but I'm not the guy to write that
I don't think it would be that hard to make a parser that understands some basic syntax for this
then the semantics could be read from some file that described each module and would be checked against it's rules
if you have an idea for how you would like the language to look, I can make the parser pretty quickly
I don't see how it can be that generic
let me show you some of the structure I have now...
[05:18:43] <jmkasunich> http://cvs.linuxcnc.org/cvs/emc2/src/hal/drivers/mesa_5i2x/hal_5i2x.c?annotate=1.3
line 33 talks about the RAM content in general terms
line 457-480 parses the stream
there is a switch in there, that branches based on the first byte of each block
"this block describes a stepgen"
but this is inside the driver, it's not the high level user view
"this block describes the GPIO options for a single pin"
what does the user file look like at the high level?
have you gotten to any examples of that yet?
I pasted a sample a while ago
that was pretty low level
it was short, because all that config had was two stepgens
it looked like write this data to this address
the data is the stream
I thought we were talking about making a higher level specification of the stream that was more user friendly?
when the stream contains "10 0x0400 2 3" (in binary, 0A 04 00 02 03)
yeah, but that's not user friendly
that means "there is a stepgen at 0x0400 in the FPGA, and the user wants you to export the HAL pins to use it"
friendly is the job of the next level tool
wouldn't it be better to say something like stepgen = 0x400, etc.?
sure, but I want to make it work, then make it friendly
you can't put "stepgen=0x400" in the RAM, because its too big
so I need to define the compact binary representation
my problem right now is that I don't have the compact binary representation for GPIO
so right now you seem pretty happy with the stream format, is that correct?
ok, so the stream format is ok, but you need a more compact binary format for gpio?
such as it is - I've only defined the stream format for a single entity - stepgen
I think the stream should follow the same syntax for all modules
so it may need some thought
different modules will have differnet needs
without the same syntax, the tool will be ugly
different needs, but same syntax
for a stepgen, the only info you need to convey is "it exists, at address foo, and the user wants it enabled"
like different programs, but all in C
so maybe there is a structure with certain attributes
but you have to distile it to something primitive that uses the same syntax
are you talking about the syntax of the 1K block? or the input syntax for a high level tool that generates a 1K block?
the input syntax the user will write
ok, thats why we keep talking past one another
I have absolutely no interest whatsoever in that syntax at this point in time
I care only about the 1K syntax, because I'm writing the driver code that will read the 1K
for now, I'm generating the 1K manually
I certainly don't want to come up with a 1K format that will cripple a later tool
but the primary requirements for the 1K syntax are that it be compact, and at least a little bit logical
isn't whats described on line 33 of the pastebin the 1K format?
are you not quite happy with what you have there yet?
the part labeled "blocks" is general though
a block that describes a stepgen is 5 bytes long, and the meaning of those 5 bytes is unique to stepgen
the block that describes a GPIO pin is ? blocks long and is unique to GPIO pins - thats whats not defined
so you just want to focus on the gpio block for now
likewise, the block that describes an encoder is ? bytes long and I have no clue what it will say
so first thing is what does your gpio reg model look like?
you mean the actual FPGA contents?
I think the part about other modules using the IO cells gets handled by them being enabled and gpio gets them by default
the fpga registers for controlling gpio
not cast in stone yet, but something like this:
do you have an OE register, a pin register, a data register, etc.
(all of these regs pack in 24 bits)
sure, but what regs do you have right now?
output pin reg, input pin reg, oe reg, open-collector enable reg, and inversion registers
6 bits that define everything the HW can do with a pin
so OE and OC are not so orthogonal
[05:34:32] <jmkasunich> http://pastebin.ca/494277
lines 27-45 describe those registers (if I choose to simply export everything to HAL)
yeah, that's your first cut at the 1K stream for a gpio pin?
lines 1-20 was my first cut
the stream would be "pin-num, 9bit-code"
9 bits sucks, that makes it 3 bytes per pin
and at this point you want the stream pin oriented and the driver will build the 24-bit values?
ok, let me think on it
the driver will have masks that were generated based on the stream
some bits of each register will be copied every time from hal pins or params, and merged with the masks, then written to the HW
so somewhere a pin address is needed too or some way for the driver to know what pin it is
other bits will come only from the masks, because the HAL pins weren't exported
the pisser is that I really need 6 values, each with 3 possible states
3 doesn't pack well
only in octal ;-)
the states are: fixed-at-1, fixed-at-0, and get-from-hal
3 states uses 2 bits
output enable: fix at 1, fix at 0, get from hal.... same for oc-mode, output-invert, input-invert
only the get-from-hal case would export the pin or param (obviously)
sure, but some of the states of bits may be able to be infered if a simpler view can be presented in the stream
only the non-orthogonal ones
the oc-oe thing might be compressable from 4 bits down to 3
so we need a more orthogonal view in the stream
the inverts can't be compressed
how is the pin number assigned? is it strictly by order?
I was planning on "number, code, number, code"
so you could specify them in any order
and even intermix them
ok, so this is just the code part?
I suppose the 72 pins (7 bits) could be packed with the 9 bits
in the HAL view here, are you departing from the model of drivers exporting both the inverted and non-inverted input?
but that is the kind of thing that really forces you to use a tool
the inverts aren't really for the HAL input/output
cause that can be done in the driver
they're for the dedicated functions
what is bit-1 then?
if you need active low step pulses, or your encoder has an active low index, you gotta invert it in the pin-driver
bit 1 and several others are a result of me trying to please everybody
hmm, I think the other module needs, pin driver, and gpio are getting mixed together
I think if they are separated this will get easier
the stepgen itself could have polarity bits
and it should control the pin driver when it's enabled
but polarity is something that will get duplicated for just about everthing that can drive or read from an I/O pin
so I wanted to put it in the pin driver
maybe it does make more sense to put it in the modules
no, polarity function will live in the pin driver
so the HW won't be duplicated
gpio will specify pol for pins that are used as gpio
stpgen should specify them for it's pins
I thought you just said the opposite
both control the pin drivers polarity control pin
the stream specifies gpio and stepgen, not the pin driver
if a pin is truly GPIO, it doesn't need a hardware inverter at all
maybe not if you export both version of the pin
I can invert in HAL - the traditional in and in-not for inputs, and out + out-enable for outputs
but all stepgen related stuff should be in the stream block for stepgen
the only reason for the HW invert is for stepgen
and I was being stupid not to just put it in stepgen
see - this is why I like to discuss these things with people
that's what I was asking before about departing from the HAL driver model
right, put it in stepgen and it's much cleaner
[05:48:36] <jmkasunich> http://cvs.linuxcnc.org/cvs/emc2/src/hal/drivers/mesa_5i2x/firmware/stepgen.vhd?annotate=1.2
that defines my registers in the FPGA
I have bits 19-31 available to me, I can easily put invert in there
hmm, open collector is a bit nastier though
each module should pretty much contain all of it's config
sometimes that gets a bit ugly with clock divider stuff
but I like to stick to that rule
you should be able to take a module and use it without a bunch of other module dependancies
this is in regards to HDL
I agree pretty much
it's makes the SW programmers life easier too
thats why there is a stepgen.vhd, and a 5i2x_stepgen.c - between them they contain all stepgen specific info
as the register will usually turn out much nicer
except for the invert stuff that is needed and in other registers ;-)
that does double (at least) the number of signals leaving the block
yeah, but that's not a big deal
I can do the invert inside the block, so thats not a problem
but for each pin (step, dir) leaving the module, I also need to send an enable
you will still need the OE control sigs if it's reauired with stepgen
OE is used to make open-collector
so the IO cell has pin, data, and OE, correct?
in gpio mode, maybe you don't need OC mode
it's easy to do by setting data to 0, and using OE as the data pin
makes the gpio model a bit cleaner
lerman_ is now known as lerman
it looks like [HAL]SHUTDOWN is only in TRUNK
that's not necessarily what he needs - the spindle turns off when you exit
(I just tried it last night)
but that was trunk I guess
I don't see this noted in the changelogs at http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Released
but I'm not saying you're wrong either
I'm not sure how to test it
without attached hardware, yeah
temporarily add a "halcmd show pin" in the emc runscript at the right point?
I think emc.in rev 188.8.131.52 is the fix
(whereever that point might be)
maybe it is in the release notes, just not with the keywords you wanted: fix problem with MACHINE ON which was left active on shutdown
yeah I searched for spindle
cradek: in my copy of v2_1_branch I added this to the runscript:
$ grep -A2 "show pin" scripts/emc
$HALCMD show pin motion.spindle
echo "Unloading hal components" >> $DEBUG_FILE
$HALCMD unload all
the "show pin" line, that is
when I run stepper and hit f1 f2 f9 alt-f4 I see this in the terminal output: 05 bit OUT TRUE motion.spindle-on ==> spindle-on
shows what I know
I know it worked on trunk, yesterday, with pluto
maybe some fix is missing in 2.1, or it's just a consequence of the pluto resetting and I mistook it
it works on trunk with the motenc-100 in my system as well
and some of the other IOs are not cleared, so it's probably not accidental
I don't see that kwaj answered my last question
(I was trying to surreptitiously determine whether he successfully updated)
I have 2.1.5 installed as well
I guess I could run that and try it
do you remember the old mod param name for motion?
Guest733 is now known as skunkworks_
skunkworks_ is now known as skunkworks