would "reentrant" allow adding multiple times to one thread? I thought about this once as a way to do multiple I/O on a dumb device per cycle. For instance, clocked-serial might want to write the parport 16 times and read it 8 times in the servo thread, with a call to a function of the clocked-serial component in between..
though that seems different than "reentrant"
yes, it should
there are no functions marked as reentrant at the moment
another application of reentrant (or something like it) would be if we ever add "function arrays" - most of the functions are re-used, just with different data
of course they have to be reentrant (by the standard definition) in that case, since you could e.g. add pid.0 to one thread and pid.1 to another
I guess that doesn't need an explicit flag - if we had a "hal_make_func_array" function, it would just create a bunch of functs with different names anyway
jmkasunich, if you do remove the reentrant flag, then delf can probably lose the thread name, since a function could only be in at most one thread
jepler, if you set the reentrant flag, you would be able to add to the same thread multiple times, regardless of whether that does one thing several times or a sequence of things
the trouble is that HAL wouldn't prevent you from also adding the same function to another thread, which could cause intermittent surprises
(at least I think you could add to the same thread multiple times, I'm not sure)
to call a function from fast and slow thread would require that it be reentrant
to call it multiple times from a single thread wouldn't
(in the normal cs meaning of "reentrant")
HAL doesn't care about anything other than the flag though
so you could use multiple invocations in a single thread to do something like you suggested
even though it doesn't need to be CS reenreant
if we remove the reentrant flag, we can choose to enforce "one function, ever", or "only in one thread, but maybe called more than once"
SWPadnos: I don't understand "function arrays"
I guess I was thinking of a shorthand way of creatig multiple functions
right now, you can call "hal_funct_new" with the same function, but pointers to different data (and we normally do that)
in many cases, multiple instances of a component (like PID) will have a single function that gets called with different data as the argument
that gives us pid.1, pid,2, etc
from the user's point of view, they are distinct functions
from the programmer's pov, they use the same code
I don't see why we would want to do anything that changes the user's view
if there were a magic way to write .all (aside from comp doing it) that wouldn't hurt (but it wouldn't help that much either)
I really don't like all
so a helper function where you give it hal_multi_funct_new(base_pointer, offset_in_bytes, count, "format_str", ...) would be a nice shorthand
if you feel strongly about it, it can be removed -- it's in TRUNK only
the odds of the function ordering being right are slim to none, unless the data paths thru each instance are parallel
* jepler has an aha moment
I thought about that before, but I didn't get to the end
"the user can simply make sure that and.0 *should be* evaluted before and.1, and so on"
^^^ too simple thinking
if it's for and.0, then xor.0, then and.1, ...
OK, you convinced me
that'll never work. it requires more thought on the part of the user :)
Running test: /home/jepler/emc2.tool/tests/hm2-idrom
hm2/hm2_test\.0: invalid cookie |test pattern 0 didnt produce error 'hm2/hm2_test\.0: invalid
hm hm2 test failures
Running test: /home/jepler/emc2.tool/tests/threads.1
test: 4: Illegal number:
*** /home/jepler/emc2.tool/tests/threads.1: FAIL: checkresult exited with 2
and whatever this means
oh that was because of .all
EMC: 03jepler 07TRUNK * 10emc2/src/hal/utils/comp.g: The "all" function only encourages users not to carefully consider the order of functions in threads. get rid of it.
EMC: 03jepler 07TRUNK * 10emc2/tests/loadrt.1/expected: The "all" function only encourages users not to carefully consider the order of functions in threads. get rid of it.
EMC: 03jepler 07TRUNK * 10emc2/tests/threads.1/test.hal: The "all" function only encourages users not to carefully consider the order of functions in threads. get rid of it.
bonk there goes my config
cradek: haha oops
'sokay I'm used to it
the hm2 test is broken on sim because you can't read messages from rtapi in the same way (by checking in dmesg)
EMC: 03jepler 07TRUNK * 10emc2/tests/hm2-idrom/skip: this test doesn't run on sim
SWPadnos: do you have the xilinx tools on windows, linux, or both?
I know you didn't ask me, but I have xilinx on linux only
I knew you wouldn't have windows
I'm thinking about the makefile I've been writing
I know how to make it work, but if I want to get peter to use it, doze would be usefull
he is very interested in being able to do builds from the command line
and maybe able to set up a linux box
emphasis on maybe
I have a python program that does most of the work, make isn't really doing much
that's an interesting point; python is pretty easy to install on windows
it wouldn't be a big step to have the .py spit out a bash build script and a doze batch file
since usually you "just rebuild everything", right?
yeah, make doesn't really save much
you could also have python directly execute the commands using os.system or os.spawnv
with C, you spend 2 minutes compiling and 5 seconds linking, and make lets you skip much of the compile
or use scons
with FPGAs, you spend 20 seconds compiling and 10 minutes "linking"
(not that i have any idea what you're talking about)
jepler: I didn't think about that approach
what happens to stdout when you spawn/system something? (xilinix tools output much messages to stdout)
just like in a shell: stdout goes to the shell's stdout unless you redirect it; same for stderr
so basically, it does what I want it to do ;-)
I bet python has os.foo for renaming/deleting/copying files too (another OS difference)
if you want better control over that (e.g., to redirect to a file) then subprocess.Popen will serve your needs. if you just want it passed through, then simply using os.system / os.spawnv will do
yes. os.rename, os.unlink for working one file at a time, shutil module for slightly higher level stuff like copying files or trees of files
just thinking one or two
I was originally thinking about "make for windows" (exists)
but the makefile tends to invoke things like rm, etc
I think you get basics like 'rm', 'mv', 'echo' when you install the mingw environment on windows
so he'd need rm for windows, mv for windows, etc - ick
yeah, there are ways to get a linuxy environment on doze, but that's just more hoops for him to jump thru
I have an incentive to make it easy for him
if you need python already, then trying to do it all from python seems like a good avenue to go down
my approach needs minor changes to the vhdl - if I make it easy for Peter, he won't mind those changes
he's already stated that he doesn't like the way he is doing config now, from a phone call I had with him I think he'll like what I'm planning
let me check how much space I have on my virtualbox windows .. should be able to install xilinx on there and work with you to develop this stuff
then we'll get him using cvs :-P
right now the biggest thing I think I'll lose when I switch from make to py is "make clean"
(of course that can be done in py too, but it smells like reinventing stuff)
the dependency management is already py, since make doesn't know about vhdl
config manipulation is also .py
virtualbox modules aren't out yet for the current ubuntu 8.04 kernel
jmkasunich, I have some older ones on Windows, and I can probably install a more recent version
I'm hoping that the command line tools are the same in both environments
you could try doing it in tcl, since the tools use that already
free space: 1.75GB
I wonder if that's enough space for xilinx
not even for the downloaded file
the version I have here is 2.4G unpacked, and it is over a year old
oh wait, you can just fit the download in that
guess I'll have to make another 4GB drive
but then there are 1.5G of updates (unless you start with 10.x.03)
bloat, thy name is xilinx
or maybe 8GB
* jepler wonders why his virtualbox shared drive doesn't work anymore
yes, espeically if you want the OS there as well
can anyone think of an easy way to see what thread a function is in (other than looking through the thread function lists to find the function name)?
are you referring to something you can do from the halcmd prompt? or something you could code as an addition to halcmd?
well, either way I guess
but it's for completion
if you do delf pid.0<tab>, it may as well fill in pid.0.calculate <threadname>
I know when you remove a comp, hal_lib can figure out what threads (if any) it's functions are in
or at least let you teb once more to get the thread name
yep. I can look at that
you could examine that code
as jepler pointed out, if we get rid of reentrancy, we can make delf not require the threadname
I bet it scans through the threads and looks for the owner ID of each funct
fenn_ is now known as fenn
jepler: SWPadnos: http://www.pastebin.ca/1280389
jmkasunich: I'd want it to be OK to specify the ".spec" extension, so that I can tab-complete it. maybe that's silly nitpicking on my part
no prob, the program needs to know the base name, but that is easy to parse
I think mcs and svf are the programming files I needed for jtag programming of my "s3board"
are the steps from 7 on doable by makefile?
one for volatile jtag programming, one for programming the flash
if so, the "stop and later continue where you left off" is done by make, not the script
SWPadnos: yes, but the cross-platform goal makes depending on make less desirable
right now I have one python program that does most of steps 1, 2, 3
another that does dependency stuff, but only one level, so that is part of 4
I suppose a Windows dependency on CygWin isn't desirable :)
the rest of 4 is currently done by make itself, thru an "include makefile.dep" line, and some weird stuff
5 and 6 are currently part makefile, part unimplemented, but trivial in .py
as you say, 7 onward is a bit of "reinventing make in python", although obviously much simpler
yeah. I guess you could add a --resume option or something
make_bitfile --resume myfile
and it can look for appropriately named intermediate files
yeah, all intermediates have the same base name, only the extension changes
in python it may be almost as simple as:
if (remake and file_exists(thefile)) or create(thefile)
it will need to check timestamps I think, unless the first thing a "non-resume" build does is clean out all the intermediates
non-resume should recreate everything
recreate doesn't imply "delete first"
but I think either that or datestamp checking is needed
actually, it's not quite that simple, unless there's a guarantee that any partially finisned steps won't leave an a correctly named file with incorrect contents
... partly finished steps ...
if ( not step_successfull ) : delete output
well, there's also ctrl-C to deal with
if you send ctrl-C to a python program that is running a child process, who gets it?
that is the kind of thing I was hoping jepler could comment on
typically if you ctrl-C this thing, you'll want the current step to die, and the python program to clean up and then exit
>>> import os
>>> os.system("sleep 30")
hit ctrl-c, signal is sent to sleep which exits with a nonzero code
just what we want
how'd that happen?
you'll also want to handle the uncommon case of hitting ctrl-c in between invocations of os.system()
you can do that by having a 'try / except KeyboardInterrupt' block around the whole process, which is treated just like an error
result = actual_build_process()
result = False
if not result:
some sort of failure, clean up, exit with nonzero status
where "actual_build_process" is several steps?
you could also write a wrapper for os.system/os.spawnv to turn a nonzero status into an exception, so you don't have to put checks everywhere
hmm, the cleanup probably depends on where in the process you were
it can't be of the form: "If file x exists, delete it"
you can have multiple Except blocks, I assume
so the code looks more like
(just pointing out exception handling for the c++ - phobic :) )
time to start coding
stupid question - anybody have a better name than "make-bitfile.py" ?
(no :) )
actually - make-xilinx-bitfile.py
I just watched "Who Framed Roger Rabbit" last week :)
those toons just can't resist 'shave and a haircut'
SWPadnos: given the assumption of some hostmot2 specific hooks, I'd be more inclined to call it "make-mesa-bitfile.py"
yeah, I was just realizing that there aren't any non-Xilinx bitfiles to make for these cards
3 hours later, they decided on a name, but by then it was past everyone's bedtime
so the project was shelved
I think I like spec2bit - not very original, but fairly short and descriptive
or just use ls to screw everyone up
and its sister app bitbanger
jepler: I'm planning to make the spec file look like this: http://www.pastebin.ca/1280407
and just execfile() it to get the info into python
is that a horribly fragile thing to do?
my gut says it is, but it is just so freaking easy....
if you expect users to edit the file, then it's fragile
well, they are expected to edit the VHDL in module_id and pin_desc
I don't know what the error messages look like when there's an error though - they may be good enough
that is more fragile than the python """ wrapped around it
I guess that's true
all the spec really is is 5 name/string pairs
two of the strings will contain newlines
ok, I see that now. it's probably fine, though I don't know how well errors in that file will map back from the Xilinx tools
errors in the vhdl will probably be rather icky
ie, make a typo in there, spec2bit runs and spits out a new file, where the error really comes from as far as xilink is concerned
but that would be true regardless of the mechanism used to get the vhdl to the xilinx tools
""" is pretty easy to understand
user can't figure out where the problem is in his input
yes, the format of the file is fine - I didn't notice that it was all multiline string constants
the header of the generated file (which is what Xilinx will complain about) looks like:
-- AUTOGENERATED FILE - DO NOT EDIT!
-- this file is: myconfig.vhd
-- generated from: myconfig.spec
-- using template: I20HostMot2-in.vhd
-- generated on: 2008-12-03 00:43:41
those strings get included verbatim in the output, right?
ThePinDesc: PinDescType :=
IOPortTag & x"00" & QCountTag & QCountQAPin, -- I/O 00
IOPortTag & x"00" & QCountTag & QCountQBPin, -- I/O 01
so theoretically you could add to that header:
the substitution starts at the :=
-- pindesc starts at line 1009, module_id starts at line 1123
so people can subtract that number (more or less) to get the offset into their "source" file
python has a lib that handles the substitution very nicely, in one or two lines
yeah, regexp :)
finding out where the substitution took place is much more work
see you jepler
source is the source file, substitutions is a dict, dest is the result (header already written with dest.write("stuff")
I bet there's a way of finding out what was substituted and where
but I'm not gonna sweat it right now
the goal of this tool isn't to make it super easy
I wonder if you could give me a quick hal pointer. I can't find anything other than rtapi "cleanup_module" that even comes close to removing HAL objects when a module is removed
you still have to know peter's conventions for module_id and pin_desc - Joe User won't be able to generate a custom config
hal_exit does a little, then calls an RTAPI function, which eventually calls module_cleanup
and I'm fine with that
yeah, it's not simple by any means
ok, changing to hal ;-)
(I was about to call it a night on the other anyway)
just a little, I promise :)
lemme take a look in hal_lib
OK - that's where I started, but I couldn't see it
I figured I'd look for hal_unlink, and there are 4 refernces to that - 2 of them are the function itself and the EXPORT_SYMBOL() for it
hal_lib.c, grep for "free_comp_struct"
it searches the function list for functs belonging to this comp
then calls free_funct_struct()
which checks all threads looking for funct_entries that call that function
I didn't trace that far I guess
and that calls "free_funct_entry_struct()"
bit of a pattern there
funct_entry is not the clearest thing around
a funct_struct defines the function
a funct_entry struct is assocated with a thread, and invokes the function
this needs a pencil
ok, so the bottom line is that it does exactly what I want to avoid, and it does it inline
what are you trying to avoid?
oh, the brute force search?
"for small N, brute force wins"
actually, it would be different anyway, because I need to look at the name, not the comp_id
these functions don't care what the objects are called, only who owns them
N in this case is small - fewer than 5 threads in even an insane system, fewer than 100 functions
I care the other way around
how do I spell printf("%p",p) in C++?
p is a pointer?
say p is a char *
cout << p
if you have streams
otherwise, it's printf("%p", p)
char *p="hello"; cout<<p says hello
oh, right :)
I want it to say 0x12345678, like %p
too funny. cast it to (void *)
cout << (void *)p
message sent to peter w describing what we've been discussing - I'd like his input
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/basic_hal.lyx: remove all function from docs
EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/hal/basic_hal.lyx: note that the all function is depreciated
stupid xilinx install ran out of space overnight even though it said there was enough on this fresh 6GB disk when it started
EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/hal/basic_hal.lyx: remove all
cradek_ is now known as cradek
EMC: 03cmorley 07TRUNK * 10emc2/src/hal/classicladder/drawing.c: switch back to normal colour display because of x windows crash after a long wait
- DynaGcDrawWinColor = gdk_gc_new(pixmap);
looks like the buggy code repeatedly allocated a gc but never freed it
that's my guess, anyhow
EMC: 03jepler 07TRUNK * 10emc2/src/hal/classicladder/ (13 files): fix dos-style line endings; no substantive change intended
hi alex :-)
hey seb, how is everything?
* alex_joni is a bit tired ..
finished doing 40 pounds of sausages :D
eating or making them? :)
I doubt I can ever eat 40 pounds of anything
fenn: making them
[Global Notice] Hi all. One of our client servers is having some connectivity problems. Please keep with us while we investigate. Thanks!