**** BEGIN LOGGING AT Sun Sep 16 03:00:00 2018 Sep 16 08:42:05 zmatt: on the raspberry pi capes there's typically a protection circuit preventing damage if you at the same time provide power to the main board from a cape and via the onboard USB Sep 16 08:42:26 zmatt: is that recommended also for the BBB if you power the main board through VDD_5V? Sep 16 08:42:53 the pmic will automatically switch between those two power sources Sep 16 08:43:26 hm, yes, but VDD_5V is also on the barrel plug, right? Sep 16 08:44:26 so it could happen that a user has 5V connected to the barrel plug at the same time with a cape powering the bbb through P9 Sep 16 08:44:28 yes. sorry I thought you meant specifically usb, but you simply meant in general Sep 16 08:45:00 it would probably be wise to take that scenario into account and ensure your cape tolerates 5v being backfed Sep 16 08:45:12 yes, I was speaking about the raspi, which has no barrel plug connector but is only powered through usb or through a cape Sep 16 08:45:26 unless it's not a general-purpose cape and you can ensure it won't happen in the target application Sep 16 08:46:01 well users are what they are and do what they do... Sep 16 08:46:18 yeah I mean, if you're simply designing a product around the bbb Sep 16 08:46:21 I cannot tell them to remove the barrel plug from their boards... Sep 16 08:46:34 rather than making a separate cape sold to users Sep 16 08:47:06 not a product, but the design will be public and people will potentially build their own boards.... Sep 16 08:47:58 well then it's your call whether protection is required or a design warning suffices Sep 16 08:48:09 yup Sep 16 08:48:34 as there's no equivalent protection on the bbb itself, I'll stick to better-safe-than-sorry Sep 16 08:49:14 the bbb can't possibly include such protection since those pins are designed to support both power in (when barrel is not used) or power out (when barrel is used) Sep 16 08:49:50 hm, correct Sep 16 08:50:30 didn't think of that... Sep 16 08:50:58 hmmmm Sep 16 08:51:58 yes Sep 16 16:21:55 in C: readlink(...); is returning a path with "../../" (symlink resolved), but fread cannot get it Sep 16 18:44:49 do you mean fopen() succeeds but fread() fails? what is the error? can you simply cat the file in the shell? Sep 16 19:01:25 i mean fopen Sep 16 19:02:44 opening and reading from the full path is fine... but maybe is there a function for removing "../../" Sep 16 19:03:43 I don't know what you mean by that. you don't have to treat a symlink special in any way, you just open it like a normal file Sep 16 19:05:35 I'll try Sep 16 19:05:57 if you have some reason to want to resolve the target path of a symlink, use realpath() Sep 16 19:07:09 but most applications should not care whether something is a symlink, or what absolute path it resolves to Sep 17 02:00:35 Back to the MotorCape! **** ENDING LOGGING AT Mon Sep 17 02:59:59 2018