Back
[01:43:30] <jmkasunich2_> seb_kuzminsky: I'm having trouble with hm2_pci
[01:44:00] <jmkasunich2_> if I load it without a "firmware" arg, I get messages in dmesg, but of course it doesn't work
[01:44:24] <jmkasunich2_> if I specify the firmware, I get an error message from insmod:
[01:44:34] <jmkasunich2_> insmod: error inserting '/home/jmkasunich/emcdev/emc2head/rtlib/hm2_pci.ko': -1 Unknown symbol in module
[01:44:44] <jmkasunich2_> nothing in dmesg
[01:44:52] <jmkasunich2_> so I don't know what symbol is wrong
[01:45:59] <jmkasunich2_> same results in 2.2-cvs and trunk
[01:55:29] <jmkasunich2_> ok, operator error (sort of)
[01:56:08] <jmkasunich2_> I was doing "loadrt hm2_pci firmware=foo", I didn't realise you are nesting the actual args inside another string
[01:56:20] <jmkasunich2_> loadrt hm2_pci config="firmware=foo"
[02:05:56] <CIA-42> EMC: 03cmorley 07TRUNK * 10emc2/src/hal/classicladder/files.c: Fix misspelled word so modbus read Registers load properly
[02:07:05] <CIA-42> EMC: 03cmorley 07TRUNK * 10emc2/src/hal/classicladder/classicladder_gtk.c: Change message box to remind that MODBUS will stop running if the GUI is closed
[02:08:22] <SWPadnos> jmkasunich2_, the "Unknown symbol ..." error is due to the fact that we return -1 for almost every error, rather than returning "proper" error codes
[02:11:01] <jmkasunich> SWPadnos: actually, the hm2_pci code isn't even running
[02:11:30] <jmkasunich> insmod is expecting an argument config=something, I gave it firmware=something
[02:11:38] <SWPadnos> but if it returns -1, the module loader will print "Unknown symbol in module" as the error
[02:11:39] <jmkasunich> so the missing variable is "config"
[02:11:55] <SWPadnos> if it returned -2, modprobe would print something else
[02:12:07] <jmkasunich> what is "it"?
[02:12:18] <SWPadnos> the module loader is what prints that message into dmesg
[02:12:49] <CIA-42> EMC: 03cmorley 07TRUNK * 10emc2/src/hal/classicladder/config_gtk.c: Add Radio buttons for mapping of MODBUS read/write registers
[02:12:51] <SWPadnos> when the module init code returns -1, the module loader sees that as an "Unknown symbol" error, and prints that
[02:12:58] <jmkasunich> what code do you think should be returning something different?
[02:13:06] <SWPadnos> rtapi_app_main
[02:13:13] <SWPadnos> (ie, module init code)
[02:13:20] <jmkasunich> that code is never running
[02:13:26] <SWPadnos> oh, ok ;)
[02:13:58] <SWPadnos> that's just the code that always gets returned in case of any init error, so most messages look like that
[02:14:02] <jmkasunich> if "config" isn't found, the loader won't load the module
[02:14:05] <SWPadnos> ah, okj
[02:14:10] <SWPadnos> ok
[02:29:25] <cradek> hm, in the last week, someone broke s32in in classicladder
[02:29:29] <cradek> wonder if it was me...
[02:36:42] <CIA-42> EMC: 03cmorley 07TRUNK * 10emc2/src/hal/classicladder/serial_linux.c: Fix compiler warning
[02:39:04] <cradek> Created new variables IW and QW to represent S32 in and out pins instead of mapping them to W variables. Defaults to ten of each. Aligns us with mainsteam Classicladder. ladder programs will need to be updated, HAL files will be fine
[02:39:08] <cradek> duh
[02:39:22] <cradek> rtfl
[02:58:11] <jepler> yay, problem solved!
[03:10:52] <SWPadnos> hmmm. I wonder if I can get the 5i20 to run the G540
[03:12:48] <SWPadnos> I'd probably have to jumper it for 5V, which is a PITA since there are 15 screws between me and the card, so maybe I'll leave that for another day
[03:18:08] <seb_kuzminsky> cradek: yes please use hm2_pci instead of hm2_5i20
[03:18:21] <seb_kuzminsky> jmkasunich: that error message could be clearer
[03:18:37] <seb_kuzminsky> in fact, hm2 configuration in general could be clearer...
[03:19:03] <seb_kuzminsky> cradek: the hm2_5i20 driver supports the 5i20 and the 4i65 (pc/104-plus version of 5i20)
[03:19:19] <seb_kuzminsky> the hm2_pci driver supports all the pci and pc/104-plus anyio boards
[03:19:47] <seb_kuzminsky> hm2_5i20 just has a bad name, not bad code ;-)
[03:21:58] <seb_kuzminsky> SWPadnos: the G540 wont step on 3.3V signals?
[03:26:56] <jepler> seb_kuzminsky: who knows, it doesn't seem to be specified in the manual.
http://www.geckodrive.com/upload/G540%20REV3%20MANUAL.pdf
[03:28:39] <seb_kuzminsky> specs, who needs 'em
[03:29:24] <jepler> "when you plug it into a computer running mach, it seems to work" </spec>
[03:31:02] <seb_kuzminsky> the g540 contains four g250's, which are advertised to work with 3.3V inputs
[03:31:05] <seb_kuzminsky> http://www.geckodrive.com/product.aspx?c=3&i=14472
[03:31:06] <jepler> (the g250, on which the g540 is said to be based, ... yes)
[03:31:14] <seb_kuzminsky> "3.3V and 5V logic compatible inputs"
[03:31:18] <jmkasunich> seb_kuzminsky: if I want to move things around on a 5i20, I need to rebuild the firmware, right?
[03:31:27] <seb_kuzminsky> jmkasunich: yes
[03:31:31] <seb_kuzminsky> or ask peter to
[03:31:34] <jmkasunich> I'd like to have stepgens and hw encoder counting on one connector
[03:32:35] <jmkasunich> what are the differences between hm2 in trunk, and in 2.2 (in a nutshell)?
[03:32:54] <seb_kuzminsky> i asked peter about putting a big switch between the modules and the iopins, but he said it took too many gates
[03:33:00] <seb_kuzminsky> maybe it could be done on the 5i22
[03:33:16] <seb_kuzminsky> um, hm2 on 2.2.7 and trunk are really similar
[03:33:18] <jmkasunich> 72x72 is a big honkin switch
[03:33:28] <seb_kuzminsky> 96x96 on the 5i22
[03:33:34] <seb_kuzminsky> trunk has better encoder velocity
[03:33:45] <seb_kuzminsky> i think that's it, hold on i'll check
[03:34:01] <seb_kuzminsky> brb
[03:37:00] <seb_kuzminsky> trunk has better logging like we talked about, not all hidden down in WARNING, INFO, and DEBUG
[03:37:16] <jmkasunich> IOW, minor details, no major differences
[03:37:22] <seb_kuzminsky> ah yes, trunk has the glitch-free encoder index
[03:37:31] <jmkasunich> maybe some pin naming differences?
[03:37:51] <seb_kuzminsky> right, the connector name was removed from the HAL representation of the gpios
[03:38:23] <jmkasunich> I'm working my way up to converting my actual machine, right now it's on 2.2
[03:39:39] <jmkasunich> there is xilinx.mk in the firmware directory, but it doesn't look like the right thing
[03:40:00] <jmkasunich> for one thing, it seems to have .bit files as targets, all the released ones are .BIT
[03:40:29] <seb_kuzminsky> i really dont know much about the firmware side of things, that's all peter's domain
[03:40:44] <jmkasunich> that makefile resembles something I was working on
[03:41:05] <jmkasunich> did you copy and tweak it? or did peter give it to you?
[03:41:33] <seb_kuzminsky> the firmware stuff is all peter's, i haven't read it, much less written to it ;-)
[03:42:23] <seb_kuzminsky> i think jepler got the hm2 firmware to compile
[03:42:43] <seb_kuzminsky> one thing i'd love to set up is a hm2 firmware compiler robot
[03:43:00] <seb_kuzminsky> poke what you want into a web form, it runs the compiler and emails you the .BIT and .PIN
[03:43:09] <jmkasunich> I have a fairly fast machine, and the xilinx tools are already installed here
[03:43:20] <seb_kuzminsky> cool
[03:44:18] <jmkasunich> ah, jeff committed that makefile - he must have started with mine
[03:44:31] <jmkasunich> (I recognise some of my comments)
[03:45:10] <SWPadnos> oh hmm, I could try it on 3.3V couldn't I
[03:46:04] <seb_kuzminsky> SWPadnos: i think it should just work
[03:46:15] <SWPadnos> yeah, it may - I
[03:46:19] <SWPadnos> I'll see
[03:46:48] <SWPadnos> the real PITA (for the Mesa) is that it uses a DB25 female connector for input
[03:47:13] <SWPadnos> so I have to make a cable if I'm curious enough
[03:47:39] <jmkasunich> you need a 50 pin breakout and a db25 breakout, and some wires ;-)
[03:47:56] <SWPadnos> hmmm. I've probably got that :)
[03:48:25] <seb_kuzminsky> cabling is usually most of the hassle
[03:49:45] <jmkasunich> I wonder what the top level vhdl file is named?
[03:49:51] <SWPadnos> it sure was this time. DB25 M-M cables aren't all that common
[03:50:40] <SWPadnos> I went to 5 stores looking for one, then realized that a 6" cable I already have (which had its ends wrapped in foam, so I didn't see it when I searched) was the right one
[03:50:55] <seb_kuzminsky> but gender changers are pretty common, no?
[03:50:58] <SWPadnos> no
[03:51:07] <SWPadnos> DB25, no. DB9, maybe
[03:51:18] <SWPadnos> Radio Shack had DB9, but not DB25
[03:52:05] <seb_kuzminsky> somewhere along the way i ended up with a big bag of gender changers, db9 & db25, mm & ff, so it hasnt been an issue for me for a while :-)
[03:52:27] <seb_kuzminsky> i'll email you one
[03:52:30] <SWPadnos> I have about 500 DB25-DB9 adapters, if you ever need any ;)
[03:52:38] <SWPadnos> heh, thanks :)
[03:52:55] <jmkasunich> I have a black-box widget with two sets of male and female 25-pin connectors, switches to connect or disconnect pins, and leds on every pin
[03:53:10] <jmkasunich> trashpicked it, haven't used it in quite a while
[03:53:23] <jmkasunich> I think it might be designed for serial tho
[03:53:38] <seb_kuzminsky> appropos: Thingiverse, "a place to share digital designs that can be made into real, physical objects",
http://www.thingiverse.com/
[03:53:39] <SWPadnos> I'm sure it's exceedingly useful about once every 2 years
[03:57:33] <jmkasunich> I think pete must use an editor with 3-space tabs
[04:03:15] <seb_kuzminsky> at some point we should have a conversation with peter about maintenance of the hostmot2 firmware source code
[04:03:39] <jmkasunich> yeah - at a minimum the readme should tell you how to use the makefile
[04:03:39] <seb_kuzminsky> pcw occasionally emails me tarballs, and i unpack them in my emc2 sandbox and commit them
[04:04:05] <seb_kuzminsky> he doesnt use revision control on his end, maybe he could use our tree?
[04:04:19] <jmkasunich> sooner or later someone from EMC is going to find a bug - that channel needs to work both ways so we can pass fixes on to peter
[04:04:28] <seb_kuzminsky> i'm just worried if we start tweaking it that we'll all get out of sync and have a hard time working together
[04:04:32] <jmkasunich> (find a bug or write a new module - I hope to do the latter)
[04:04:38] <seb_kuzminsky> jmkasunich: yes
[04:05:18] <jmkasunich> jepler: are you lurking around?
[04:05:48] <SWPadnos> AFAIK, the code he sticks in his stuff isn't GPL, so sending him code would probably need a non-GPL license so he could stick it in his stuff
[04:05:54] <seb_kuzminsky> jmkasunich: you saw jeff's notes on the wiki, right?
[04:05:56] <seb_kuzminsky> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?BuildingHostmot2
[04:06:03] <jmkasunich> no, thanks
[04:06:55] <seb_kuzminsky> it should be fairly easy to set up the buildbot to compile the firmware along with everything else
[04:07:05] <cradek> seb_kuzminsky: if hm2_5i20 is deprecated you could just remove it on trunk
[04:07:33] <seb_kuzminsky> i'm planning to remove it in january
[04:07:36] <cradek> that would be a lot of encouragement for to use the new one
[04:07:37] <cradek> ok
[04:10:06] <jmkasunich> those wiki instructions are for using the GUI
[04:10:36] <jmkasunich> jeff is the one who committed the makefile - I wish I knew how he got it to work (specifically, what target I should ask for)
[04:11:34] <jmkasunich> you can request a .bit for any .vhd, but the process will only work if you choose a valid top-level vhd file
[04:11:43] <jmkasunich> and it isn't at all clear what file that is
[04:12:13] <CIA-42> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/hm2_5i20.c: warn about the imminent removal of hm2_5i20 from TRUNK
[04:13:10] <SWPadnos> jmkasunich, I20HostMot2.vhd, I think
[04:13:19] <jmkasunich> thats what I tried
[04:13:24] <SWPadnos> oh
[04:13:28] <jmkasunich> ERROR:Xst:1817 - Invalid target No Default data
[04:13:29] <SWPadnos> I
[04:13:45] <SWPadnos> ah, ok - you have no chip specification
[04:13:59] <jmkasunich> there has to be some FM involved, somehow peter tells it what combo of stuff to build
[04:15:07] <seb_kuzminsky> i'm out for the night
[04:15:15] <jmkasunich> I should be too
[04:15:16] <jmkasunich> goodnight
[04:15:27] <seb_kuzminsky> jmkasunich: maybe mail peter and ask? it'd be good to start the conversation about source code mods with him
[04:15:46] <seb_kuzminsky> goodnight guys
[04:15:51] <jmkasunich> does he read his email on weekends?
[04:16:09] <SWPadnos> jmkasunich, are you on TRUNK, in the meas-hostmot2/firmware dir?
[04:16:12] <SWPadnos> mesa
[04:16:18] <jmkasunich> SWPadnos: yes
[04:16:21] <SWPadnos> ok
[04:17:24] <jmkasunich> it's kind of odd that the makefile isn't in the src directory
[04:18:46] <SWPadnos> I think if you can get the command-line foo that tells ISE what chip you want, that I20HostMot.vhd is the correct file
[04:20:03] <jmkasunich> this is a makefile, I don't see how I'd pass that into make
[04:20:45] <SWPadnos> yeah, it's only necessary for the final place & route anyway (or should be)
[04:22:17] <jmkasunich> I used a trick to store that info in the vhdl when I was messing with makefiles
[04:22:43] <jmkasunich> I wonder if jeff was using my tricks three months ago when he commited the makefile, and peter's newer vhdl broke it
[04:22:49] <jmkasunich> * jmkasunich checks cvs history
[04:23:37] <jmkasunich> this is not encouraging
[04:23:46] <jmkasunich> jeff committed a working makefile in August
[04:24:01] <jmkasunich> Seb did the 1.1 commit of the current vhdl in September
[04:25:06] <jmkasunich> I absolutely hate the Xilinx GUI
[04:25:17] <cradek> jmkasunich: I think peter W works continuously
[04:25:25] <jmkasunich> there are no words to describe my loathing for that piece of crap
[04:26:01] <jmkasunich> cradek: you mean he's a constantly moving target?
[04:26:36] <cradek> no I mean I think he's always doing work stuff
[04:26:40] <SWPadnos> the hostmot2_import.tcl file is the only one that makes any mention of the chip (and it's for the 5i22 at the moment)
[04:27:24] <SWPadnos> there's mention of a .spec file in the makefile, but there are none in the src/ directory
[04:28:39] <jmkasunich> that tcl thing supposedly contains "information contained in the project file"
[04:28:49] <jmkasunich> the makefile generates a .prj file
[04:28:52] <SWPadnos> yes, it's the import script to re-create the project
[04:29:29] <jmkasunich> "the project" - wtf is that? a file, a directory tree? I hate IDEs!
[04:29:39] <SWPadnos> it's like a makefile ;)
[04:29:46] <cradek> jmkasunich: told you so
[04:30:16] <SWPadnos> heh
[06:12:59] <CIA-42> EMC: 03cmorley 07TRUNK * 10emc2/src/hal/classicladder/protocol_modbus_master.c: Fix mistakes when mapping variables to MODBUS
[06:48:37] <CIA-42> EMC: 03cmorley 07TRUNK * 10emc2/src/hal/classicladder/ (classicladder_gtk.c classicladder_gtk.h): Changes to add message box warning when resetting a running ladder program and change a couple other message boxes
[13:21:43] <CIA-42> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/install/images/latency.png: add graphic file
[13:23:54] <CIA-42> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/install/Latency_Test.lyx: add file
[13:25:44] <CIA-42> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/common/Getting_EMC.lyx: add info about upgrading Ubuntu
[13:28:26] <CIA-42> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/Master_Integrator.lyx: add file
[13:32:41] <CIA-42> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/install/Latency_Test.lyx: add info on finding a parallel port card address
[16:12:54] <CIA-42> EMC: 03tissf 07TRUNK * 10emc2/docs/src/install/Latency_Test_fr.lyx: french translation update
[17:59:38] <jmkasunich> jepler: I'd like to talk to you about xilinx makefiles when you have a few minutes
[18:24:11] <jmkasunich> some specific questions about your xilinx.mk:
[18:24:23] <jmkasunich> 1) why xilinx.mk and not just Makefile
[18:24:33] <jmkasunich> 2) why in the firmware directory instead of the src directory
[18:26:47] <jepler> jmkasunich: xilinx.mk was a combination of your makefile and something I found on another website. ".mk" seems to be a standard for things included from Makefiles to specify how to build targets. I'm not sure why I put it where I put it; I think I was thinking about including it from each different firmware directory.
[18:27:10] <jepler> that's about all I remember :-P
[18:27:15] <jmkasunich> ok, so it isn't/wasn't intended to be a standalone makefile
[18:28:08] <jmkasunich> maybe that explains "@for i in $(SOURCES); do echo $$i; done > $@"
[18:28:17] <jmkasunich> because I don't see anything that sets SOURCES
[18:28:28] <jmkasunich> (that line is part of the .prj target)
[19:01:33] <jepler> exactly
[19:01:47] <jepler> I think the makefile that actually used it may have been removed one of the times seb got a new firmware from peter
[19:02:12] <jmkasunich> so I should go looking in the attic for it
[19:02:34] <jmkasunich> I want to see how you were setting SOURCES
[19:07:51] <jmkasunich> found it
[19:16:33] <jmkasunich> not much to that
[19:16:56] <jmkasunich> seems like it would be nice to be able to generate SOURCES automatically
[19:17:31] <jepler> yeah
[19:17:54] <jepler> $(wildcard *.v) will list all the verilog files in the directory, but that's not what you want
[19:18:05] <jmkasunich> if foo.vhd has "use work.bar" in it, then foo depends on bar
[19:18:43] <jmkasunich> I think I was doing some dependency generation stuff before
[19:18:55] <jmkasunich> I didn't comment enough tho, a year later it's all greek to me
[19:19:58] <jepler> In verilog (.v) here's a line that means that wdt.v is also used to compile this firmware: wdt w(clk, do_enable_wdt, &div2048, do_tristate);
[19:20:28] <jepler> that's the only instance of the 'wdt' identifier in the source file
[19:20:49] <jepler> the compiler knows enough about the structure of the language to know that at that spot there can only be a declaration, I guess
[19:20:50] <jmkasunich> in vhdl, it is the use statement
[19:20:59] <jepler> so there's not a keyword for it in verilog
[19:21:02] <jepler> there is in vhdl
[19:21:12] <jmkasunich> fortunately verilog doesn't matter, Peter uses VHDL
[19:21:15] <jepler> makes it harder for a parser that doesn't know a substantial chunk of verilog to figure it out
[19:21:25] <jepler> oh he does? my mistake, then, for this silly detour
[19:21:29] <jmkasunich> heh
[19:21:55] <jmkasunich> grep "use *work" I20HostMot2.vhd
[19:21:55] <jmkasunich> use work.IDROMParms.all;
[19:21:55] <jmkasunich> use work.NumberOfModules.all;
[19:21:55] <jmkasunich> use work.MaxPinsPerModule.all;
[19:22:33] <jmkasunich> if I omit the "work" part, I get system libs as well as local ones, which I don't want
[19:23:03] <jmkasunich> I'm trying to figure out (again) how to handle the recursion in a makefile
[19:23:28] <jmkasunich> if I'm trying to make foo.bit, first I find the dependencies of foo.vhd, then I find the dependencies of each of those dependencies, etc
[19:25:09] <jmkasunich> duh, I bet the "makefile.vhd.dep" target has something to do with that
[19:25:16] <jepler> you make BASE.o depend on BASE.t, BASE.t depend on USED.t, and %.t depend on %.vhd
[19:25:24] <jepler> and, yes, you generate that into makefile.vhd.dep
[19:25:34] <jepler> from all vhd files, regardless of whether they're actually used
[19:26:09] <jmkasunich> I wonder why you didn't keep that part when you copied the rest of the makefile?
[19:26:19] <jepler> ummmmm
[19:26:41] <jepler> I may have just not taken the time to understand it
[19:26:59] <jmkasunich> right now I don't understand it either, guess it needs some review
[19:27:17] <jepler> 'echo | sed | sed | sed' doesn't make for the easiest-to-read code
[19:27:40] <jmkasunich> yeah, I'm gonna either rewrite it or comment it heavily
[19:28:26] <jmkasunich> figure out what it does, document that, then figure out if there is a better way to do it
[19:32:15] <jepler> there are probably lots of different ways to do it
[19:33:13] <jmkasunich> what would you use? python?
[19:39:01] <jepler> oh of course
[19:43:15] <jepler> one other thing I'd do is try to find out if there's a way to get a program that actually parses vhdl to produce the dependency list
[19:43:25] <jepler> rather than doing it with ad-hoc regular expressions, no matter what the language
[19:45:23] <jmkasunich> like
http://www.ht-lab.com/freeutils/vhdlsort/vhdlsort.html maybe...
[19:47:28] <jmkasunich> hmm, some forum thread says that emacs has a vhdl mode (why am I not really surprised?)
[20:05:55] <jmkasunich> vhdlsort is binary only "freeware", screw that
[20:06:25] <jmkasunich> besides, if I read the docs right, it doesn't figure out what files are needed, it simply sorts a list of files you give it
[20:06:44] <jmkasunich> ah-hockery here we come
[20:29:18] <jepler> oh, I remember now why verilog was relevant: the provenance of that xilinx.mk is from a project of my own, which did use verilog
[20:29:30] <jepler> I half-adapted it back to hostmot2, but had lost the dependency-generating code
[20:30:08] <jmkasunich> it turns out that dependency generation is more complex than I thought
[20:30:27] <jmkasunich> "use" is not the only way that a dependency can be expressed
[20:31:57] <jmkasunich> last year I was using a coding convention that did express everything in a use, but peter isn't doing that anymore
[20:32:10] <jmkasunich> "entity foo is" in a file means that this file defines foo
[20:32:34] <jmkasunich> "bar : entity foo" in a file means that this file uses foo
[20:33:06] <jmkasunich> definitely a task for python, for each file I can have a list of things it defines and things it uses
[20:33:51] <SWPadnos> it may be in some docs that any files in the working directory are considered "usable", without a USE statement
[21:06:18] <alex_joni> jmkasunich: I'm not entirely sure what you want to "fix"
[21:06:54] <jmkasunich> I want to be able to build bitfiles from the source in CVS, using the command line
[21:07:09] <alex_joni> do you expect that to happen frequently?
[21:07:47] <alex_joni> (probably not a right question, so feel free to ignore it :)
[21:07:55] <jmkasunich> I know I could do the vhdl dependencies manually
[21:07:59] <jmkasunich> but I don't want to
[22:06:38] <alex_joni> good night all
[23:31:26] <jepler> jmkasunich: I wholeheartedly want that too
[23:51:35] <jmkasunich> well, I got the parsing working
[23:54:52] <jmkasunich> trying to think of how to process the data
[23:56:56] <jmkasunich> dicts I think
[23:58:00] <jmkasunich> provides = { 'entity-name' : 'file-that-provides-entity', more-of-the-same }
[23:58:07] <jmkasunich> and
[23:58:35] <jmkasunich> hmm, "needs" isn't a simple 1:1 mapping