**** BEGIN LOGGING AT Sat Jan 05 02:59:56 2019
**** BEGIN LOGGING AT Sat Jan 05 06:02:10 2019
Jan 05 06:32:55 <calicobrak_> I am trying to work on a BBB Cape... According to some documents I am reading, I need a EEPROM that supports 16bit addressing, is this indeed true?
Jan 05 06:33:24 <calicobrak_> I can't find a part that is still 'active' that supports this (thats not some special crypto type eeprom)
Jan 05 06:34:44 <zmatt> ehh what?
Jan 05 06:35:05 <zmatt> the eeproms used are basically the most common i2c eeproms you can find
Jan 05 06:35:27 <zmatt> afaik
Jan 05 06:35:44 <calicobrak_> hmmmm
Jan 05 06:37:26 <calicobrak_> I was thinking the difference between the 8 bit/16 bit addressing, is how much data is grabbed from the EEPROM during each read cycle
Jan 05 06:37:49 <calicobrak_> So if I don't have the correct one that they suggest, then things might not work properly... but maybe I am mistaken
Jan 05 06:38:07 <zmatt> just search for 24c256
Jan 05 06:38:19 <zmatt> 8-bit addressing means the eeprom can only be 256 bytes in size
Jan 05 06:38:58 <calicobrak_> So a 16 bit address then can get me double the memeory?
Jan 05 06:39:09 <zmatt> 16-bit address means the eeprom can be up to 64 KB
Jan 05 06:39:22 <calicobrak_> doesnt have to do about the amount of data it reads and writes at a given time frame?
Jan 05 06:39:29 <zmatt> no
Jan 05 06:39:33 <calicobrak_> yea, your right, one extra bit would be double the memory
Jan 05 06:40:15 <calicobrak_> okay, I was reading through the CAT24C256, and didn't see it reference 16-bit addressing...
Jan 05 06:40:39 <calicobrak_> but this tutorial, and also the offical BBB documentation do mention it
Jan 05 06:40:42 <calicobrak_> http://papermint-designs.com/community/node/331
Jan 05 06:41:12 <calicobrak_> https://github.com/beagleboard/beaglebone-black/wiki/System-Reference-Manual
Jan 05 06:41:14 <zmatt> it might not explicitly call it by that name, but it should show that the address uses two bytes
Jan 05 06:41:39 <zmatt> for an example, see figure 5-2 on page 8 of https://eu.mouser.com/datasheet/2/590/DS-RM24C256C-L_081-1385715.pdf
Jan 05 06:47:08 <calicobrak_> So this example you referenced uses 16-bit addressing then, right?Or is it considered 8-bit, since it sends 8 bits at a time?
Jan 05 06:47:29 <calicobrak_> A15 to A0 is the Address bits
Jan 05 06:47:58 <zmatt> it uses a 16-bit address
Jan 05 06:48:06 <calicobrak_> Gotcha
Jan 05 06:50:24 <calicobrak_> hmmm... So 24C256 is a standard part number made by multiple vendors?
Jan 05 06:50:28 <zmatt> yes
Jan 05 06:50:29 <calicobrak_> I have never heard of Adesto before
Jan 05 06:50:50 <calicobrak_> Is that the vendor the BBB uses?
Jan 05 06:50:53 <zmatt> neither have I, I just clicked on the first part I got in the search results
Jan 05 06:50:57 <calicobrak_> ahhh
Jan 05 06:50:58 <calicobrak_> gotcha
Jan 05 06:51:07 <calicobrak_> I was looking at a old microchip datasheet
Jan 05 06:51:14 <calicobrak_> I figured they were the only vendor
Jan 05 06:51:26 <calicobrak_> OnSemiconductor*
Jan 05 06:51:38 <zmatt> no there are tons of vendors
Jan 05 06:51:59 <calicobrak_> Ahhh, gotcha.  I wonder why I am not seeing any come up in digikey when I do a search then
Jan 05 06:52:08 <calicobrak_> I try to filter things down
Jan 05 06:52:23 <calicobrak_> Surface Mount Part + 16-bit addressing + I2C
Jan 05 06:52:34 <calicobrak_> and get not much for hits
Jan 05 06:52:47 <calicobrak_> Let me try again
Jan 05 06:52:48 <zmatt> just search for 24c256
Jan 05 06:52:55 <calicobrak_> k
Jan 05 06:53:37 <calicobrak_> Ohhhh.....
Jan 05 06:53:43 <calicobrak_> I had been filtering it wrong
Jan 05 06:54:05 <calicobrak_> 32k x 8 is what these 256kb ICs are
Jan 05 06:54:25 <calicobrak_> I was looking for 16 bit wide registers
Jan 05 06:54:32 <calicobrak_> or memory segments
Jan 05 06:54:40 <calicobrak_> however you would refer to it as
Jan 05 06:55:27 <zmatt> that's a misunderstanding of what it means
Jan 05 06:56:10 <zmatt> all i2c eeproms I know of are byte-addressable
Jan 05 06:57:12 <zmatt> 8-bit addressing would therefore imply the eeprom can only be 256 bytes in size, so a 32KB eeprom necessarily use 16-bit (or more) addressing
Jan 05 06:57:21 <calicobrak_> I think you have to send a 16 bit (2 byte) address all the time, but you get one byte of data per address
Jan 05 06:57:44 <zmatt> see datasheet for the format
Jan 05 06:58:02 <calicobrak_> Yea, I looked at it, it looks like it is alwyas a A15 - A0 format for the address
Jan 05 06:58:12 <calicobrak_> You cant just send A7-A0
Jan 05 06:58:28 <zmatt> but don't worry about too much about it: any "24c256" part that supports 3.3v operation is compatible
Jan 05 06:58:38 <zmatt> the compatibility is implicit in that part number
Jan 05 06:58:39 <calicobrak_> Okay, sweet.  THis is good to know
Jan 05 06:58:54 <calicobrak_> Okay, sweet.  Its good to know what some of this stuff means though
Jan 05 06:59:01 <calicobrak_> THank you for pointing me in the correct direction
Jan 05 07:02:17 <zmatt> 24c32 and larger are compatible basically, as seen from which parts have AT24_FLAG_ADDR16 in this list: https://elixir.bootlin.com/linux/latest/source/drivers/misc/eeprom/at24.c#L149
Jan 05 07:05:24 <calicobrak_> This is confusing
Jan 05 07:05:38 <zmatt> yeah I shouldn't have said that
Jan 05 07:05:51 <zmatt> just grab a 24c256 and don't worry about it
Jan 05 07:05:52 <calicobrak_> Sorry, I need to know this stuff though, right?
Jan 05 07:06:04 <calicobrak_> How to read the drivers and what not
Jan 05 07:06:06 <zmatt> not really?
Jan 05 07:06:10 <calicobrak_> Oh okay
Jan 05 07:06:11 <zmatt> I mean, if you want to
Jan 05 07:06:27 <calicobrak_> I am sure there is benifit in understanding it... or maybe not
Jan 05 07:06:28 <calicobrak_> idk
Jan 05 07:07:45 <calicobrak_> What is bootlin anyway?
Jan 05 07:08:11 <calicobrak_> Does this have all the drivers for one of the stock linux images
Jan 05 07:08:12 <zmatt> no idea, but elixir is a site that cross-indexes the linux kernel and some other projects
Jan 05 07:08:16 <calicobrak_> I see it talks about other ICs
Jan 05 07:08:28 <zmatt> what I linked to is the generic i2c eeprom driver
Jan 05 07:08:30 <calicobrak_> hmmm
Jan 05 07:08:46 <calicobrak_> Yea, I recalled the name they used in something I was reading yesterday
Jan 05 07:08:50 <calicobrak_> the "at24"
Jan 05 07:09:01 <calicobrak_> other than that, it is all foriegn to me
Jan 05 07:09:19 <zmatt> at24 is the name for the general family of i2c eeproms
Jan 05 07:09:26 <calicobrak_> ahhh
Jan 05 07:09:57 <calicobrak_> How does one determine from the datasheet what family or what driver that a device will fall into?
Jan 05 07:10:22 <calicobrak_> Do you have to read through the addressing and config of the status bits, etc to determine what drivers are compatable?'
Jan 05 07:11:22 <zmatt> in theory yes, but in practice all these eeproms are specifically made to be compatible with the original at24 chips, and show this by their part number
Jan 05 07:11:33 <zmatt> which is why you can just search for 24c256 and grab one from any vendor
Jan 05 07:11:34 <calicobrak_> oh
Jan 05 07:11:47 <calicobrak_> the 24 at the front, gotcha
Jan 05 07:12:08 <zmatt> 24c is not sufficient though, e.g. some smaller ones use 8-bit addressing
Jan 05 07:12:16 <zmatt> you also don't want the serial ones (24cs)
Jan 05 07:12:26 <calicobrak_> does the cs stand for something?
Jan 05 07:12:34 <zmatt> s = serial
Jan 05 07:12:42 <calicobrak_> okay
Jan 05 07:13:16 <zmatt> the beaglebone device tree declares the eeproms to be "24c256", so if you pick that part number then you're definitely safe
Jan 05 07:13:21 <calicobrak_> is there a over arching standard for these memory devices, or did one vendor create the 24Cxxx and everyeone copied?
Jan 05 07:13:29 <zmatt> pretty sure the latter
Jan 05 07:13:38 <zmatt> at24 sounds like atmel to me
Jan 05 07:13:47 <calicobrak_> gotcha.  wasn't sure if it something like ieee standards
Jan 05 07:13:53 <calicobrak_> yea, that sounds like atmel
Jan 05 07:20:28 <zmatt> ah actually the devicetree even says it: compatible = "atmel,24c256";
Jan 05 07:21:34 <zmatt> so yeah, the part is an atmel at24c256, or compatible clone
Jan 05 07:25:43 <calicobrak_> Oh, yea I see in the notes they mention Atmel AT24C or MicroChip 24LC
Jan 05 07:29:46 <zmatt> huh, this is odd
Jan 05 07:30:12 <calicobrak_> Whats odd?
Jan 05 07:30:17 <calicobrak_> The LC part?
Jan 05 07:30:52 <zmatt> not actually all 24c256 devices have three programmable device address bits
Jan 05 07:31:58 <zmatt> in particular, the original at24c256 didn't.  it could only be configured to device address 0x50 - 0x53, but the i2c eeprom of capes needs to be in range 0x54-0x57
Jan 05 07:33:38 <zmatt> I'm guessing all modern parts support configuration in range 0x50-0x57, but it doesn't hurt to double-check before making your final part selection
Jan 05 07:33:50 <zmatt> i.e. confirm it has an A2 pin
Jan 05 18:05:59 <BennyHyphen> Where can I find the docs to control the motor drivers on the beaglebone blue?
Jan 05 18:10:55 <wmat> BennyHyphen: dunno, but the Adafruit_BBIO can be used
Jan 05 18:12:47 <wmat> BennyHyphen: docs -> https://github.com/beagleboard/beaglebone-blue/tree/master/docs
Jan 05 18:43:58 <__jk__> I wish to use spi on my BBBW. Will config-pin utility as explained https://stackoverflow.com/a/43117267 work with latest kernel too ?
Jan 05 19:49:54 <set_> BennyHyphen: If you want, there is a librobotcontrol library for the BBBlue!
Jan 05 19:50:59 <set_> http://strawsondesign.com/docs/librobotcontrol/ and they have a github page too.
Jan 05 19:51:10 <BennyHyphen> Terrific, I'll take a look
Jan 05 19:51:32 <set_> Okay.
Jan 06 01:52:41 <mawk> hi
Jan 06 02:02:19 <mawk> I have a beaglebone black and I put the official debian image on it, and I'm trying to use what seems to be called SPI0 but I can't find my way among all the device tree overlay stuff. I used uboot overlays to enable BB-SPIDEV0 which was already in /lib/firmware and this thing also: https://elinux.org/images/1/1f/BB-SPI0-01-00A0.txt (which mentions the right pin names))
Jan 06 02:02:42 <zmatt> you don't need to mess with overlays at all
Jan 06 02:03:12 <zmatt> undo whatever you did in /boot/uEnv.txt and configure the pins using 'config-pin'
Jan 06 02:03:59 <mawk> ah
Jan 06 02:04:01 <mawk> I see, thanks
Jan 06 02:04:06 <zmatt> enabling the BB-SPIDEV0 overlay in /boot/uEnv.txt should also still work fine though
Jan 06 02:04:18 <mawk> yeah it didn't work
Jan 06 02:04:32 <mawk> no /dev/spidev0 appeared
Jan 06 02:04:38 <mawk> I'm trying config-pin
Jan 06 02:05:13 <zmatt> correct, for historical reasons spi0 ends up as /dev/spidev1.* and spi1 as /dev/spidev2.*
Jan 06 02:05:24 <mawk> ah !
Jan 06 02:06:50 <mawk> I see
Jan 06 02:07:04 <zmatt> on old kernels, a stupidity in the mcspi driver caused spidev devices used to be sequentially numbered 1-based in the order the kernel encountered them rather than following the numbering assigned to them by the device tree
Jan 06 02:07:38 <zmatt> this has been fixed, but people already relied on this broken numbering, so now it's explicitly preserved for compatibility reasons :/
Jan 06 02:08:42 <mawk> so the device tree overlay named SPIDEV0 makes /dev/spidev1 appear ?
Jan 06 02:09:20 <zmatt> yep
Jan 06 02:11:22 <zmatt> if this offends you as much as me, just grab the appropriate branch of the dtb-rebuilder project, fix these two lines, and recompile the dtbs: https://github.com/RobertCNelson/dtb-rebuilder/blob/4.14-ti/src/arm/am33xx.dtsi#L39-L40
Jan 06 02:14:32 <mawk> ok config-pin seems to be working
Jan 06 02:14:45 <mawk> now I just have some kind of alignment issue or whatever but I'll figure that out
Jan 06 02:15:04 <zmatt> alignment issue?
Jan 06 02:15:27 <mawk> I get wrong values every three SPI reads or something
Jan 06 02:16:04 <zmatt> that sounds odd. make sure the structure of the transfers you're doing matches the expectations of the device
Jan 06 02:16:32 <mawk> yeah this program was for a RPi at first and it works right there
Jan 06 02:16:40 <mawk> I just use the spidev interface, which is standard
Jan 06 02:17:34 <mawk> maybe bad cables
Jan 06 02:17:58 <zmatt> signal integrity is something to be mindful of
Jan 06 02:18:38 <zmatt> if wire length is substantial, you may want to include series resistors at the driving side of each line to avoid overshoot/ringing
Jan 06 02:19:21 <zmatt> especially on the clock line
Jan 06 02:19:36 <zmatt> since ringing on the clock line may be misinterpreted as additional clocks
Jan 06 02:19:37 <mawk> it's some "dupont" wires from amazon
Jan 06 02:19:41 <mawk> yeah
Jan 06 02:20:02 <mawk> I twisted the wires a bit and now it works consistently
Jan 06 02:20:14 <mawk> they're just badly made wires
Jan 06 02:20:18 <mawk> thanks for your help
Jan 06 02:20:19 <zmatt> lol
Jan 06 02:20:23 <zmatt> ok
Jan 06 02:22:54 <mawk> the ultimate goal is to enhance the RTEMS rtos
Jan 06 02:22:58 <mawk> on particular for the bbb
Jan 06 02:23:19 <mawk> I'm adding a 6lowpan stack with some mates
**** ENDING LOGGING AT Sun Jan 06 02:59:57 2019