**** BEGIN LOGGING AT Fri Jan 20 03:00:03 2017
Jan 20 03:46:11 <Frogging101> <omar> hello there i need help with a robot
Jan 20 03:46:19 <Frogging101> whatever you're doing: don't
Jan 20 03:46:21 <Frogging101> :p
Jan 20 04:10:32 <YesSometimes> I've been unable to google up the answer or search the BBB itself to find the location of the "BeagleBone Getting Started" folder that shows up when connecting via USB to a PC
Jan 20 04:11:16 <YesSometimes> Is it possible to change the default behavior of the BBB when connecting to a PC?  Or at minimum replace the "getting started" htm pages with those of my own writing?
Jan 20 09:37:23 <DriesS> I have a beaglebone with SD card that boots automaticly. How can I tell the system to boot on the internal system?
Jan 20 09:41:24 <gquere> DriesS: on eMMC you mean ?
Jan 20 09:41:30 <DriesS> yes
Jan 20 09:42:11 <gquere> it's supposed to automatically boot from eMMC I think
Jan 20 09:42:47 <gquere> are you sure it boots from the SD card ?
Jan 20 09:43:14 <LetoThe2nd> if in doubt, look up the sysboot pins and set them to your liking.
Jan 20 09:44:00 <DriesS> gquere: yes because our operating system is on the SD card
Jan 20 09:44:06 <DriesS> with uBoot and uENV config
Jan 20 09:44:23 <DriesS> the problem is that the SD card is now corrupt and does not write changes to it.
Jan 20 09:44:58 <gquere> what happens if you remove the SD card and try to boot ?
Jan 20 09:45:01 <DriesS> so I can not change the uboot to tell the system to boot on eMMC
Jan 20 09:45:24 <DriesS> our problem is that we don’t have physical access to the system
Jan 20 09:46:05 <gquere> so ... you don"'t have physical access AND cannot commit changes to the filesystem ??
Jan 20 09:46:35 <LetoThe2nd> technically ou can rewrite the uboot env from the system and then reboot. but if it fails, then... you are bricked. no good idea if you can't access the system.
Jan 20 09:47:25 <DriesS> LetoThe2nd: I can access the system but I need to drive from Belgium -> Germany for it :)
Jan 20 09:48:31 <phschafft> consider to visit me when in germany :)
Jan 20 09:50:52 <LetoThe2nd> DriesS: the point is that if something goes wrong, there's no way back.
Jan 20 09:51:13 <DriesS> LetoThe2nd: but we can’t change uboot and uenv
Jan 20 09:51:58 <LetoThe2nd> DriesS: ok. so you can't set jumper wires, you can't modify bootloader settings - how on earth do you want to change the boot then?
Jan 20 09:52:27 <DriesS> LetoThe2nd: don’t know that is why I was asking here to be sure there is no other way then going to the device
Jan 20 09:52:40 <LetoThe2nd> i can't think of anythng.
Jan 20 09:54:06 <DriesS> We have now the 2nd device with an SD card corrupted. Is it better to write our system to the eMMC to avoid this situations?
Jan 20 09:54:55 <LetoThe2nd> emmc might be a bit better, but generally nand technology is somewhere between low quality and outright crap.
Jan 20 10:05:33 <thinkfat> DriesS: you might want to investigate what's causing the corruption, and probably switch brand of the SD card ;)
Jan 20 10:06:30 <thinkfat> I'd check if your system is not constantly writing to the SD card
Jan 20 10:07:44 <DriesS> thinkfat: it is a system that is constanly registering values and writing this to a database
Jan 20 10:08:35 <DriesS> thinkfat: it is like a domotic system for monitoring hardware (air pressure, temperature, humidity, … )
Jan 20 10:08:52 <DriesS> so we are saving this in a sqlite database
Jan 20 10:09:40 <LetoThe2nd> um, but depending on the cycle and size this is going to kill any kind of nand storage.
Jan 20 10:10:32 <thinkfat> especially high-density, mlc based consumer crap^Wgrade SD cards
Jan 20 10:10:48 <DriesS> LetoThe2nd: ok so meaning we have to add an HDD instead of an SSD?
Jan 20 10:10:59 <thinkfat> cloud cloud cloud :-)
Jan 20 10:11:14 <DriesS> thinkfat: yes but it is using 3g/4g
Jan 20 10:11:23 <LetoThe2nd> DriesS: i did not say hdd, just some kind of storage that is suited for random write access.
Jan 20 10:11:27 <DriesS> so meaning we have to upload and download all the time
Jan 20 10:11:39 <LetoThe2nd> DriesS: you can also use a printed, for example.
Jan 20 10:11:45 <thinkfat> DriesS: reduce the frequency of writes to the storage
Jan 20 10:11:46 <LetoThe2nd> *printer
Jan 20 10:12:22 <LetoThe2nd> DriesS: depending on the volume and rate of the datapoints, piping out via MQTT might be an option.
Jan 20 10:14:13 <thinkfat> how large is the dataset you need to write, can you cache it in memory more agressively, is data loss through a power interruption critical?
Jan 20 10:47:48 <lore4> zeekhuge: I am doing what I wrote yesterday... I hope that it will work as only the header file with the struct is becoming more thatn 500 lines of code
Jan 20 10:47:56 <lore4> xD
Jan 20 13:11:51 <prakash> hi
Jan 20 13:12:22 <prakash> How to get the bootlogo in beagle bone black
Jan 20 13:22:01 <lore4> I would like to define an address in PRU contants table. I read on PRU manual that only addresses from 24 to 31 are programmable. Anyone has experience of changing one of them?
Jan 20 13:28:32 <philenotfound> DTS question: Can I place arbitrary string properties in a node in order to query them later from userspace?
Jan 20 13:29:52 <philenotfound> As I understood it there is no verification of the node contents at build/runtime for unknown properties..
Jan 20 13:29:52 <zeekhuge> lore4: Hi ! did that work ?
Jan 20 13:30:11 <zeekhuge> lore4: you can do that by using Control registers
Jan 20 13:30:57 <zeekhuge> something like PRU0_CTRL.CTPR0 = 0xSOME_VALUE
Jan 20 13:31:17 <zeekhuge> dont remember exactly
Jan 20 13:33:29 <lore4> zeekhuge: I had just finished the draft of the .h file with the structs for each register of TSC ADC (not at bit level T.T)
Jan 20 13:33:56 <zeekhuge> prakash: you mean the logo thats on the website bbb.io ?
Jan 20 13:33:58 <lore4> I added the address to the .cmd file, but there is not room for cregister as all 32 are used : \
Jan 20 13:34:21 <zeekhuge> you dont strictly need it to be in the cmd
Jan 20 13:34:59 <zeekhuge> it can be accessed without putting in the CREGISTERS
Jan 20 13:35:49 <lore4> great!
Jan 20 13:38:10 <lore4> zeekhuge: but if i do not put it in the CREGISTERS, will "volatile __far sysPwmss TSCADCSS __attribute__((cregister("TSCADCSS", far), peripheral));" work?
Jan 20 13:42:18 <lore4> *sysPwmss = sysTscadcss
Jan 20 13:48:38 <fjfijfg> .
Jan 20 13:50:35 <zeekhuge> oh ! sorry ! mom called :P
Jan 20 13:51:26 <zeekhuge> lore4: you can probably use something like "volatile __far name __attribute((location(address_of_peripheral)))"
Jan 20 13:56:33 <lore4> zeekhuge: don't worry, be happy ;) moreover, mom is always mom!
Jan 20 13:57:11 <lore4> zeekhuge: ok so address_of_peripheral = 0xXXXXX, right? without any define
Jan 20 13:57:28 <zeekhuge> yeah. that should work
Jan 20 13:57:33 <zeekhuge> try it now.
Jan 20 13:57:46 <zeekhuge> I mean .. if its possible
Jan 20 13:58:47 <lore4> uhm.. volatile __far sysTscadcss TSCADCSS __attribute((location(0x44E0D000)))
Jan 20 14:01:26 <lore4> zeekhuge: 3 errors while compiling... going into debug
Jan 20 14:02:30 <zeekhuge> is is with the __attribute() ?
Jan 20 14:04:37 <lore4> stddef.h -> #66 expected a ";" -> typedef __PTRDIFF_T_TYPE__ ptrdiff_t;
Jan 20 14:05:10 <zeekhuge> oh ! wait ! that wont work !
Jan 20 14:06:07 <lore4> I putted my .h file into pru-software-support-package/include/am335x
Jan 20 14:06:26 <lore4> that folder is included in my CCS project
Jan 20 14:13:02 <naveen> Will it be possible to monitor individual power rails of beagleboard X15 rev B1 like Rev A2? Can anybody in the know let me know. The documentation is insufficient.
Jan 20 14:15:30 <lore4> zeekhuge: without my .h it is compiling, with it does not. T.T
Jan 20 14:15:51 <lore4> naveen: sorry, I dunno : \
Jan 20 14:16:37 <zeekhuge> lore4: uhm ... actually ...
Jan 20 14:18:16 <naveen> lore4@ does the developers of Beagleboard hang around this IRC channel? May be I can bug them :-)
Jan 20 14:18:50 <naveen> I wrote to the mailing list yesterday. It is still unanswered.
Jan 20 14:18:53 <prakash> I am using 3.14 kernel it doesn't show the logo on the hdmi screen zeekhuge
Jan 20 14:20:06 <prakash> zeekhuge: it's seems like drm driver is utilizing the framebuffer on the newer kernels
Jan 20 14:21:03 <lore4> naveen: actually, I have no idea about that... but here there are people with more experience than me, probably they can help you :) be patient ;)
Jan 20 14:23:12 <naveen> In the mailing list, Gerald seems to be the one who used to answer the power management issues. I could not find him on this channel :(
Jan 20 14:23:44 <lore4> zeekhuge: I tried to change the previous "volatile _far ..." with a define which, I believe to be the same (hopefully, give me some feedbacks pls :P) "#define TSCADCSS (*((volatile sysTscadcss*)0x44E0D000))"
Jan 20 14:24:37 <zeekhuge> lore4: actually that CREGSITER tag in the .cmd file seems to be just of no use.
Jan 20 14:24:42 <zeekhuge> can you try it like this :
Jan 20 14:25:21 <lore4> naveen: let's hope that he is in vacancy and he will be back soon ;)
Jan 20 14:25:58 <zeekhuge> TSCADCSS (R): origin = 0xsomething length = 0xsomething
Jan 20 14:26:20 <zeekhuge> or even add CREGSITER=some_unique_number
Jan 20 14:26:38 <flash_> hi there
Jan 20 14:26:43 <flash_> anyone?
Jan 20 14:26:56 <zeekhuge> and then in the code do like earlier with __attribute(cregister(),peripheral) and all that
Jan 20 14:29:38 <lore4> zeekhuge: uhm...
Jan 20 14:31:06 <lore4> zeekhuge: I got lost
Jan 20 14:31:46 <zeekhuge> can you share your code ?
Jan 20 14:31:58 <zeekhuge> is it hosted somewhere ?
Jan 20 14:32:12 <lore4> locally : \ do you have an email?
Jan 20 14:32:45 <zeekhuge> yeah contact@zeekhuge.me
Jan 20 14:33:31 <lore4> writing, ty!
Jan 20 14:43:20 <lore4> zeekhuge: sent
Jan 20 14:49:37 <zeekhuge> lore4: uhm ... havent receive yet. looks like its spammed out. :\ will have to configure it.
Jan 20 14:50:09 <zeekhuge> lore4: sorry but can you please resend it to my original email : me.zubeen3@gmail
Jan 20 14:53:20 <gquere> hint: github.com ;)
Jan 20 14:54:34 <lore4> zeekhuge: sure, done ;)
Jan 20 14:58:04 <lore4> zeekhuge: meanwhile, I'm still doing some debugging... it seems that the struct is good... the issue is the allocation
Jan 20 15:11:29 <lore4> zeekhuge: it seems to compile now... dunno why O.O
Jan 20 15:12:47 <zeekhuge> the same code ?
Jan 20 15:13:15 <lore4> zeekhuge: some comment/uncomment write/delete/rewrite of the same things O.O
Jan 20 15:13:36 <lore4> zeekhuge: #define TSCADCSS (*((volatile sysTscadcss*)0x44E0D000))
Jan 20 15:14:38 <zeekhuge> I have made following changes : http://paste.ubuntu.com/23833740/
Jan 20 15:14:41 <zeekhuge> dinner now.
Jan 20 15:14:50 <lore4> zeekhuge: enjoy the meal! ;) ty
Jan 20 15:18:11 <minnesotags> Uh, this is a bone simple question, and I swear I have googled extensively. I was able to easily cat out analog pin data from Angstrom, how do I do it on the latest Debian build?
Jan 20 15:58:18 <lore4> zeekhuge: it reads 0 in different registers which should contain value != then 0 : \
Jan 20 16:05:26 <asad_> hi is there a simulator for bb available? e.g., to test code before deploying?
Jan 20 16:05:51 <asad_> for 8051 I use proteus/multisim etc.
Jan 20 16:16:18 <zeekhuge> lore4: back . did you try that patch ? actually there was a mistake in that too. hope you noticed
Jan 20 16:16:56 <lore4> I tryed my code and took a look at your, but not tryed! If you mean by the mistake the wrong struct name, yes I noticed ;)
Jan 20 16:17:10 <lore4> tring with your code
Jan 20 16:17:51 <lore4> however, I checked the technical manual of AM335x and it is wrote that there are only 32 cresgister... is it right to use 51?
Jan 20 16:18:53 <zeekhuge> lore4: actually .. it looks like that CREGISTER tag is optional.
Jan 20 16:19:02 <zeekhuge> so ... try removing it too.
Jan 20 16:19:04 <lore4> zeekhuge: Btw, what does it stand for the "(R)"?
Jan 20 16:19:16 <zeekhuge> R = readable
Jan 20 16:21:13 <lore4> :O that sounds clever!
Jan 20 16:21:17 <lore4> ty
Jan 20 16:22:12 <zeekhuge> also .. see if the len is correct
Jan 20 16:23:28 <lore4> zeekhuge: it still reads 0 instead of 10h : \
Jan 20 16:23:42 <zeekhuge> :(
Jan 20 16:23:45 <lore4> I edited AM335X.cmd by adding ad from your patch "TSCADCSS (R)	: org = 0x44E0D000 len = 0x00000300 CREGISTER=31"
Jan 20 16:24:02 <zeekhuge> remove CREGISTER ?
Jan 20 16:24:41 <lore4> and also I edited sys_tscadcss.h by removing the "#define TSCADCSS ..." and adding "volatile __far sysTscadcss TSCADCSS __attribute__((cregister("TSCADCSS", far), peripheral));"
Jan 20 16:25:10 <lore4> if I compile by removing CREGISTER it throws a warning
Jan 20 16:25:20 <lore4> "Description	Resource	Path	Location	Type #10247-D creating output section ".creg.TSCADCSS.noload.far" without a SECTIONS specification	PRU_RPMsg_Echo_Interrupt1		 	C/C++ Problem"
Jan 20 16:27:22 <zeekhuge> :(
Jan 20 16:27:41 <zeekhuge> I'll try it tonight .... wont sleep maybe .
Jan 20 16:28:21 <zeekhuge> Sorry .. no more ideas.
Jan 20 16:28:26 <lore4> zeekhuge: ah ah! don't worry, get rest for the weekend ;) if you will be here on monday we will go on ;) a lot of thanks!
Jan 20 16:29:04 <lore4> zeekhuge: I also do not have any more idea
Jan 20 16:51:19 <dury> hi there all
Jan 20 16:51:48 <dury> where can I buy X15 in europe
Jan 20 16:52:00 <lore4> bye folks, enjoy the weekend
Jan 20 17:58:02 <Chao> Hi all, I am trying RS485 CAN Cape(http://www.waveshare.com/wiki/RS485_CAN_CAPE#Introduction), but the image won't boot on my BBGW
Jan 20 17:59:01 <Chao> my question is, do capes for BBB also work for BBGW?
Jan 20 18:33:20 <kamilo1409> hi. can you help me how connect temperature sensor and rgb diode with beaglebone?
Jan 20 20:23:49 <dury> hi there channel :-)
Jan 20 20:24:28 <dury> which one is better xM or X15 board
Jan 20 20:43:45 <dury> so guys... no answer or what
Jan 20 20:44:09 <Frogging101> be patient pls
Jan 20 20:44:30 <dury> which one is better xM or X15 board
Jan 20 20:44:56 <dury> Frogging101, sorry there
Jan 20 21:37:52 <Confusedand> Anybody using the BBB to power up and down without a button press?
Jan 20 22:27:36 <GenTooMan> Not me
Jan 21 00:09:28 <zmatt> GenTooMan: you could parse that? I'm really not sure what he was asking
Jan 21 00:12:53 <zmatt> *sigh* it's so annoying to see questions that could be answered if the people asking them would stick around
Jan 21 00:14:56 <zmatt> fuck it, I'll answer a few anyway... if they show up again hopefully someone will point them to the logs :P
Jan 21 00:16:32 <zmatt> Confusedand: the BBB powers up when power is applied or (after shutdown) when the power button is pressed, it powers down on request by software (e.g. in response to power button press).
Jan 21 00:17:21 <zmatt> dury: your question has no answer, "better" is subjective and depends on what you care about
Jan 21 00:19:47 <Frogging101> people think the I in IRC stands for "Instant" I suppose
Jan 21 00:19:49 <Frogging101> :p
Jan 21 00:20:51 <veremit> kids these days have a 3 second attention span
Jan 21 00:21:35 <zmatt> kamilo1409: when asking how to interface stuff, *be specific* and specify the actual components.  nobody can answer how to interface a "temperature sensor" in general.  for leds (rgb or otherwise) see for example the 4 user leds in BBB's own schematic
Jan 21 00:22:27 <zmatt> Chao: the BBGW's brilliant (*cough*) design sacrifices a whole bunch of expansion I/Os for its wireless chipset, hence not all capes will be compatible
Jan 21 00:23:57 <zmatt> lore4: CREGISTER=51 makes no sense.  there's no constants-register that's of any use for the address 0x44E0D000
Jan 21 00:28:06 <zmatt> minnesotags: see if this is of any help: http://elinux.org/Beagleboard:BeagleBone_Debian_Image_Migration#Enabling_the_ADC
Jan 21 00:28:15 <zmatt> well that's at least one person who's still here :D
Jan 21 00:51:34 <zmatt> it's really bizarre that the pru constants registers have the same values in all instances of prussv2, rather than being addresses that are actually *useful* on the target
Jan 21 00:51:47 <zmatt> e.g. on am572x most of the constants are completely useless
Jan 21 01:00:34 <minnesotags> zmatt; I'm good with doing it how it is done now. I have kernel 4.4.x,
Jan 21 01:01:18 <zmatt> minnesotags: ah you figured it out already? ok good :)
Jan 21 01:01:46 <minnesotags> No. i didn't figure it out.
Jan 21 01:01:51 <zmatt> ?
Jan 21 01:02:24 <minnesotags> From what I read, those show how to disable current device tree and do it how it HAD been done.
Jan 21 01:02:54 <minnesotags> Lots of "disabling".
Jan 21 01:03:37 <zmatt> eh no the section I linked to explains how to enable the ADC on kernel 4.x (since it's not enabled by default) and also shows its new location in sysfs (since it's now an IIO device)
Jan 21 01:04:04 <minnesotags> I will check.
Jan 21 01:05:00 <minnesotags> permission denied to echo to "slots".
Jan 21 01:05:14 <zmatt> then probably the path is wrong
Jan 21 01:05:22 <minnesotags> I have heard this is related to it being tied to hdmi?
Jan 21 01:05:51 <minnesotags> Slots is there. I can't save to it using nano, either.
Jan 21 01:05:52 <zmatt> uhh, the adc is not related to hdmi in any way or fashion
Jan 21 01:06:11 <zmatt> using a text editor in sysfs is generally a bad idea
Jan 21 01:06:21 <zmatt> did you do the echo as root ?
Jan 21 01:06:33 <minnesotags> Yes
Jan 21 01:07:16 <zmatt> (note: "sudo echo" does not do what you want, open a root shell using "sudo -s" and perform the echo from within it)
Jan 21 01:07:31 <minnesotags> -bash: /sys/devices/platform/slots: Permission denied
Jan 21 01:08:05 <minnesotags> I am logged in as root, I don't need to do sudo anything.
Jan 21 01:08:11 <zmatt> that's not the path to slots
Jan 21 01:08:55 <zmatt> ok, I mentioned that just in case, since it's easy to trip over that one
Jan 21 01:09:32 <zmatt> but slots is at /sys/devices/platform/bone_capemgr/slots, not /sys/devices/platform/slots
Jan 21 01:09:35 <minnesotags> -bash: echo: write error: File exists
Jan 21 01:09:35 <minnesotags> '
Jan 21 01:09:50 <zmatt> then it's already loaded probably
Jan 21 01:10:28 <minnesotags>  0: PF----  -1
Jan 21 01:10:28 <minnesotags>  1: PF----  -1
Jan 21 01:10:28 <minnesotags>  2: PF----  -1
Jan 21 01:10:28 <minnesotags>  3: PF----  -1
Jan 21 01:10:28 <minnesotags>  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,cape-universaln
Jan 21 01:10:28 <minnesotags>  5: P-O-L-   1 Override Board Name,00A0,Override Manuf,BB-ADC
Jan 21 01:10:35 <zmatt> yup
Jan 21 01:10:54 <zmatt> so one of your earlier writes actually succeeded
Jan 21 01:11:24 <minnesotags> Ok, then I should be seeing AIN0 files somewhere.
Jan 21 01:11:34 <zmatt> they
Jan 21 01:12:16 <zmatt> they're not called exactly that, but there are similar files in the sysfs directory for the iio device
Jan 21 01:14:06 <zmatt> I think iio devices also show up as *actual* devices (/dev/iio*) for more efficient access, but I haven't yet explored how to use those
Jan 21 01:14:09 <minnesotags> Aha
Jan 21 01:14:51 <minnesotags> in_voltage0_raw, etc.
Jan 21 01:15:54 <zmatt> there ya go :)
Jan 21 01:16:04 <minnesotags> But it doesn't tail....
Jan 21 01:18:54 <zmatt> of course not, they're sysfs attributes
Jan 21 01:19:37 <zmatt> to re-read an attribute, seek to offset 0 and read again
Jan 21 01:19:53 <zmatt> (or close and reopen, but that's needlessly inefficient)
Jan 21 01:21:26 <minnesotags> Please explain "seek to offset0 and read again"
Jan 21 01:23:57 <zmatt> seek is system call on file descriptors and available in basically any sane programming language
Jan 21 01:25:07 <minnesotags> How about an insane programming language?
Jan 21 01:25:14 <zmatt> close and reopen
Jan 21 01:25:23 <zmatt> (e.g. in shell scripting you have no other choice)
Jan 21 01:25:56 <minnesotags> I would rather cat to a log file.
Jan 21 01:26:56 <zmatt> while cat in_voltage0_raw; do sleep 0.5; done >~/adc.log
Jan 21 01:28:29 <minnesotags> Sure. Just interesting devices aren't already mounted in /dev/
Jan 21 01:28:44 <zmatt> ?
Jan 21 01:29:06 <minnesotags> NM
Jan 21 01:29:21 <minnesotags> Thank you
Jan 21 01:30:55 <zmatt> it's useful to keep in mind that sysfs is really not a normal filesystem, it's a representation of a hierarchy of kernel objects and their attributes
Jan 21 01:31:58 <zmatt> reading or writing an attribute actually performs a call on a kernel object, in this particular case causing an adc measurement to be performed
Jan 21 01:32:36 <zmatt> that's why tail will never work, it tries to passively observe changes, but that will never happen
Jan 21 01:46:30 <stefan___> Hi guys, I am having a problem connecting a motor controller via Uart. I can see Tx messages and Rx responses in osziloscope, but I have no access to the responses in software
Jan 21 01:47:16 <stefan___> when reading from serial, it says the device is busy
Jan 21 01:47:32 <zmatt> stefan___: check if there's some other process hogging the port
Jan 21 01:47:38 <zmatt> my first thought would be a getty for example
Jan 21 01:48:22 <stefan___> good point, I will check :)
Jan 21 01:48:43 <zmatt> (you can use 'lsof /dev/ttySwhatever' to search for processes that keep it open)
Jan 21 01:49:17 <stefan___> no other processes
Jan 21 01:50:04 <zmatt> make sure to run lsof as root
Jan 21 01:50:43 <zmatt> (otherwise you probably only see your own processes)
Jan 21 01:52:56 <zmatt> if there's really no other process hogging the port then I'm not sure what could cause that error message... maybe something wrong with how you're using the device, dunno
Jan 21 01:53:01 <zmatt> we're using serial ports without issues
Jan 21 01:56:17 <stefan___> problem might be, that I have to use it in real asynchronous mode, as the motor controler just uses a shift register to push out the data
Jan 21 01:56:31 <stefan___> means: it pushes out bits when bits come in
Jan 21 01:56:52 <zmatt> that sounds more like spi than uart?
Jan 21 01:56:54 <stefan___> if I want to write 2 byte and read 2 byte, I have to transmit 4 byte
Jan 21 01:57:13 <zmatt> still doesn't explain any error from the device though
Jan 21 01:57:57 <stefan___> I already found some similar problems, but all solutions didn't work for me
Jan 21 01:58:40 <stefan___> I believe I will switch to another mc
Jan 21 01:58:57 <stefan___> already took me weeks
Jan 21 01:59:29 <stefan___> but its working, if I use a real embedded device, it works
Jan 21 01:59:44 <zmatt> what do you mean with "real embedded device" ? :P
Jan 21 02:00:08 <zmatt> can you share your code?
Jan 21 02:00:25 <stefan___> the plain hardware
Jan 21 02:01:09 <zmatt> what do you mean with "the plain hardware" ? :P
Jan 21 02:01:31 <zmatt> I'd love to help but you're really being too vague here
Jan 21 02:01:39 <stefan___> Infineon XMC4700
Jan 21 02:01:55 <stefan___> something linux is not yet ported to
Jan 21 02:02:23 <zmatt> what interface of that μC do you use/
Jan 21 02:02:26 <zmatt> ?
Jan 21 02:02:47 <stefan___> the spi/lin/uart interface in uart mode
Jan 21 02:02:56 <stefan___> transceive mode, which means sending and receiving
Jan 21 02:03:44 <zmatt> ok, so it is plain an uart interface.  that should work fine
Jan 21 02:04:05 <stefan___> yeah
Jan 21 02:04:21 <zmatt> note that if you're sufficiently desperate you can also just map an uart peripheral on the am335x and use its register interface directly, bypassing the kernel
Jan 21 02:04:50 <zmatt> but obviously it *should* also work fine via the kernel driver, it's being used all the time for all sorts of purposes
Jan 21 02:04:53 <stefan___> my current assumption is, that linux buffers output in any case and that somehow makes problems
Jan 21 02:05:20 <stefan___> ah, its the second processor on beagleboard?
Jan 21 02:05:46 <zmatt> there's some buffering all over the place, but I don't see how that matters
Jan 21 02:06:15 <zmatt> eh what?
Jan 21 02:06:30 <stefan___> sorry, its late here :)
Jan 21 02:06:33 <zmatt> wait, are you using a beagleboard or beaglebone?
Jan 21 02:07:38 <stefan___> it is beaglebone black
Jan 21 02:07:49 <zmatt> ok
Jan 21 02:08:06 <zmatt> what did you mean by "the second processor" ?
Jan 21 02:08:46 <stefan___> that was just my confusion. I have plenty of different boards here, and one of them has a coprocessor that can also be programmed
Jan 21 02:08:56 <stefan___> but after reading, it was not the beagleboen
Jan 21 02:09:44 <zmatt> there's only one SoC on the beaglebone, although it does have auxiliary cores embedded (two "PRU" cores for real-time applications and a cortex-m3 for power management)
Jan 21 02:10:42 <ddc> Hi everyone.  I'm dusting off my bbb I bought a couple (few) years ago.  Its only got the 2gb eMMC.  Is it possible to update the software?
Jan 21 02:12:02 <stefan___> zmatt - thanks so far, I believe I have to postpone further investigation until tomorrow
Jan 21 02:12:09 <stefan___> its too late
Jan 21 02:12:41 <zmatt> ddc: yes, although there's no prebuilt images with GUI, so your options are:  1. use the (minimal) console image,  2. download the iot image, shrink it to fit 2g (assuming it's still 4g for inexplicable reasons),  3. nag rcn-ee on the mailing list for 2g images
Jan 21 02:20:10 <ddc> thanks :)
Jan 21 02:21:00 <zmatt> ddc: or run from sd card, or hunt down the last 2g images (which are probably still a lot newer than what's on your bbb right now)
Jan 21 02:21:53 <ddc> I may try to run from an SD card.  I don't have anything smaller than 16gb laying around. are there any limitations size wise?
Jan 21 02:22:43 <zmatt> if you have a linux host system then shrinking a filesystem image is pretty easy btw, and given that the iot images are <300MB compressed they undoubtedly fit
Jan 21 02:23:25 <zmatt> not really, just try to avoid slow cards (unless you like slowness)
Jan 21 02:25:41 <ddc> awesome.  thanks for the help.
Jan 21 02:26:10 <zmatt> I personally don't like preinstalled crap though so I've always started with a console image
**** ENDING LOGGING AT Sat Jan 21 03:00:00 2017