**** BEGIN LOGGING AT Tue Jan 24 03:00:02 2017 Jan 24 03:46:47 Hello...are there any people in here messing with motors, the BBB, and python? Jan 24 03:48:06 I ask because of me using Python, the BBB, and the Motor Bridge Cape. I have sufficient software so far but I want to add to it. Jan 24 03:49:06 i.e. maybe a turn or two in the motor at a specific time would help. Jan 24 03:50:10 For instance...I can move the motors in forward, reverse, and stop but I cannot control one motor to turn at a specific point while the other motor does not turn. I need a 180 degree turn from one motor. Jan 24 03:52:08 ...Oh. Jan 24 03:52:52 I have a Motor Bridge Cape library to work from. Jan 24 07:16:33 hi all Jan 24 08:19:26 doeas TSC ADC allows you to get average samples? Jan 24 08:19:39 *does Jan 24 08:23:40 bbx15 - help with setup spi driver Jan 24 08:23:42 ? Jan 24 08:23:50 on ubuntu Jan 24 08:41:47 nt_: sorry, I have not experience with that : \ Jan 24 09:58:58 I'm having issues since I switched from BBW to BBB with SPI. flashrom almost always fails to find my SPI flash, only once this happened : "Found Macronix flash chip "unknown Macronix SPI chip" (0 kB, SPI) on linux_spi." Jan 24 09:59:54 which technically isn't even correct, since the chip is obv not 0kB Jan 24 10:00:28 I didn't have this issue when using BBW Jan 24 10:03:56 (showpins indicates the mux is correct for the pins i'm using) Jan 24 10:54:49 gquere: that sounds really odd Jan 24 10:57:12 zmatt: it got even odder in the meantime, I tested with yet another new flash chip from another manufacturer with the same pinout, it had the same behaviour initially, then I've been able to read/write Jan 24 10:57:54 so I tried writing zeros and read from again, initially (first few thousand bytes) are all zero indeed, and then it's interleaved with FF Jan 24 10:58:42 I was writing at 512Hz, trying at 64 now Jan 24 11:00:19 I did have a similar issue with BBW though Jan 24 11:04:18 which I attributed to the flash memory still being on a PCB with other stuff Jan 24 11:04:35 so it looks like it's about the BB Jan 24 11:05:57 this happens at 64Hz Erasing and writing flash chip... FAILED at 0x00000000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x00000fff: 0x3e Jan 24 11:10:38 here is my setup, really couldn't be any simpler : imgur.com/a/gOOmb Jan 24 11:11:49 that looks pretty trivial indeed Jan 24 11:12:18 we've used flash chips in a similar setup without any problems whatsoever Jan 24 11:13:02 maybe try using the spidev interface so you can give commands manually and see what's going on exactly, and check the datasheet if you're missing anything stupid Jan 24 11:13:27 yeah maybe I should ditch flashrom temporarily Jan 24 11:13:53 i'll re-check the DS but what could be special about a SPI flash chip ? :/ Jan 24 11:13:56 if the flash chip has HOLD or WP inputs, try tying those off instead of leaving them floating (even if they are supposed to have internal pull) Jan 24 11:15:19 ah yes those I deemed useless Jan 24 11:21:30 they may be, but unless tied to vdd or gnd you may be using them accidently :) Jan 24 11:26:23 ah yesn seems like that was it, both reset and WP had to be driven high Jan 24 11:26:29 zmatt: thanks! Jan 24 11:31:43 https://liktaanjeneus.nl/flash-utils.tar.xz see if this is one any use... you'll probably need to tweak the code since I wrote this for flash of a specific manufacturer (and I check this during init to verify the connection is working ok) but at least it's known-working Jan 24 11:31:51 *of any use Jan 24 11:32:45 ah you solved it already Jan 24 11:32:48 nm then :) Jan 24 11:33:50 ah thanks for the effort :) Jan 24 11:34:19 in order to sample with the onboard ADC (i.e. TSC ADC) is it enought to configure one step (e.g. STEP1)? Jan 24 11:35:19 yes Jan 24 11:35:27 at least, if you want to sample one input Jan 24 11:36:24 (if you use it in a "one-shot" fashion (i.e. not continuous sampling) then you can change the config after each time of course, hence sample different inputs successively) Jan 24 11:40:10 roger that, thank you! So, if I'd like to do a "one-shot", I configure a step (e.g. step1), and then enable the sampling via CTRL_Register. Then, I go to read the first element of target fifo. Am I right? Jan 24 11:40:59 yes, or afaik you can even leave it enabled but only enable the step after configuring Jan 24 11:41:38 so, enable the sampling and then enable the step, right? Jan 24 11:42:39 KotH: (late reaction) subarctic is the am335x/dra60x/dra61x, aegis is the am437x Jan 24 11:42:47 lore4: I think either order will work Jan 24 11:43:00 zmatt: top, thank you! Jan 24 11:43:35 in continous mode, it will be the same, but the ADC will fulfill the fifo with the samples. right? Jan 24 11:44:06 presumably a non-continuous step will self-disable after sampling (never tested this, I just use continuous sampling), while the adc's global enable needs to remain on until you've read the data since clearing it will clear the fifo Jan 24 11:44:38 in continuous mode the step remains enabled hence it'll get sampled again and again Jan 24 11:46:10 I use it in combination with EDMA which copies the data to a fixed location in SRAM, allowing software to read the latest values from there whenever they want Jan 24 11:46:54 zmatt:therefore, if in one-shot, then adc sampling must be enabled each time (i.e. sample). If in continous, then sampling must be enabled until samples are read, otherwise it will clear the fifo Jan 24 11:47:53 zmatt: I recall that in your code there was the DMA address, I believe that is due to the use of such values in ARM, right? Jan 24 11:47:59 no, the adc global enable needs to remain enabled until you've read the data in both cases Jan 24 11:48:11 O.o Jan 24 11:48:40 to disable sampling you disable the step (register at offset 0x54) Jan 24 11:48:57 a non-continuous step will disable itself there afaik Jan 24 11:49:00 uhm.. so each time in one-shot mode -> Enable sampling -> Read sample from FIFO -> Disable Sampling Jan 24 11:49:36 not the enable bit at address 40h.0? Jan 24 11:50:03 that enable-bit is the global enable for the adc, you can leave it enabled the whole time if you want Jan 24 11:50:35 ok Jan 24 11:50:46 so, which bit has to be 1 untill FIFO is read? Jan 24 11:51:05 that bit needs to remain on until the fifo is read Jan 24 11:51:18 global enable? Jan 24 11:51:46 yes, it *needs* to be enabled until you've read your data since disabling it clears the fifo Jan 24 11:52:05 perfect! Hence I stop sampling via "step enable" Jan 24 11:52:14 you *may* disable it once the adc is completely idle and no more relevant data is in the fifo Jan 24 11:52:39 yes, though for a one-shot step I think that will happen automatically Jan 24 11:52:52 roger! thank you zmatt Jan 24 11:53:17 after lunch, I finish to write the structures in the header and try to saple a bit :) Jan 24 11:53:25 *sample Jan 24 11:53:57 pay attention to the comment in lines 134-135 in my header :) Jan 24 11:54:05 uhm.. Jan 24 11:54:19 -> https://hastebin.com/xiqocipazo.cc ? Jan 24 11:54:33 (that one I learned through experience, I previously managed to get the adc completely locked up) Jan 24 11:54:50 yes Jan 24 11:55:01 thank you, I did not read that note Jan 24 11:55:23 btw, how did you learn all such things? Did you follow a some course from TI? Jan 24 11:55:41 no, Jan 24 11:55:48 I just read the TRM and fiddled with it a bit Jan 24 11:56:17 wow... all 5k pages? Jan 24 11:56:26 zmatt: ah.. thanks! Jan 24 11:56:41 hehe, I meant the relevant chapter of the TRM Jan 24 11:56:48 which is all of them Jan 24 11:56:50 ;) Jan 24 11:56:53 lol Jan 24 11:56:55 congrats! Jan 24 11:56:59 although by now i probably have at least browsed most of the TRM Jan 24 11:57:34 some of it is just filler though... like writing an explicit register description for each element in an array of 32 registers (all identical) Jan 24 11:59:00 still, congrats ;) Jan 24 11:59:05 my suggestion for the TRM would be: every now and then, pick some random chapter you're not familiar with and read its introduction, skip or skim the integration, and browse the functional description Jan 24 11:59:24 so you at least know what functionality is there Jan 24 11:59:46 +1 Jan 24 11:59:48 I'll definitely follow your advice ;) Jan 24 11:59:53 then when you need some of that functionality or you're just curious, dig deeper Jan 24 12:00:08 that's actually how i evaluate whether i want to use a specific cpu/mcu Jan 24 12:00:33 read all introductions of the chapters, look at the functional diagrams and skimm over the functional descriptions Jan 24 12:00:51 not everything necessarily has a good diagram though Jan 24 12:00:54 after that i usually have a quite good idea what the cpu/mcu does and what it doesnt Jan 24 12:01:01 yes Jan 24 12:01:11 fsl is famous for their shitty RM's Jan 24 12:01:19 lol Jan 24 12:01:29 see you later folks, gtg lunch Jan 24 12:01:34 en guete! Jan 24 12:01:35 but it's definitely a better way to learn a device than reading the marketing fluff ;) Jan 24 12:02:39 KothH: Danke dir auch! Jan 24 12:03:45 KotH: the reason I generally prefer the codenames (when I know them) btw is because they're simply a superior way to identify dies: names are memorable and easily distinguished, while TI tends to assign several completely different part numbers to the same SoC (with different parts eFUSEd out and/or targeting different market segment) while completely different SoCs can end up having confusingly similar Jan 24 12:03:51 part numbers Jan 24 12:04:16 e.g. the am335x is not remotely related to the am35xx Jan 24 12:04:18 zmatt: true... i just am not in the know... so i cannot always map names to parts Jan 24 12:04:56 beside... i still don't own any of the beagle borads Jan 24 12:05:35 https://goo.gl/TQcqDV Jan 24 12:07:50 lot of info missing still, but this is where I occasionally gather info I know :) Jan 24 12:08:22 (you can ignore the USCIF tab, that's CCS-specific info) Jan 24 12:28:13 * KotH wonders whether zmatt has some ODC or just a swiss-like diligence Jan 24 12:28:54 :) Jan 24 12:28:54 likely just a well-trained neural deep-learning network Jan 24 12:31:13 KotH: I can't really recognize myself in the description of OCD, even though I can sometimes be a bit obsessive in "collecting" info on a topic I'm sufficiently interested in Jan 24 12:31:53 zmatt: ie you are just a regular geek :) Jan 24 12:32:00 possibly yes ;) Jan 24 13:16:15 zmatt: nice sheet file ;) Jan 24 13:17:40 lore4: well, if you like spreadsheets... https://goo.gl/Jkcg0w https://goo.gl/UHF2Fy ;) Jan 24 13:23:22 zmatt: that's an impressive work! :O Jan 24 13:24:37 yea they're okay, could be better Jan 24 13:25:35 i cannot imagine how long you worked on those Jan 24 13:26:31 fortunately, I have no idea either Jan 24 13:26:56 hence I can enjoy the results without feeling like I've wasted time on it Jan 24 13:28:24 definitely, it is not a wasted time, as if you needed probably also many other persons need and / or will need them Jan 24 13:28:47 still, thanks for such work! Jan 24 13:29:14 the pins spreadsheet I definitely reference a lot Jan 24 13:29:33 especially the P9/P8 overview charts Jan 24 13:32:33 yep, also the bbb page I would guess Jan 24 13:33:08 I start to believe that you use a lot of TI dies on your job! Jan 24 13:33:19 *TI producs Jan 24 13:33:25 just beaglebones really Jan 24 13:34:24 and dm814x-based designed whose prototype board is on a shelve somewhere, buried under a thick layer of dust Jan 24 13:34:29 *design Jan 24 13:34:33 *shelf Jan 24 13:34:34 jeez Jan 24 13:35:15 don't worry, I am not a native speaker as well as you, I guess ;) Jan 24 13:36:05 that's not an excuse for my hands typing the wrong thing :P THEY ARE DISOBEYING ME Jan 24 13:36:08 ;) Jan 24 13:36:21 lol Jan 24 13:37:26 no custom sitara boards? Jan 24 13:38:42 what the hell is a "sitara board" ? :P sitara is a marketing term for a collection of essentially unrelated SoCs Jan 24 13:39:47 then AM3358 :P Jan 24 13:40:18 I would add "sitara" to the code names spreadsheet :P Jan 24 13:41:03 ehm, the spreadsheet shows the names of specific dies, while sitara is a meaningless marketing term Jan 24 13:42:24 but no, no custom am335x-based board yet, though I expect that's a matter of time Jan 24 13:44:00 zmatt: I was joking ;) Jan 24 13:44:26 great! Jan 24 13:50:15 zmatt: ok, I finished the structs... I wrote two of them on your StepBase and Step, structure. Is it an issue? I start to test some read... finger crossed Jan 24 13:51:42 yes, terrible issue, that's why I shared it ;P Jan 24 13:53:22 lol... don't worry, I mentioned the base author in comments Jan 24 13:55:19 just to be sure in continous: 1. config control register (i.e. 0x40) and enable sampling; 2. config step (0x64); 3. enable step (0x54); 4. wait until fifo0count != 0 (0xe4); 5. read value from fifo0data Jan 24 13:56:01 when done: clear step enable; clear step config; disable sampling. Jan 24 13:56:12 did I understand correctly? Jan 24 13:58:02 lore4: I can also recommend setting bit 2 of the control register before configuring the step ;) Jan 24 13:59:29 there's no need to clear the step config obviously, in fact "clearing" it is merely a form of reconfiguration since all-zeros is a perfectly valid step config Jan 24 14:01:11 zmatt: do you mean Step_id_tag = 1 by setting bit 2? Jan 24 14:01:33 no since that's bit 1 Jan 24 14:01:59 ok, then STEPCONFIG_WRITEPROTECT_N_ACTIVE_LOW Jan 24 14:02:15 lol is that the official name? wow that's horrible Jan 24 14:02:26 but yes Jan 24 14:02:28 lol it is the official one Jan 24 14:02:36 taken from TRM Jan 24 14:03:00 roger that, thanks ;) Jan 24 14:04:01 apparently it didn't occur to them to call it ALLOW_STEPCONFIG_WRITES or something Jan 24 14:04:39 too simple Jan 24 14:06:23 maybe it was described as "stepconfig WRITEPROTECTn (active low)" somewhere or something and someone just turned that into an identifier Jan 24 14:09:17 that's clever, so everything is coherent :P Jan 24 14:09:35 *everywhere it is coherent Jan 24 14:09:36 the people who actually produce docs aren't necessarily always paying attention to what they're doing... https://liktaanjeneus.nl/iirc.png Jan 24 14:10:10 O.O Jan 24 14:10:55 it is also true that all people makes mistakes : \ Jan 24 14:10:59 true Jan 24 14:12:20 I did in my papers... also if they were few pages (i.e. not 5044) and with several time spent on reading them T.T Jan 24 14:13:19 uhuh, having other people proofread it can help Jan 24 14:14:03 although it's perfectly possible for a whole bunch of people overlooking "obvious" problems Jan 24 14:15:44 e.g. I remember a prototype for some embedded system whose schematics had been checked by several people (myself included), yet one of the uC supplies was connected to the wrong voltage (there went the magic smoke...) and the RAS and CAS lines of the ram were swapped Jan 24 14:16:33 these are things someone with no understanding of electronics could have noticed simply by comparing the net label to the pin label Jan 24 14:16:40 ... and yet... Jan 24 14:17:58 anyway, stuff to do, afk Jan 24 14:20:03 zmatt: don't worry, I am coding ;) Jan 24 14:21:37 zmatt: lol, look at the bright side of the experience, now you take a look at the pin label :D Jan 24 14:23:50 as well as, now I let at leaast 5 people to proofread xD Jan 24 14:23:57 *least Jan 24 14:54:28 I remember a colleague drilling a hole into a prototype pcb to cut a trace on an inner layer that connected two nets that weren't supposed to Jan 24 15:04:16 thinkfat: lol Jan 24 15:09:02 i am reading a strange value from ADC Jan 24 15:09:11 i.e. 746 Jan 24 15:36:10 ever heard of JTAG re-enabling on a chip? seems strange to me ... Jan 24 15:50:08 gquere: sorry, I did not : \ Jan 24 15:50:59 gquere: more context? Jan 24 15:55:47 I don't have a lot of context on this, just a discussion I had with a colleague someone told him it's possible for some chips to re-enable JTAG after it's been explicilty disabled Jan 24 15:55:57 never heard of this, it's usually a fuse IIRC Jan 24 15:56:19 OTOH it's a very special gemalto chip he was mentioning I don't have the datasheet for that p: Jan 24 15:56:22 :p Jan 24 15:59:13 there are some chips with a "secure jtag controller", like, iMX6, where you can disable jtag by blowing a fuse, but re-enable the jtag by doing some challenge-response game with the controller Jan 24 16:00:22 so it's not completely disabled of course, just the interesting taps are hidden until you unlock them Jan 24 16:02:15 usually you can access a certain register on the controller which provides you with a challenge, and you have to write the proper response into the same register, based on a shared secret Jan 24 16:02:56 I am sampling from TSC ADC, but my fifo count stays = to 0, and the first element in fifo queue has value 456 (i.e. not what I shoud have) Jan 24 16:03:18 anyone had the same odd experience? Jan 24 16:07:20 thinkfat: thanks, will look into that Jan 24 16:42:11 zmatt: I am having issue in reading the samples... I committed the current version on the repository https://github.com/lore4/TSCADCss . However, the fifo0count stays = to 0, and fifo0data[0] = to 456. Jan 24 16:42:19 bye to all Jan 24 16:45:23 Hi! Is there a way I can determine if my BBB is rev B or rev C? I am facing problems with flashing the board. Jan 24 17:09:13 check the size of the emmc Jan 24 17:10:25 gquere: there are TI SoCs where jtag access can be locked with an access code Jan 24 17:10:35 TI uCs I mean Jan 24 17:11:51 on SoCs like the am335x access to JTAG is controlled through a control module register, so if there are versions which disable it by default then I can easily imagine there might be a software-controlled way to reopen it Jan 24 17:12:09 (although the register can also be locked) Jan 24 17:15:12 zmatt: fdisk -l should do the trick? Jan 24 17:15:36 carpediem_: no, that displays the partition map Jan 24 17:17:10 lsblk Jan 24 17:17:57 should show something like 3.7G for the disk for rev C Jan 24 17:20:52 zmatt: It says 1.8G for mine. Jan 24 17:20:57 then it's rev B Jan 24 17:21:15 Sure it's a rev B or a Rev A? Jan 24 17:21:33 yeah I meant rev A/B sorry Jan 24 17:21:42 zmatt: Thank you for the help. Jan 24 17:21:47 you can actually also check the eeprom Jan 24 17:22:08 Rev B means I can flash only 2GB images, right? Jan 24 17:22:47 yeah, so the latest lxqt images won't fit, the console images will fit, and the iot images should fit if you resize them Jan 24 17:26:52 * zmatt does a facepalm while reading lore4's code... Jan 24 17:42:37 heh, nice... "The kind of stuff that was going on behind the scenes made me once and for all decide to never have anything to do with the FSF again. So if you want to give money to an organisation that does good, give it to the EFF. The FSF is full of crazy bigoted people... that's just my opinion." -- Linus Torvalds Jan 24 17:43:08 (he Jan 24 17:43:18 (he's a bit kinder to them when more context is taken though ;) Jan 24 18:08:31 ...what Jan 24 18:14:39 https://www.youtube.com/watch?v=PaKIZ7gJlRU Jan 24 18:19:36 I fully agree with him that the FSF made a really loathesome move with that they did with GPLv3, misusing the trust people gave them when using "GPLv2 or later" as license Jan 24 18:47:36 zmatt: GPLv3 is superior to GPLv2 in every way. and it was drafted in an _open_ and _public_ process, so no misuse was even possible Jan 24 18:47:43 zmatt: please don't spread FUD Jan 24 18:48:03 zmatt: at the very least get your facts right Jan 24 18:49:26 the first is nonsense, superiority is a subjective thing and for example linus makes it very clear he prefers the GPLv2 for linux (while acknowledging other people may perhaps prefer the GPLv3 for their projects) Jan 24 18:49:39 how it was drafted is largely irrelevant Jan 24 18:50:17 the point is that it's a different license, pushed through a mechanism of force that should never have been used for anything other than bugfixes in the legalese Jan 24 18:51:51 and really, how on earth am I "spreading FUD" ? Jan 24 18:53:39 zmatt: GPLv3 was written by the people who use it in an open process. if you like proprietary software that's, fine, but please don't accuse the FSF of doing something they did not; that's FUD Jan 24 18:54:18 zmatt: if you want to give people the freedom to sell others locked down hardware, that's your choice. but it isn't mine Jan 24 18:54:25 you are arguing a point that I don't contest (but don't see the relevance of) and are putting words in my mouth that I didn't say Jan 24 18:55:01 and yes, I fully acknowledge people's choice of selling limited hardware. if they don't claim you can do X or Y with it, then you can't complain if indeed you can't Jan 24 18:55:12 if you don't like limited hardware, don't buy it Jan 24 18:56:13 I also fully acknowledge that some people may not like if their software is used as part of such devices, and that the GPLv3 is then a Good Thing for those people Jan 24 18:56:20 for their software Jan 24 18:56:23 by their choice Jan 24 18:56:32 zmatt: that's where we disagree, and that's why I am a proponent of the protections in GPLv3 and you are not. disagreeing on a specific point it fine. what I don't want is nebulous accusations Jan 24 18:56:35 which they get to make since they wrote the software Jan 24 18:56:49 I didn't make any nebulous accusation, I was very specific Jan 24 18:57:16 zmatt: let me quote you: "the FSF made a really loathesome move with that they did with GPLv3, misusing the trust people gave them when using "GPLv2 or later" as license " Jan 24 18:57:24 zmatt: how is that "very specific"? Jan 24 18:58:17 you neglected to include the "I fully agree with him", referencing the video I linked to immediately before Jan 24 18:58:19 zmatt: instead of saying "I'm a fan of this specific restriction" you accuse the people who are against restrictions of betrayal. Jan 24 18:58:36 the statement wasn't about specific restrictions Jan 24 18:58:43 nor even about the merits of the GPLv3 vs the GPLv2 Jan 24 19:00:39 it was about the fact it was published as GPLv3, hence putting it on the "upgrade path" for projects licensed as "GPLv2 or later", even though the difference between it and GPLv2 are as significant as the differences between the GPLv2 and the LGPL Jan 24 19:00:53 it's a different license Jan 24 19:01:01 with different restrictions Jan 24 19:01:15 that people who chose the GPLv2 may not like at all (see e.g. linux) Jan 24 19:01:30 zmatt: and therefore they have the freedom not to upgrade Jan 24 19:01:52 zmatt: but that's not good enough for you? Jan 24 19:02:09 and lose the ability to integrate changes made by people, if those people chose to take the upgrade-clause, thereby undermining the one thing that the GPLv2 was supposed to guarantee Jan 24 19:02:14 zmatt: also, these so called "restrictions" are called "protections" in my book. Jan 24 19:02:37 zmatt: any two copyleft licenses, GPL or not, are by definition mutually incompatible Jan 24 19:03:49 .... and? Jan 24 19:04:14 zmatt: people are given freedom to upgrade if they want and not if they don't; I'm amazed that you manage to find something to complain about in that, and then assign malice to it Jan 24 19:04:37 did you read at all what I just said? Jan 24 19:04:42 zmatt: do you also hate the new MPL for now being GPL-compatible? Jan 24 19:05:29 and do you think your case is improved by making random claims about what I might like or hate, unrelated to the subject? Jan 24 19:06:10 anyway, since you're trolling rather than discussing, I'm not going to put further energy into this Jan 24 19:06:21 zmatt: GPLv3 is compatible with _more_ licenses than GPLv2. how so your claim of being restricted in your ability to integrate changes is factually wrong Jan 24 19:06:36 zmatt: apache 2.0 comes to mind Jan 24 19:07:51 zmatt: I'm fine with dropping it too. I just have to jump in which I see someone stomping on a group that doesn't have a voice, and are often less popular to defend. Jan 24 20:23:50 Has anyone get the bootlogo on 4.4 kernel Jan 24 23:40:20 The beagle board xM looks nice but there are no expansion boards for itI'. I assume it's a 32bitter? **** ENDING LOGGING AT Wed Jan 25 03:00:01 2017