Back
[07:20:40] -barjavel.freenode.net:#linuxcnc-devel- [freenode-info] channel flooding and no channel staff around to help? Please check with freenode support:
http://freenode.net/faq.shtml#gettinghelp
[07:38:02] <KGB-linuxcnc> 03jepler 05master 77c8fc2 06linuxcnc 10src/hal/classicladder/drawing.c * classicladder: cast to double to do FP arithmetic on integers
[07:38:02] <KGB-linuxcnc> 03jepler 05master 071f36c 06linuxcnc 10src/hal/user_comps/mb2hal/mb2hal.c * mb2hal: compute timeouts with integer math
[07:38:05] <KGB-linuxcnc> 03jepler 05master 602204c 06linuxcnc 10src/hal/user_comps/vfs11_vfd/vfs11_vfd.c * vfs11_vfd: don't needlessly cast
[13:55:02] <andypugh> does rtapi_print understand the %llx format from printk?
[13:57:51] <andypugh> I am a bit puzzled by the result of printing the initial value of an s64 variable with %llx then setting it to 0, then printing it again giving the exact same non-zero (and only 26 bits long) number both before and after setting the value.
[14:02:41] <awallin> andypugh: here's some code for printing 64bit numbers
http://www.ohwr.org/projects/wrpc-sw/repository/revisions/master/entry/monitor/monitor.c#L29
[14:02:55] <awallin> (from a completely unrelated project, but anyway)
[14:03:33] <andypugh> I guess that is one way :-)
[14:03:52] <andypugh> I thought that 64-bit printing was included in printk though
[14:04:16] <andypugh> http://www.mjmwired.net/kernel/Documentation/printk-formats.txt
[14:04:54] <awallin> elsewhere I've used also: printf( "WR-time : %" PRId64 ".%09d \n", utc_seconds, nsecs);
[14:05:09] <awallin> which requires #include <inttypes.h>
[14:15:06] <andypugh> As far as I know rtapi_print uses a subset of printk, which rather limits what I can do.
[14:17:21] <jepler> andypugh: yeah I don't think you can use ll or L specifiers in rtapi_print_msg et al
[14:17:54] <andypugh> This gets stranger by the moment...
[14:18:01] <jepler> that's why my mail recommended getting the low and high halves for separate inspection
[14:18:24] <andypugh> That is what I am doing. I am seeing high-order bits.
[14:18:55] <andypugh> I was seeing non-zero values at init time, but that stopped, and the run-time values made sense for a while.
[14:19:23] <andypugh> Then the init-time values continued to make sense, but the run-time ones went crazy again.
[14:21:15] <andypugh> The problem actually seems to be the old_pos. (which is in code you haven't seen).
[14:22:53] <andypugh> I had that as a u32, but things work better with s32. But I think that the data in the Mesa registers is always raw-bits, so technically u32. But to complicate matters the underlying data is arbitrary bit-length and gray-coded.
[14:26:15] <jepler> when using shift operators there are differences in how signed and unsigned types work
[14:27:57] <jepler> for instance, for(int i=1; i; i<<=1) is undefined behavior and gives an infinite loop in some incarnations of gcc
[14:28:19] <jepler> I have no reason to believe that specific example is related to what you're seeing
[14:48:10] <jepler> heck, even just wrapping around from negative to positive again is undefined on signed integers
[14:48:37] <jepler> maybe we should turn on -fno-strict-overflow where applicable (probably everywhere) because it returns some of these things to the state we expect
[14:49:37] <andypugh> Hmm, I wish I fully understood the complexities.
[14:50:30] <andypugh> I am trying to decide how to handle the fact that there may be multiple fields in the bit stream.
[15:52:39] <jepler> andypugh: I don't have any specific advice though a blog I follow has recently been discussing dealing with foreign bitfields in C .. first of 2+ parts:
http://jeelabs.org/2013/09/05/decoding-bit-fields/
[15:53:31] <andypugh> jepler: Are you on the other channel too? I am discssing a format specifier there with PCW
[15:53:42] <jepler> I never pay attention over there..
[15:59:47] <andypugh> jepler: As a point of style. The code to extract the bits is likely to be extemely simiar to the code that handles the smart-serial 96-bit bitfields. Does it make more sense to copy the smart-serial code, or to use the same code?
[16:00:22] <jepler> if you can arrange to use the same code twice (not copy & paste) that's a win
[16:02:54] <andypugh> OK. I guess that re-using the same catch-all data type is going to be handy too.
[16:04:25] <andypugh> I have a feeling that sserial_pin_t (in sserial.h) should really have been a Union, though I can't imagine that there is much overhead in a struct of pointers only one of which ever gets initialised.
[16:05:44] <andypugh> Why do I end up writing so many polymorphic components?
[16:06:04] <jepler> because it's less time consuming than writing a million components that don't adapt?
[16:06:39] <andypugh> Well, yes, but nobody else really seems to try.
[16:06:58] <jepler> seb certainly did when he made the hm2 drivers...
[16:07:09] <jepler> but I certainly haven't done it to anything like the extent you have
[16:08:36] <andypugh> I certainly seem to be exploring the boundaries of "comp" that's for sure. (Which is a marvellous tool)
[16:09:02] <jepler> at some point I assume you'll have had enough and fix it to do what you need
[16:09:18] <jepler> <1/2 wink>
[16:09:25] <andypugh> I would need to learn Python first :-)
[16:10:09] <jepler> you've had years!
[16:10:37] <andypugh> One handy option, though, would be to be able to alias "Personality". I think it would still be called "Personality" in the code, but would be a different name as a modparam an in the docs.
[16:10:58] <andypugh> Yeah, but I am only about 42% of the way through learning C!
[16:14:16] <andypugh> This SSI encoder stuff was intended to be a quick and easy thing to get me back into the swing of coding after a hiatus (of actually working with hardware) to then move back on to Tool Table stuff (in Python, mainly) But is has proven to be rather complex.
[16:15:46] <jepler> :-/
[16:19:18] <andypugh> Hmm, and now I am wondering if I need to re-structure sserial so that I can re0use the code....
[16:20:08] <andypugh> First I reckon I will see how I get on with making an SSI device look _exactly_ like a smart-serial.
[16:21:31] <andypugh> There is a precendent for this, if you look in sserial.h you will find two dummy config roms for devices that pre-dated the config rom.
[16:23:33] <jepler> I'm not going to second-guess you about that
[16:25:00] <andypugh> Well, _first_ I need to make a patch for the people who want SSI _now_
[21:25:04] <kwallace1> It looks like for BBB there is a component [PRUCONF](Driver) that has functions in it for stepgen, pwm and others? Then a GPIO component for setting pins. How does one figure out how the physical pins are mapped?
[21:28:00] <kwallace1> I guess the GPIO is set according to this:
http://letsmakerobots.com/files/userpics/u19048/B_3PinOut3.png
