**** BEGIN LOGGING AT Thu Feb 07 02:59:57 2019 Feb 07 03:00:48 https://www.st.com/content/ccc/resource/technical/document/application_note/b9/9b/16/3a/12/1e/40/0c/CD00167594.pdf/files/CD00167594.pdf/jcr:content/translations/en.CD00167594.pdf Feb 07 03:01:03 this document describes the UART flashing sequence Feb 07 03:01:13 see page 36 for the cape chip Feb 07 03:01:18 learning how to reflash some random microcontroller you don't actually develop for is not a useful skill unless you have a specific need to reflash it Feb 07 03:01:46 if you do want to develop for the stm32 (for whatever reason), get a cheap stm32 dev board Feb 07 03:01:59 he said he wanted to fix the cape, but I don't know if he meant the cape itself or its user library on the BBB side Feb 07 03:02:05 fix in what sense? Feb 07 03:02:23 [03:07:48] But...this Cape has given the community trouble in the past. Feb 07 03:02:23 [03:08:15] I wanted to try to give the Motor Bridge Cape a new lease on life. Feb 07 03:03:12 I don't recall there being any problems with the firmware Feb 07 03:04:50 set_: what trouble are you talking about, concretely? Feb 07 03:07:39 I thought of libraries used on this Cape. Feb 07 03:07:52 Adafruit_BBIO right? Feb 07 03:08:43 their python lib is broken but that was a 2-line fix, which I sent to them a year ago ( https://github.com/Seeed-Studio/MotorBridgeCapeforBBG_BBB/issues/6 ) and has been ignored ever since Feb 07 03:08:49 that has nothing to do with the firmware on the cape Feb 07 03:09:17 I understand Feb 07 03:09:18 ah they did fix it Feb 07 03:09:28 Yes but it does not work. Feb 07 03:09:33 just didn't bother closing the issue Feb 07 03:09:38 what's the problem? Feb 07 03:10:11 I had to resort back to Adafruit_BBIO --version 1.0.3 and... Feb 07 03:10:32 The issue was w/ another adafruit repo that was not available any longer. Feb 07 03:10:46 it should work with the latest version Feb 07 03:11:09 Adafruit_GPIO used another repo and that repo is no longer viable. Feb 07 03:11:52 zmatt: Do you have the BBB and Motor Bridge Cape? Feb 07 03:12:15 regardless, issues with their python library need to be fixed in their python library. being able to reflash the firmware is of absolutely zero use for solving this problem Feb 07 03:12:18 no Feb 07 03:12:19 I get errors. Always did. I just downgraded to --version 1.0.3 instead of using 1.0.10. Feb 07 03:12:33 Okay. Feb 07 03:12:35 No issue. Feb 07 03:12:38 please use the latest versions and pastebin the error you get Feb 07 03:12:51 Okay. Please hold. Feb 07 03:13:31 I will set up that board w/ the Cape on it and run the software example w/ the library as you have it stated w/ the I2C stuff. Feb 07 03:13:37 It may take a while. Feb 07 03:14:12 I need to get that board and update the --version of Adafruit_BBIO to 1.0.10 and change the library. Feb 07 03:16:20 man. That beef stew was good. I am surprised. Feb 07 03:16:30 The board is booting now. Feb 07 03:17:12 latest version is 1.1.1 btw Feb 07 03:17:33 Okay. Feb 07 03:21:30 I changed the software in the library for MotorBridge.py. Adafruit_BBIO is updating now. Feb 07 03:21:34 upgrading... Feb 07 03:22:14 Now...I will run the software soon but first I need to get the repo for Adafruit_GPIO right? Feb 07 03:22:19 and install it? Feb 07 03:25:46 https://pastebin.com/XVQZvqU8 is w/out installing Adafruit_GPIO. Feb 07 03:26:06 Let me show you what happens when the Adafruit_GPIO is installed. Feb 07 03:27:38 Please hold. I am updating. This takes a while now for some reason. Feb 07 03:28:05 I guess we lessened boot times for update times? Feb 07 03:28:24 I have noticed that the boards are booting quickly now. Feb 07 03:33:20 https://pastebin.com/6mqQze5E is the issue w/ installing the Adafruit_GPIO from then until now. It is still the same. Feb 07 03:34:45 reboot! Feb 07 03:35:32 I should have the necessary files once this reboot happens. Feb 07 03:36:20 can I modify the device tree on runtime ? Feb 07 03:36:32 like just change a status = "disabled"; to status = "okay"; Feb 07 03:36:34 set_: https://github.com/mvduin/MotorBridgeCapeforBBG_BBB Feb 07 03:36:40 so that a loaded driver will recognize its peripheral Feb 07 03:36:47 not do fancy things Feb 07 03:37:00 set_: see if that works with python3 if you pip3 install Adafruit_GPIO Feb 07 03:37:02 I don't remember if that's still possible or not, you said it is deprecated Feb 07 03:38:00 mawk: you can try using the utils in the bin directory of my overlay-utils project, they might still work Feb 07 03:38:13 ah, nice Feb 07 03:40:24 set_: I attempted to pip3 install Adafruit_BBIO but that lib seems to be too broken Feb 07 03:40:36 set_: so I replaced it with pure python code Feb 07 03:40:37 Okay. Feb 07 03:40:48 based on my very limited local testing, it seems to work Feb 07 03:40:51 I tried Adafruit_GPIO and it failed. Feb 07 03:41:00 I used pip to install it. Feb 07 03:41:05 I mean git clone. Feb 07 03:41:14 pip3 install Adafruit_GPIO worked for me Feb 07 03:41:28 and its I2C module appears to work Feb 07 03:41:35 which is the important part Feb 07 03:41:51 these libs are interchangeable anyway, no ? Feb 07 03:41:56 Right but git clone adafruit_GPIO and Adafruit_BBIO are not the same repo. Feb 07 03:42:08 you can get a one that doesn't require patching by end users and plug that into the library Feb 07 03:42:09 mawk: totally different libs Feb 07 03:42:21 no I mean adafruit_gpio and wiringpi for instance Feb 07 03:42:28 set_: don't git clone either, just pip3 install adafruit_GPIO Feb 07 03:42:29 if the first doesn't work you can substitute for the second Feb 07 03:42:34 Okay. Feb 07 03:43:00 well I say wiringpi but that's for raspberry pi I guess; but I'm sure there are others Feb 07 03:43:06 set_: and my modified version of the MotorBridge module no longer requires Adafruit_BBIO Feb 07 03:43:10 only Adafruit_GPIO Feb 07 03:43:25 I saw that. Feb 07 03:43:39 So, we just need i2c for communicating. Feb 07 03:43:46 Over UART? Feb 07 03:43:48 yes and that part seems to work Feb 07 03:43:53 ehm, i2c is i2c Feb 07 03:43:55 Okay. Feb 07 03:43:57 Got it. Feb 07 03:43:58 uart is not used Feb 07 03:44:04 Oh. Okay. Feb 07 03:44:16 I must have missed that section. Feb 07 03:44:40 this is awful code btw Feb 07 03:44:44 Yea, you are right. Feb 07 03:45:49 Heh? Feb 07 03:46:08 I am having fails for building. Feb 07 03:46:21 for building what/ Feb 07 03:46:21 Okay. I have it now. Feb 07 03:46:28 Adafruit-GPIO. Feb 07 03:46:43 sudo apt-get install python3-dev Feb 07 03:46:44 -v 1.0.3 Feb 07 03:46:54 what? Feb 07 03:46:57 It is already the newest version. Feb 07 03:47:13 ok Feb 07 03:47:15 Adafruit-GPIO --version 1.0.3. Feb 07 03:47:21 yes that's the latest version Feb 07 03:47:24 Okay. Feb 07 03:51:26 So, I have GPIO as not being defined. Feb 07 03:51:33 Let me show you the output. Feb 07 03:52:29 https://pastebin.com/jWHALfcE is what I have as output. I changed HIGH to LOW for no reason. Feb 07 03:52:59 you're not using my version Feb 07 03:54:18 Please hold. Let me check what happened. Feb 07 03:54:20 Oh. Feb 07 03:54:29 what happened is that you didn't use my version Feb 07 03:54:36 I got you. Let me get that version. Feb 07 03:56:34 I think it was a bad idea to hotplug my driver Feb 07 03:56:40 [26896.973441] Unable to handle kernel NULL pointer dereference at virtual address 00000020 Feb 07 03:57:06 why expose bind/unbind in sysfs if it's not able to do it; it was a temptation Feb 07 03:57:44 mawk: that just means your driver is buggy :P Feb 07 03:58:04 lol Feb 07 03:59:28 it's still the same module, mrf24j40 from mainline Feb 07 03:59:32 I did not even edit it Feb 07 04:00:07 Okay so, right now! The software I have runs. It ran anyway but now it is in an ongoing loop. Feb 07 04:00:18 The software has not stopped yet. Feb 07 04:00:28 set_: what are you running? Feb 07 04:00:35 does not simply have an infinite loop? Feb 07 04:00:35 Please hold. Feb 07 04:00:50 I thought my software ran and completed/ended. Feb 07 04:00:55 It used to end. Feb 07 04:01:01 pastebin? Feb 07 04:01:04 Please hold. Feb 07 04:01:54 I got what happened. I had it on time.sleep for 100 milliseconds. Feb 07 04:02:35 I must had did that to have time to turn the switch on the Cape to standby. Feb 07 04:02:43 okay glad to hear the module now works. I need to pay attention to other stuff now I'm afraid Feb 07 04:02:51 Coolness! Feb 07 04:02:56 Good luck w/ your other stuff. Feb 07 04:28:15 I'm doing my kvm client in C++ Feb 07 04:28:26 because I know the teacher only loves C Feb 07 04:28:44 I'm such a loveable student Feb 07 05:25:18 mawk: https://en.wikipedia.org/wiki/Objective-C#Objective-C++ Feb 07 05:25:19 ;) Feb 07 05:45:41 his only condition is that it can compiles on archlinux Feb 07 06:54:33 ... which is basically everything? Feb 07 07:17:56 yeah Feb 07 07:17:59 I guess Feb 07 07:18:04 but he doesn't want us to use exernal libs Feb 07 07:18:11 so that rules out various language runtimes maybe Feb 07 07:18:15 but his logic is fragile Feb 07 07:18:18 that'd rule out the libc Feb 07 07:18:36 the only quality of the libc is that it's pre-installed and linked by default with the standard compiler Feb 07 07:18:41 but it's a runtime too Feb 07 13:00:59 mawk: if you want to get the most out of the class, it's probably worth trying to do what he wants rather than looking for holes in the rules Feb 07 13:03:32 your creativity is best used in enhancing the project rather than beating the teacher Feb 07 21:08:25 zmatt: do you still live here? Feb 07 21:23:10 yeah I was joking artag , he reads C++ I'm sure Feb 07 21:23:16 but some of my comrades are not Feb 07 21:23:22 some are using haskell, some go, etc Feb 07 21:23:36 but that teacher isn't much liked Feb 07 21:23:49 he comes high or drunk to classes, sometimes late, sometimes he doesn't even come because he didn't wake up Feb 07 21:24:03 but he's a good dev Feb 07 21:24:08 here are some of the projects he made: https://lse.epita.fr/projects/ Feb 07 22:09:02 seems he likes to reverse-engineer and hack stuff. I approve of that. Feb 07 22:10:08 yeah Feb 07 22:10:25 he runs the system&security lab of the school Feb 07 22:11:12 have you seen ross anderson's stuff ? he does something similar at Cambridge Feb 07 22:11:36 "KOPUL : Kind Of Pack Unpack Language" lol Feb 07 22:11:46 kopul means procreate in french, phonetically Feb 07 22:11:50 heh Feb 07 22:11:52 in english too no ? "to copulate" Feb 07 22:12:13 yes, though I don't think anyone would make that link Feb 07 22:12:14 no I didn't knew him Feb 07 22:12:46 cybercrime center Feb 07 22:13:04 well I'm french and he is too Feb 07 22:13:10 so everyone involved with the project knows what it means Feb 07 22:13:26 eg he did it on purpose Feb 07 22:13:53 that makes me think of https://weboob.org/ that got kicked from debian recently because of the boobs reference Feb 07 22:13:59 they're french too, strange coincidence Feb 07 22:15:15 i like provate jones like that, even if not rude. The power PC had an instruction 'enforce in-order execution of IO' to do with caching and io instructions. the instruction was called eieio Feb 07 22:16:19 typo ^^ up there was 'private jokes' Feb 07 22:19:15 in english, boob is just as often 'error' as 'breast' Feb 07 22:19:29 as in 'I boobed' for 'I fucked up' Feb 07 22:30:51 eieieieieieio Feb 07 22:30:56 I see Feb 07 22:34:24 eieio as in 'old mcdonald had a farm. eieieo'. maybe that's not a french song. Feb 07 23:51:09 yeah we know that in france too Feb 07 23:51:31 we would spell that hiyahiyaho Feb 08 00:46:36 artag: I've never seen or heard "boob" used in that way Feb 08 00:48:23 (random factoid: the PowerPC architecture has an "eieio" instruction) Feb 08 01:26:26 I am using BBB to talk to LTC2984 chip. Unfortunately they do not communicate. SDO always sends FF. I wonder if anyone has a working BBB sample to talk to this chip. I am quite new to SPI, though I believe I understand it. Feb 08 01:29:50 what connections have you made? (i.e. which signal to which beaglebone pin) Feb 08 01:31:27 hello zmatt Feb 08 01:31:42 * zmatt checks datasheet in meantime... ok, spi mode 0, max 2 MHz Feb 08 01:32:37 P9.17 ss Feb 08 01:33:54 p9.18 mosi; p9.21 miso Feb 08 01:34:04 p9.22 clk Feb 08 01:34:26 device: "/dev/spidev1.1" Feb 08 01:34:54 those are not signal names of the LTC2984 Feb 08 01:36:04 spidev1.1 is definitely wrong, it should be spidev1.0 (unfortunately the off-by-one error of the spi bus numbering is a historical error kept for backwards compatibility) Feb 08 01:37:31 give me a moment Feb 08 01:37:47 I'm going to assume you have P9.17 -> CS, P9.18 -> SDI, P9.21 <- SDO, P9.22 -> SCK Feb 08 01:38:04 let me check /dev/spidev1.1 Feb 08 01:38:07 but do double-check sdi/sdo Feb 08 01:38:53 P9.17 is cs0, hence the .0 Feb 08 01:39:33 also, if you're not controlling its nRESET input from the beaglebone, be sure to tie it high Feb 08 01:40:32 next thing to check is pin configuration. you can e.g. use my https://github.com/mvduin/bbb-pin-utils/#show-pins utility to double-check you've correctly configured the pins to spi mode Feb 08 01:40:41 did you modify the device tree also dreamhiker ? Feb 08 01:40:43 ah Feb 08 01:40:49 no need to modify the device tree Feb 08 01:41:22 because spidev is in the default cape ? Feb 08 01:41:24 assuming a beaglebone with a recent image you can just configure the pins with config-pin Feb 08 01:41:27 the default dt Feb 08 01:41:29 ah Feb 08 01:41:41 most functionality is part of the universal overlay Feb 08 01:41:47 yeah universal overlay Feb 08 01:41:51 that was the word I was looking for Feb 08 01:43:01 if pins are hooked up right and are configured right, next question would be what programming language you're using and which library (if any) for spi access Feb 08 01:46:03 is spidev1.1 vs 1.0 relates to SS? Feb 08 01:46:24 hmm, the read/write opcodes this thing uses are compatible with spi eeprom... it might actually be an interesting option to use an overlay to make it use the at25 driver rather than the spidev driver, then the memory map of this thing would appear as a file you can simply access using seek/read/write or pread/pwrite Feb 08 01:46:32 dreamhiker: yes, spidev1.1 is for cs1 Feb 08 01:47:08 like I said, the bus numbering is off-by-one, so 1.0 = spi0 cs0, 1.1 = spi0 cs1, 2.0 = spi1 cs0, 2.1 = spi1 cs1 Feb 08 01:47:14 Thanks! it started to do something useful :) Feb 08 01:48:33 sorry, what was the name for the textboard? Feb 08 01:48:40 copy/paste Feb 08 01:48:54 pastebin' Feb 08 01:48:58 there are many such sites, but pastebin.com for example Feb 08 01:49:41 The pins are configured properly. Your utility confirms that. Feb 08 01:50:41 here is the program: https://pastebin.com/kr9dLsLG Feb 08 01:50:52 There is something I do not understand Feb 08 01:51:29 let us look at spi_transfer_block() Feb 08 01:51:59 btw, next time select "C" from the syntax highlighting options menu Feb 08 01:52:33 why .len defines input and output number of bytes? Feb 08 01:53:34 Thanks for 'C' Feb 08 01:53:39 https://paste.serveur.io/YJa25aN7.c Feb 08 01:53:47 reupload without the ads and with syntax coloration Feb 08 01:54:14 dreamhiker: what do you mean? the len field is just how many "words" (which should be bytes in this case, i.e. bits_per_word should be 8) should be transferred... how else would the kernel know? Feb 08 01:54:32 SPI is full duplex dreamhiker Feb 08 01:54:37 a transfer is bidirectionnal Feb 08 01:54:44 so, you specify the length of both input and output buffers Feb 08 01:54:57 the output buffer is shifted serially while the input buffer is filling Feb 08 01:55:02 well "full duplex" just maens you *can* communicate in both directions at the same time. with spi doing so is obligatory Feb 08 01:55:11 yes Feb 08 01:55:27 ultimate full duplex Feb 08 01:56:06 a pointer is always unsigned long ? that's dubious Feb 08 01:56:13 let us look at https://github.com/spotify/linux/blob/master/include/linux/spi/spidev.h Feb 08 01:56:21 well it's not 64 bits so it's fine, but it doesn't sound extremely portable Feb 08 01:56:24 @len: Length of tx and rx buffers, in bytes. Feb 08 01:56:34 yes Feb 08 01:56:39 see the full duplex explanation Feb 08 01:57:47 dreamhiker: https://github.com/torvalds/linux/blob/v4.20/include/uapi/linux/spi/spidev.h Feb 08 01:57:51 this is the most recent source Feb 08 01:57:55 the header changed a bit Feb 08 01:58:08 in general don't get random forks on github to look at the kernel code, it can change a lot Feb 08 01:58:54 mawk: are you saying that a number of bytes received is ALWAYS equal to a number of bytes sent? Feb 08 01:59:12 in a single SPI message yeah Feb 08 01:59:24 if you want to mask that fact you can use several SPI messages Feb 08 01:59:29 tx only followed by rx only Feb 08 01:59:45 but that's less flexible Feb 08 02:00:06 and anyway the kernel falls back to full duplex with zero buffers anyway I think Feb 08 02:00:13 https://pastebin.com/nMjd9sdz Feb 08 02:00:50 (I recommend doing spi configuration once on the fd instead of overriding it per messsage) Feb 08 02:03:40 Looking at your sample. I do not understand it. tr[0] doesnot specify rx_buf Feb 08 02:04:18 it's like specifying a trash buffer Feb 08 02:04:23 I think Feb 08 02:04:24 letting it default to NULL is fine Feb 08 02:04:37 you're sure it defaults to NULL ? Feb 08 02:04:42 you don't need to do {..., 0} for that ? Feb 08 02:04:45 null, mening that no received data? Feb 08 02:04:46 doesn't it in C? Feb 08 02:04:53 I'm not sure Feb 08 02:05:05 I'm very much used to C++ where I'd write this differently to begin with Feb 08 02:05:18 I know in C++ {} defaults everything to null , and that in C {..., 0} defaults the rest to null Feb 08 02:05:22 but just {...} I'm not sure Feb 08 02:05:33 let me check Feb 08 02:05:35 if in doubt, just explicitly memset(tr, 0, sizeof tr); and then explicitly set the relevant fields Feb 08 02:06:08 my question is not about the default value of uninitialized things, which in C I believe undefined Feb 08 02:06:33 but I'm pretty sure this works since the linux kernel relies on it iirc... or maybe that's just for static data, I'm not 100% sure Feb 08 02:06:52 if it's undefined you'll presumably get a compiler warning Feb 08 02:08:09 dreamhiker: there's nothing useful on SDO during those first three bytes (the command and address). setting rx_buf to NULL means the received data (i.e. 0xff due to pull-up) will be discarded Feb 08 02:08:12 sorry, let me get back to my question: if rx_buf is null does it mean that the ioctl will ignore all the output data? Feb 08 02:08:26 for that part of the transfer yes Feb 08 02:08:39 got it! Thanks! Feb 08 02:09:48 And for tr[1] the amount of received data is 'length'? Feb 08 02:10:13 the number of bytes transferred (in and/or out) yes Feb 08 02:11:02 so, if i understand correctly, for each byte sent there is a byte received Feb 08 02:11:57 yeah you're right zmatt Feb 08 02:12:00 there is nothing that indicates the presence or absence of data on the SDI or SDO line Feb 08 02:12:11 https://godbolt.org/z/MlLs5p Feb 08 02:12:20 it's zeroed out Feb 08 02:12:35 uh I did it in C++ Feb 08 02:12:38 let me try C instead Feb 08 02:13:04 so every clock cycle will transfer a bit from the device's SDO to the beaglebone's MISO and a bit from the beaglebone's MOSI to the device's SDI Feb 08 02:14:23 regardless of whether there's anything useful to communicate in both directions Feb 08 02:14:29 Cool! thank you for the explanation. For me the full duplex meant something else (like a duplex socket), where the things tx and rx are independent. Good to know! Feb 08 02:14:35 even in C it's zeroed out yes Feb 08 02:14:41 https://godbolt.org/z/okrTf7 Feb 08 02:14:43 yes "full duplex" was not a good choice of words Feb 08 02:14:49 Definitely not local variables Feb 08 02:15:08 unless something sihnificant has changed in the last 5 years :) Feb 08 02:15:13 not local variables in general, but structs with designated initializers Feb 08 02:15:24 oh he didn't test those Feb 08 02:15:29 Thank you for conforming. I feel less stupid :) Feb 08 02:15:44 with designated initializers it's the same Feb 08 02:15:56 in C Feb 08 02:16:46 I think that it makes sense for structs, though I do not remember seeing the .xyz syntax in my past life :) Feb 08 02:17:03 it's a pretty nice syntax Feb 08 02:17:20 struct { int a; int b; int c; } x = {.a = 12, .b = 42, .c = 54}; Feb 08 02:18:03 also, a test like this should definitely be done with optimization enabled Feb 08 02:18:05 BTW, the code you see was taken from Arduino controlling the chip. As such, do you think in general this ioctl approach is the correct one? Feb 08 02:18:13 you have something like it for arrays, for instance int x[3] = {[2] = 12, [0] = 4, [1] = 5}; Feb 08 02:18:22 but indeed even at -O3, struct s s4 = {.b=1}; properly zero-initializes the other two fields Feb 08 02:18:37 ah the optimization disappeared when I went from C++ to C Feb 08 02:18:46 but yeah I intended to test with it Feb 08 02:19:24 the ioctl approach is pretty much the only approach I think dreamhiker Feb 08 02:19:29 so yeah it's correct Feb 08 02:19:32 annoyingly, g++ only allows designated initializers if you provide them in-order :/ Feb 08 02:19:45 well no you have the read()/write() approach with a user-controlled CS but that's ugly Feb 08 02:19:55 you have the power of the ioctl at hand because you're low level, you might as well use it Feb 08 02:19:57 annoying indeed, for the name entities. Feb 08 02:20:07 yeah zmatt , that sucks Feb 08 02:20:27 OK, let me try you spi_transfer_block Feb 08 02:20:59 initializing to {} and then setting the fields works correctly in C and C++ Feb 08 02:23:12 mawk: like I said, since this thing uses a memory-mapped interface with read/write opcodes compatible with that of spi eeprom, it might be possible to use an existing kernel driver to expose a file-like interface to the device Feb 08 02:23:25 ah ! right Feb 08 02:23:25 so you can pread()/pwrite() instead of the read/write functions I made Feb 08 02:23:26 yeah Feb 08 02:23:41 but that would require an overlay, so just sticking to spidev is probably more convenient Feb 08 02:24:12 it also seems the spi eeprom (at25) driver does a bit too much other stuff to be able to abuse it like this Feb 08 02:27:02 zmatt, trying to understand your spi_transfer_block Feb 08 02:28:21 what is the header? Feb 08 02:28:28 (btw I added example code for initialization at the top, so refresh the paste if necessary) Feb 08 02:29:09 it's the instruction byte and address bytes, see figures 1 and 2 in the datasheet Feb 08 02:32:50 doing a two-part transfer like this is typically more convenient, since it lets you read into or write from an existing buffer or structure Feb 08 02:33:12 as far as your initialization, what about other parameters: SPI_IOC_RD_MAX_SPEED_HZ, SPI_IOC_RD_BITS_PER_WORD, etc. Feb 08 02:33:23 like I said, reload my paste Feb 08 02:34:07 reloaded, i can see only 3 ioctl in spi_initialize Feb 08 02:34:27 oh, why would you want to read those parameters? Feb 08 02:34:34 I mean, you can, but you set them yourself Feb 08 02:34:47 RD stands for READ dreamhiker Feb 08 02:34:50 no need to use them Feb 08 02:35:00 that Feb 08 02:36:41 So you are saying that I do not need to worry abot RD params? Feb 08 02:37:01 SPI_IOC_RD_* is to read parameters Feb 08 02:37:04 there are no "RD params", the RD ioctls let you read those parameters you set with WR Feb 08 02:38:02 Oh, I see :) Feb 08 02:40:27 as far as the initialization, is the order unimportant? Feb 08 02:42:55 no Feb 08 02:46:21 fun fact, in gcc you can also do: https://pastebin.com/N9yTCv7x Feb 08 02:46:33 annoyingly it doesn't support it in c++ mode Feb 08 02:47:54 shall I assume that both BBB and the chip communicate in low-endian mode? Feb 08 02:48:03 big-endian mode Feb 08 02:48:10 spi is basically always big endian Feb 08 02:53:51 so, BBB is little endian, but SPI is big endian? **** ENDING LOGGING AT Fri Feb 08 02:59:56 2019