| 00:00.10 | bencoh | and the "host" part is 64b-wide |
| 00:00.15 | kerio | the public ipv6 addresses have 3 bits set |
| 00:00.29 | kerio | so that's 125 bits |
| 00:00.38 | Humpelstilzchen | bencoh: if linux open a shell type ifconfig and check your ipv6, you should have at least a local ipv6 containing your mac |
| 00:01.02 | bencoh | the MAC-address thing comes from the EUI-64 mechanism to create a 64b host address from the 48b MAC address |
| 00:01.13 | bencoh | s/create/construct/ |
| 00:01.28 | Humpelstilzchen | yes, but its the same for all addresses |
| 00:01.34 | kerio | no it's fucking not |
| 00:02.00 | Humpelstilzchen | doesn't matter if global, mobile or anything |
| 00:02.25 | bencoh | Humpelstilzchen: it's not really an IPv6 requirement |
| 00:02.36 | kerio | that's link-local addressing for NICs with a MAC |
| 00:02.55 | Humpelstilzchen | bencoh: but its used everywhere |
| 00:03.01 | bencoh | Humpelstilzchen: EUI-64 specifies a way to have "non-universal" host address |
| 00:03.19 | bencoh | by just flipping a bit you can say that the address does not respect EUI-64 |
| 00:03.32 | bencoh | which would still leave 63b for a host address ;) |
| 00:03.42 | bencoh | (for a non-universal one, I mean) |
| 00:04.17 | bencoh | and we're talking about the whole address space anyway, not the way they get attributed :) |
| 00:12.56 | Humpelstilzchen | bencoh: EU-64 seems to be only 64 bit |
| 00:24.13 | *** join/#neo900 Oxyd76 (~quassel@gateway/tor-sasl/oxyd76) |
| 00:24.22 | Steven__ | Back. |
| 00:25.31 | Steven__ | IPv6 is just enough to put a public key fingerprint in and still be secure. =) |
| 00:25.50 | Steven__ | (losing the nice properties for routing though) |
| 00:26.46 | kerio | rofl |
| 00:27.00 | kerio | just bruteforce keys until the prefix matches |
| 00:27.05 | kerio | ez |
| 00:27.13 | Steven__ | No, all of the address. |
| 00:27.26 | kerio | no, i mean |
| 00:27.26 | Steven__ | Some virtual networks use the address that way. |
| 00:27.51 | kerio | bruteforce keys to match the prefix |
| 00:27.51 | Steven__ | The whole 128b is used as the fingerprint. |
| 00:28.04 | kerio | and set the host part appropriately |
| 00:28.59 | Humpelstilzchen | but the first bits are needed for routing? |
| 00:29.57 | Steven__ | Humpelstilzchen: That why it is only used on some virtual networks. |
| 00:30.34 | Steven__ | I have seen it on some anonymity networks. |
| 00:30.45 | Humpelstilzchen | and I thought the whole point of ipv6 was to have a global unique address ;) |
| 00:31.09 | Steven__ | It is. But it is no longer useful for routing because it doesn't correspond to physical location. |
| 00:31.36 | Steven__ | So the use case is when you need to address computers where you don't know where they are, like on an anonymized network. |
| 00:58.51 | *** join/#neo900 phre4k (~phre4k@55d4335e.access.ecotel.net) |
| 01:31.57 | Oksana | Moin. ((the true mirror app is the one that switches the screen to black ;-P )) True. |
| 01:37.08 | bencoh | :)) |
| 01:54.11 | *** join/#neo900 phre4k (~phre4k@55d4335e.access.ecotel.net) |
| 01:57.00 | DocScrutinizer05 | nice guys over at devuan :-) |
| 01:58.19 | DocScrutinizer05 | moin Oksana |
| 01:58.55 | Oksana | Moin :-) |
| 03:16.20 | DocScrutinizer05 | wpwrak: hey, I proceeded in reading the NFC whitepaper and it seems you and me are 100% on same page: http://privatepaste.com/919fa57f97 |
| 03:17.20 | DocScrutinizer05 | just to remarks: the user visible effects are tolerable and the impact on IRQ handling dealy is expected to be negligible in an OMAP system |
| 03:17.33 | DocScrutinizer05 | just two* |
| 03:26.36 | wpwrak | (expected and negligible) if you say so :) i don't know. |
| 03:28.42 | wpwrak | based on my experience, getting this right (i.e., without causing stray system upsets) will be quite a lot of work for the poor soul who implements and debugs it |
| 03:29.24 | wpwrak | not to mention maintenance. because new kernels may come with new code that doesn't expect this kind of mistreatment |
| 03:36.59 | wpwrak | hence my preference of an MCU to do such things: there you can screw around as much as you want - the worst the kernel can see from this is a communication timeout. nice and easy. |
| 03:55.15 | DocScrutinizer05 | to make your day, you almost sold that MCU to me when I looked at that mux mess needed to use TI's NFC chip special modes |
| 03:55.55 | wpwrak | yeah, i thought that would be rather convincing ;-) |
| 03:56.17 | DocScrutinizer05 | then I read about SWD and flash fusing and I thought it needs a lab breadboard PoC for that whole stuff, incl the mentioned I2C bootloader |
| 03:56.49 | wpwrak | PoC ? |
| 03:56.51 | DocScrutinizer05 | and I see only one person doing this |
| 03:56.59 | DocScrutinizer05 | Proof of concept |
| 03:57.42 | DocScrutinizer05 | unbrickability is an absulte must for that stuff |
| 03:57.54 | DocScrutinizer05 | absolute* |
| 03:57.58 | wpwrak | oh, i think making a prototype of that subsystem would be a very good idea - a lot easier to make changes on a two-chip board than fiddling with a neo900 |
| 03:58.15 | wpwrak | (unbrickability) hence the i2c boot loader |
| 03:58.32 | DocScrutinizer05 | you already wrote that one? |
| 03:59.02 | wpwrak | no, but i've written boot loaders before :) |
| 03:59.15 | DocScrutinizer05 | another headache: clock from NFC chip |
| 04:00.23 | wpwrak | and i have a bunch of kl26 here at home, neatly arranged on a pcb, ... picture: http://downloads.qi-hardware.com/people/werner/anelok/tmp/kltab-pgm.jpg |
| 04:00.37 | DocScrutinizer05 | I don't see the NFC chip delivering stable clock out of power on reset, to bring up MCU to configure NFC chip |
| 04:01.20 | wpwrak | the NFC chip could do that (it's designed to be able to provide the only clock of an MCU), but we don't need that |
| 04:01.48 | wpwrak | the MCU has internal clock sources it can use while the NFC chip is down |
| 04:02.16 | DocScrutinizer05 | ok, but does it do that, unconditionally? |
| 04:02.42 | DocScrutinizer05 | i.e. how does MCU itsown POR? |
| 04:02.59 | DocScrutinizer05 | which is the clock source after POR? |
| 04:03.18 | wpwrak | in the case of the kinetis critters, on POR they run off an internal RC oscillator |
| 04:03.30 | DocScrutinizer05 | ooh, fine! :-) |
| 04:03.46 | DocScrutinizer05 | then nevermind my comment about clock |
| 04:04.23 | wpwrak | yeah, clock source is not a problem. clock switching is a different story, but i've already figured out that mess for anelok :) |
| 04:06.19 | wpwrak | (i2c boot loader) e.g., after reset, it could just sit there waiting for either a firmware update or a "go ahead and boot" command from the main CPU. |
| 04:06.49 | DocScrutinizer05 | the comparator sounds a tad, err, odd to me yet. I'd love to have an analog comparator that probes volatge across the shunt-R |
| 04:07.58 | DocScrutinizer05 | but maybe I'm just over sceptical |
| 04:09.54 | wpwrak | hmm. i have a work-in-progress document about the kinetis flash security architecture. lemme check if that may be useful here ... well, sufficient for a quick idea: http://downloads.qi-hardware.com/people/werner/anelok/tmp/klsec-20141005.pdf |
| 04:11.40 | wpwrak | you mean having the shunt between + and - ? i thought of that, too, but doesn't the offset voltage go both ways ? i.e., if CMP+ == CMP-, the result is undefined ? (which would basically be the case when the SIM doesn't try to send something) |
| 04:12.32 | wpwrak | (klsec) the interesting bit if section 3: the write protection. the other sections are about the bricking feature we don't want :) |
| 04:13.13 | DocScrutinizer05 | has SWD a certain minimum clock freq.? |
| 04:13.57 | wpwrak | no, you can go as slow as you want |
| 04:14.42 | wpwrak | and you can hold the CPU in reset throughout all this. so there's no race against code execution |
| 04:14.57 | DocScrutinizer05 | (offset) of course a comparator needs proper bias to define operation point aka threshold. And it needs proper positive feedback (out -> +in) to define hysteresis |
| 04:15.37 | DocScrutinizer05 | (SWD) fine, so this goes to I2C-extender |
| 04:15.43 | wpwrak | so that would then be a general opamp, not a comparator ? |
| 04:16.36 | DocScrutinizer05 | well, there's not really a difference between a comparator and an opamp. Except for output which is digiatl for comparator but analog by design for an opamp |
| 04:16.53 | wpwrak | (SWD) yes, and i'd add some sort of jumper because bypassing the boot loader with SWD would allow you to brick the chip |
| 04:17.18 | wpwrak | for bias, you'd need an analog output, right ? |
| 04:17.25 | wpwrak | err, feedback |
| 04:17.43 | DocScrutinizer05 | oooh not even swd allows full flash erasure? |
| 04:18.05 | DocScrutinizer05 | for bias you don't need output |
| 04:18.22 | wpwrak | you can configure the chip to ignore any attempt of modification |
| 04:18.25 | DocScrutinizer05 | bias is a voltage offset you feed to either of the inputs |
| 04:18.51 | wpwrak | i wish they had some "fuse" that would make the chip ignore any attempt to make it ignore any attempt of modification. alas, that's not there. |
| 04:19.05 | DocScrutinizer05 | (ignore) wtf did they smoke? |
| 04:19.16 | wpwrak | and i looked at several other ARMs and they all have the same scenario, though with different mechanisms |
| 04:20.26 | DocScrutinizer05 | what's the RAM size available for program text on that critter? |
| 04:21.02 | DocScrutinizer05 | since I'm tempted to say, when it can get fused, we need to fuse it |
| 04:21.04 | wpwrak | (ignore) i've already been bitten by it: flashed mis-structured firmware that then locked me out for good :-( lesson learned: my flasher now refuses to set that certain bit pattern |
| 04:22.34 | wpwrak | of course, the boot loader would never touch that area. in fact, one would simply (reversibly only by SWD) protect it against changes. |
| 04:22.50 | DocScrutinizer05 | write your I2C bootloader, debug it thoroughly, flash it to the shi(T)p, and that's it. The rest is firmware upload on boot into RAM |
| 04:22.58 | wpwrak | so you'd only need SWD if you want to change the I2C boot loader. in practical terms, that would be never. |
| 04:23.05 | wpwrak | exactly :) |
| 04:23.33 | wpwrak | (never) that is, only during production. |
| 04:23.52 | DocScrutinizer05 | that's the way |
| 04:24.18 | DocScrutinizer05 | we don't offer reflashing of the MCU flash |
| 04:24.24 | DocScrutinizer05 | it's immutable |
| 04:24.50 | DocScrutinizer05 | it comes with an I2C BL (C)w.Almesberger |
| 04:25.19 | wpwrak | RAM and Flash size depend on which chip we use. the kl26 i have go up to 128 kB Flash and 16 kB RAM |
| 04:25.57 | DocScrutinizer05 | well, you need to get along with 16kB memory for program text and data then |
| 04:26.03 | wpwrak | if we use a kl27, that would have 256 kB Flash and 32 kB RAM. haven't used that critter yet, though. |
| 04:26.43 | DocScrutinizer05 | I think 16kB are more than enough for a bit of SPI forwarding |
| 04:27.03 | DocScrutinizer05 | and other silly bitbanging |
| 04:27.30 | wpwrak | or let's say KLx7 (x = 1 without USB, 2 with USB). what i have are the ones with USB, which would also be ideal for prototyping. in the neo900, we'd most likely be more interested in having more GPIOs than yet another USB OTG port :) |
| 04:27.54 | DocScrutinizer05 | given the timing constraints you think you want to meet, you wouldn't even have the time to execute lengthy (100s of kB) programs |
| 04:28.05 | wpwrak | why have program in RAM ? we can safely change part of the flash |
| 04:28.36 | DocScrutinizer05 | didn't you just say it can get locked? |
| 04:29.07 | wpwrak | yes, we'd do this when flashing the boot loader. to prevent alteration of boot loader and the protection. |
| 04:29.40 | wpwrak | after that only SWD can unlock the locked part of the Flash. but the rest can be left unprotected. |
| 04:29.46 | DocScrutinizer05 | I don't care about protecting BL, I deny a design that could result in crap locked into flash |
| 04:30.32 | wpwrak | you need the boot loader anyway, and you definitely want to protect it. so you gain nothing by not using the rest of the flash |
| 04:31.10 | DocScrutinizer05 | I gain the flash not containing crap that doesn't work and we cannot get rid of |
| 04:31.47 | wpwrak | the only part you can't easily get rid of would be the boot loader. we just have to make sure it's not crap :) |
| 04:32.26 | DocScrutinizer05 | sorry, you start to puzzle me. didn't you say the flash can get locked and you cannot erase it even with swd? |
| 04:33.29 | wpwrak | there are several protection mechanisms. 1) you can prevent external access (at several levels), 2) you can protect the flash from being written |
| 04:33.52 | wpwrak | the flash protection can be removed by doing a "mass erase" (which erases everything) |
| 04:34.07 | wpwrak | BUT the access restrictions can deny the mass erase |
| 04:34.16 | DocScrutinizer05 | exactly |
| 04:35.03 | wpwrak | so if you have that, and you don't have the code you want on the device, then you're screwed |
| 04:35.13 | DocScrutinizer05 | I don't know of other ways to erase flash than mass (page) erase |
| 04:35.22 | wpwrak | but we wouldn't set that super-restrictive mode |
| 04:35.35 | DocScrutinizer05 | who stops user from setting it? |
| 04:35.56 | wpwrak | but we would use the flash write protection on part of the Flash. the one that could be revoked (over SWD) |
| 04:36.15 | wpwrak | the Flash write protection on the area containing these nasty bits :) |
| 04:36.26 | DocScrutinizer05 | aaah |
| 04:36.47 | DocScrutinizer05 | so that's the ignore of ignore change |
| 04:36.59 | wpwrak | yup :) |
| 04:37.32 | DocScrutinizer05 | we won't support change of bootloader |
| 04:37.42 | DocScrutinizer05 | maybe by testpoints |
| 04:37.50 | wpwrak | yeah. that should be plenty. |
| 04:37.52 | DocScrutinizer05 | for the hardcore hackers |
| 04:37.59 | wpwrak | very hardcore :) |
| 04:39.04 | DocScrutinizer05 | please keep the bootloader short. I don't want to spend weeks on peer review/audit |
| 04:39.24 | wpwrak | in prototypes we may want to have SWD routed to some IO expander or such, so that we can conveniently flash the critter. |
| 04:39.32 | wpwrak | sure |
| 04:39.42 | DocScrutinizer05 | :nod: |
| 04:41.33 | DocScrutinizer05 | could you edit that whitepaper, truncate 9. ? |
| 04:42.31 | wpwrak | you mean "remove" ? :) |
| 04:43.12 | wpwrak | there are a few more such pointers in there. need to get rid of them as well. |
| 04:43.37 | wpwrak | (all mentioned in the check-list at the beginning :) |
| 04:44.26 | DocScrutinizer05 | yeah, rmove |
| 04:45.14 | DocScrutinizer05 | headbangs a little, just for fun |
| 04:45.23 | DocScrutinizer05 | headdesks actually |
| 04:46.00 | DocScrutinizer05 | how noring our lifes would be, without lawyers |
| 04:46.02 | wpwrak | patents are so much fun. especially on standards :) |
| 04:46.03 | DocScrutinizer05 | boring |
| 04:47.39 | DocScrutinizer05 | anyway I think we got a fine general purpose 14MHz RF radio, up to users to do meaningful things with it |
| 04:49.45 | DocScrutinizer05 | snoop mode seems hacker's wet dream |
| 04:50.30 | wpwrak | it's interesting that TI's engineers themselves first had to try to see if that was possible ;-) |
| 04:50.47 | DocScrutinizer05 | hehe |
| 04:51.42 | DocScrutinizer05 | anyway we should get that stuff out to our community, it's just too good to keep it local |
| 04:53.00 | wpwrak | glad you like it ;) |
| 04:53.07 | DocScrutinizer05 | and could earn us some visibility and attention beyond the inner Neo900 circle |
| 04:53.30 | wpwrak | what do we want to do about "inaccessible" documents ? (for-pay standards, NXP chip documents, etc.) |
| 04:53.49 | DocScrutinizer05 | what shall we do about them? |
| 04:53.59 | DocScrutinizer05 | hardly anything we can do |
| 04:54.17 | DocScrutinizer05 | deny we ever seen them? |
| 04:54.27 | DocScrutinizer05 | wouldn't think that's needed |
| 04:54.29 | wpwrak | yes, that's one option |
| 04:54.50 | DocScrutinizer05 | we don't provide them, so what? |
| 04:55.19 | DocScrutinizer05 | those who heard of google can find them as well |
| 04:55.26 | wpwrak | after all, we reference them (or drafts of them) extensively. but no, we don't provide them :) |
| 04:55.45 | wpwrak | the 2nd question would be whether we want to provide links to them |
| 04:55.49 | DocScrutinizer05 | it's not forbidden to read that stuff |
| 04:56.00 | DocScrutinizer05 | rather not |
| 04:56.51 | DocScrutinizer05 | at least not in this document |
| 04:58.39 | wpwrak | lemme weed them out ... |
| 04:58.59 | wpwrak | JIS X 6319-4:2010 ... yup, for pay. gone |
| 05:00.21 | wpwrak | NFC forum is inconvenient: "Non-Members: The NFC Forum Technical Specifications are available for anyone to download at no charge, but only after completing the Specification License Agreement." |
| 05:03.23 | DocScrutinizer05 | alas after registration the amount of available data is exactly as limited as before |
| 05:03.52 | wpwrak | really ? |
| 05:04.11 | DocScrutinizer05 | well, I registered and wondered why I did |
| 05:04.31 | wpwrak | so you don't get access to the documents you selected ? |
| 05:04.58 | DocScrutinizer05 | err, I got access to all those without registration as well |
| 05:05.15 | wpwrak | ah, how ? :) |
| 05:05.26 | DocScrutinizer05 | I hoped for hidden sekrit documents, but there were none |
| 05:05.46 | DocScrutinizer05 | don't ask me details, it been plain frustration |
| 05:06.47 | wpwrak | i found them on 3rd party sites (e.g., apps4android.org) |
| 05:06.53 | DocScrutinizer05 | maybe I found all of them documents 'leaked' on other sites before |
| 05:07.58 | DocScrutinizer05 | but no, actually I think they were available on NXP's site without loggin in to anything |
| 05:09.49 | Steven__ | Was reading the above. Sounds like you two are brewing up a storm. Am I reading this right: wpwrak is getting his MCU? |
| 05:10.36 | wpwrak | NXP seem to have just a nice summary, not the actual specs (looking for the tag specs) |
| 05:11.32 | *** join/#neo900 astr (~astr@79-69-206-237.dynamic.dsl.as9105.com) |
| 05:15.28 | wpwrak | URLs trimmed. size is now down to 50 pages :) |
| 05:18.00 | wpwrak | remaining items on the check list: "Change wording to indicate what we will actually do" -> i think this can wait until later |
| 05:18.10 | Steven__ | IDK if this is interesting to you (probably doesn't fit the design constraints), but Parallax has an open source microcontroller on a 44-QFN: http://www.parallax.com/microcontrollers/propeller-1-open-source http://www.parallax.com/product/p8x32a-m44 |
| 05:18.11 | DocScrutinizer05 | find a tex macro for checking, somewhere there's a closing } missing ;-) |
| 05:18.17 | wpwrak | "Remove choices we don't want to discuss" -> do we want to drop anything ? |
| 05:18.22 | DocScrutinizer05 | ) even |
| 05:18.55 | DocScrutinizer05 | nah, we should "disclose" all stuff we pondered |
| 05:19.02 | wpwrak | (}) hmm ? |
| 05:19.16 | DocScrutinizer05 | a missing ")" |
| 05:19.29 | wpwrak | last one then: "Remove any other information we don't want to say we have" -> anything ? |
| 05:19.37 | DocScrutinizer05 | somewhere, don't ask me where |
| 05:19.54 | DocScrutinizer05 | could't think of any |
| 05:19.56 | wpwrak | missing } ... in what context ? nfc.tex ? |
| 05:20.14 | DocScrutinizer05 | in the whitepaper |
| 05:20.35 | DocScrutinizer05 | ) not } |
| 05:21.12 | wpwrak | ah, you mean that 1) you saw it when reading, 2) still remember that it was missing, but 3) not where ? |
| 05:21.22 | DocScrutinizer05 | yes |
| 05:22.29 | wpwrak | after TX_EN :) thanks, fixed ! |
| 05:22.34 | DocScrutinizer05 | :-) |
| 05:22.38 | DocScrutinizer05 | yes |
| 05:25.38 | DocScrutinizer05 | Steven__: will check that later. thanks |
| 05:26.25 | wpwrak | the propeller is a weird design. totally incompatible with anything else under the sun. |
| 05:26.46 | Steven__ | DocScrutinizer05: Sure. |
| 05:26.52 | wpwrak | the approach is interesting, though. but not really what we'd want |
| 05:27.28 | DocScrutinizer05 | wpwrak: what's formfactor of that kinetis critter? |
| 05:28.26 | wpwrak | 32-QFN may be the most convenient |
| 05:28.27 | Steven__ | I don't really know the design constraints of what you are talking about, but I always thought the Propellar was cool. Even better that the whole design is released to the community. |
| 05:28.53 | wpwrak | you can also choose 48-QFN, various LQFP, various BGAs |
| 05:29.32 | DocScrutinizer05 | 5*5mm quite a monster |
| 05:29.49 | wpwrak | Steven__: i know about it because it's cool :) oh, do they have a proper compiler for it now ? or is it still all with the built-in SDK ? |
| 05:30.43 | Steven__ | Lets see, I remember reading about that. Let me see what I can pull up. |
| 05:31.50 | DocScrutinizer05 | maybe a BGA variant would please me more |
| 05:32.24 | DocScrutinizer05 | I mean, FIVE times FIVE MILLIMETER |
| 05:32.46 | wpwrak | suitable BGAs also start at 5x5 |
| 05:33.01 | DocScrutinizer05 | Nik already moans we can't find space for all the chips we need |
| 05:33.04 | wpwrak | there are some kinetis in smaller packages but they don't have all the features we want |
| 05:33.25 | wpwrak | maybe we can PoP it on the RF chip ;-)) |
| 05:33.33 | DocScrutinizer05 | hehe |
| 05:34.16 | DocScrutinizer05 | I think Nik applies some design rules that drastically reduce usable available real estate |
| 05:34.42 | DocScrutinizer05 | we might have more available than he thinks |
| 05:35.51 | DocScrutinizer05 | (unless we need to waste a PCB area the size of North America for the dang speakers) |
| 05:36.32 | wpwrak | hmm, the KL03 would be available in 20WLCSP (2 x 1.61 mm). has I2C. does not have I2S or FlexIO. has ROM boot loader. (ROM boot loader is another potential (*) get-out-of-bricking-tell ticket) |
| 05:36.44 | Steven__ | Looks like they have it set up for GCC as well as their IDE. |
| 05:37.15 | Steven__ | They also have an area for sharing libraries and such. |
| 05:37.17 | wpwrak | (*) if you're lucky enough to have enabled the "backdoor" feature AND you know what junk you have written in that general area |
| 05:39.06 | wpwrak | but i think with 32-QFN we're on the safe side. oh, and if we want, we can get a BGA with 81 balls or such and abuse it as IO expander. that'll make up for much more than the space it takes :) |
| 05:39.44 | DocScrutinizer05 | hmm |
| 05:40.53 | DocScrutinizer05 | sounds like sth to ponder |
| 05:40.59 | wpwrak | or 48-QFN if nik doesn't like BGAs. actually, even the 32-qfn may have some spare IOs. so it can already begin to pay back :) |
| 05:41.47 | DocScrutinizer05 | I won't start on less than 16 IO we gain with that |
| 05:42.16 | DocScrutinizer05 | 81 is a nice number |
| 05:42.20 | Steven__ | On Wikipedia, says Spin (Propellar specific high-level), C, Forth, partial Pascal, and Java in development. Quote: "Parallax supports Propeller-GCC which is a port of the GCC C/C++ compiler for Propeller[13] (branch release_1_0). The C compiler and the C Library are ANSI C compliant. The C++ compiler is ANSI-C99 compliant. Full C++ is supported with external memory." |
| 05:44.23 | DocScrutinizer05 | the last sentence sounds like the epithap of a civilazation that suffocated from own featuritis |
| 05:45.19 | DocScrutinizer05 | suuure, why code a MCU in assembler when you can code same stuff in C++ when omly you add a lil bit of external RAM |
| 05:45.47 | Steven__ | Browsing Propellar Object Exchange I see entries for I2C, UART, IR, 1-wire, AES, serial, parallel, RF... |
| 05:45.48 | wpwrak | and with the propeller, you could even code your _peripherals_ in C++ ! ;-) |
| 05:45.57 | Steven__ | Well, that is Wikipedia. |
| 05:46.08 | Steven__ | Doesn't mean its actually used that way. |
| 05:46.09 | DocScrutinizer05 | \o/ |
| 05:46.32 | Steven__ | http://obex.parallax.com/ |
| 05:46.37 | DocScrutinizer05 | waits for the linux kernel in java |
| 05:46.45 | Steven__ | Lol. |
| 05:47.25 | DocScrutinizer05 | wait, I think I missed the release a few years ago |
| 05:48.28 | wpwrak | (bga) i'd plan with 32-qfn for now. if we see an opportunity to use it for massive IO expansion, we can always look into that. i suspect that our IO expanders will be limited by placement anyway. |
| 05:49.01 | DocScrutinizer05 | hmm, dunno |
| 05:49.37 | DocScrutinizer05 | I see them mainly on LOWER, and there the placement is not that critical then |
| 05:50.03 | DocScrutinizer05 | NFC would live on LOWER too, right? |
| 05:50.08 | wpwrak | (io expander) and also please don't forget that the kinetis have just one voltage domain. well, at least the ones i've looked at so far. the architecture seems to support at least partial mixed voltage (with true open-drain ports) |
| 05:50.33 | DocScrutinizer05 | hmmm |
| 05:50.44 | wpwrak | (lower) guess so |
| 05:51.29 | wpwrak | the kinetis family goes up to fairly powerful chips. so you can pile up a decent amount of features if you want :) |
| 05:51.48 | DocScrutinizer05 | thanks, but no thanks |
| 05:51.57 | wpwrak | hehe :) |
| 05:53.25 | DocScrutinizer05 | 5*5 makes me start calculating how large a mux and other stuff would be |
| 05:59.59 | wpwrak | hmm, i wonder if i should keep the mention of leaks in section 7.6 (2nd paragraph) |
| 06:00.34 | DocScrutinizer05 | if you feel uncomfortable, just delete it. no? |
| 06:01.38 | DocScrutinizer05 | we didn't leak anything... |
| 06:02.08 | DocScrutinizer05 | but we don''t need to mention there's stuff. When you feel like deleting, do it |
| 06:02.41 | wpwrak | yeah, better not to taunt them |
| 06:02.47 | DocScrutinizer05 | or simply delete the word "leak" |
| 06:03.41 | DocScrutinizer05 | nobody will check all the references anyway |
| 06:04.07 | wpwrak | hmm. and i need to correct the PN532 "leaks", which aren't |
| 06:05.16 | DocScrutinizer05 | yeah, attributing sth as 'leaked' maybe isn't smart |
| 06:05.32 | DocScrutinizer05 | after all we don't even know for sure |
| 06:06.35 | DocScrutinizer05 | IOW often stuff isn't leaked but rather "published inofficially" |
| 06:07.21 | DocScrutinizer05 | nfc what they mean by "confidential / pusblished" anyway |
| 06:08.50 | Steven__ | "We want people to be able to see it if they need to, but we want to be able to C&D them if we don't like them"? |
| 06:09.41 | wpwrak | especially the chinese like to do that :) |
| 06:12.58 | DocScrutinizer05 | oooh, and some nitpicking: the footnotes/refrences the [26] etc are almost in the line above. Looks weird, maybe don't ² it |
| 06:14.42 | DocScrutinizer05 | http://wstaw.org/m/2015/01/04/plasma-desktopbV2003.png |
| 06:16.31 | DocScrutinizer05 | in normal text it's fine to move it to up, but in the list of footnotes it might as well be normal chars, not ²³ |
| 06:19.49 | wpwrak | hmm, that's an unusual style you want. lemme see if there's a package for it ... |
| 06:21.21 | DocScrutinizer05 | really just nitpicking |
| 06:22.20 | DocScrutinizer05 | just found it difficult to align leading ²³ with a previous and following multiline comment |
| 06:24.23 | DocScrutinizer05 | alternatively add a guiding "-" in place of the space separator, maybe |
| 06:24.52 | DocScrutinizer05 | even several "---" |
| 06:25.16 | DocScrutinizer05 | ²³----this is number 23 |
| 06:25.29 | DocScrutinizer05 | ³²----this is number 32 |
| 06:26.59 | wpwrak | maybe if i just reduce the white space ? |
| 06:27.10 | DocScrutinizer05 | could help as well |
| 06:29.58 | Steven__ | Something interesting: 12Mb/s USB and BT stacks by bit-banging on the Prop http://obex.parallax.com/object/640 |
| 06:32.01 | wpwrak | new draft has the space reduced by 1/3 |
| 06:33.27 | wpwrak | going deeper would get messy because i already veer from the standard format to get "hanging" indentation |
| 06:34.51 | DocScrutinizer05 | don't waste time on it |
| 07:21.50 | Steven__ | Just browsing obex some more: FAT16/32 for SD/MMC http://obex.parallax.com/object/16 keyboard matrix controller http://obex.parallax.com/object/144 19.2Kb/s serial bitbang http://obex.parallax.com/object/541 16-bit 44.1/48 kHz S/PDIF http://obex.parallax.com/object/561 |
| 07:23.51 | wpwrak | ... FTL travel ... PCI ... perpetuum mobile ... SONET ... cure for cancer ... |
| 07:26.13 | wpwrak | i wonder how energy-efficient all those bit-banging peripherals are. |
| 07:27.53 | Steven__ | The QFN states: Current requirements: â 9 mA per cog @ 3.3 V, 80 MHz |
| 07:28.07 | Steven__ | 80 MHz is max. |
| 07:28.51 | wpwrak | pretty greedy. but i hope the peripherals can stop execution when they have nothing to do ? |
| 07:28.54 | Steven__ | Eight cogs. The FAT driver for example states that it uses one cog. |
| 07:29.43 | Steven__ | It can throttle the clock down to zero according to the summary. Factors of two, I think. |
| 07:31.01 | wpwrak | that's per cog or global ? |
| 07:32.59 | Steven__ | Not sure. |
| 07:33.06 | Steven__ | Probably global. |
| 07:34.13 | Steven__ | Chat on the specifications shows the current going down to microamps with frequency reduction. |
| 07:34.16 | Steven__ | Chart* |
| 07:35.53 | Steven__ | Yes. There is exactly one clock select on the block diagram. |
| 07:36.45 | wpwrak | 8.2 has the ugly truth: up to 1 mA for doing nothing |
| 07:38.52 | Steven__ | Only if your running it at 80 MHz |
| 07:39.06 | Steven__ | Almost zero if you have throttled it down. |
| 07:39.08 | wpwrak | my kl26 can do this with about 2 uA ;-) (i.e., be awake enough to react to IO within ~5 us) |
| 07:40.10 | Steven__ | What would prevent you from listening with one cog at a low clock frequency? |
| 07:43.02 | Steven__ | Eh, might be worth inquiring about what people think on the Prop forums. They seem to have a healthy FLOSS community, so you might get some volunteers to hash stuff out. |
| 07:44.09 | Steven__ | That is the main advantage that I see, besides it being a FOSS (FOSH?) micro. (Well, and possible code sharing) |
| 07:44.11 | wpwrak | yes, one cog listening at low frequency would correspond to those 2 uA modes |
| 07:45.30 | wpwrak | also note: 3 V supply. neo900 is mostly 1.8 V |
| 07:45.44 | Steven__ | Ah. |
| 07:45.46 | Steven__ | Mostly? |
| 07:46.15 | wpwrak | we have some components that need 3 V. which is usually a bit of a headache. |
| 07:49.00 | wpwrak | anyway, the prop is certainly an interesting concept. but not really for the kind of environment we have here. you could probably have quite a bit of fun with it as an arduino replacement, though. |
| 07:50.00 | Steven__ | Yeah, I guess. |
| 07:51.26 | Steven__ | How are you handling the 3V now? I guess you just have two buck supplies? |
| 08:23.21 | Steven__ | Goodnight all. |
| 08:37.56 | *** join/#neo900 Pali (~pali@Maemo/community/contributor/Pali) |
| 08:46.00 | *** join/#neo900 illwieckz (~illwieckz@rob92-15-83-156-208-169.fbx.proxad.net) |
| 09:06.11 | *** join/#neo900 paulk-collins (~paulk@gagarine.paulk.fr) |
| 09:12.56 | *** join/#neo900 jonwil (~jonwil@27-33-80-219.tpgi.com.au) |
| 09:38.37 | *** join/#neo900 che1 (~che@n118.tum.vpn.lrz.de) |
| 09:57.01 | *** join/#neo900 b1101 (~b@fsf/member/b1101) |
| 11:45.10 | *** join/#neo900 SylvieLorxu (~SylvieLor@dhcp-077-251-165-191.chello.nl) |
| 12:00.24 | *** join/#neo900 arcean (~arcean@5.174.125.192) |
| 12:08.18 | *** join/#neo900 illwieckz (~illwieckz@rob92-15-83-156-208-169.fbx.proxad.net) |
| 12:20.44 | *** join/#neo900 phre4k (~phre4k@55d438e3.access.ecotel.net) |
| 12:53.41 | *** join/#neo900 phre4k (~phre4k@55d438e3.access.ecotel.net) |
| 13:32.21 | *** join/#neo900 Kabouik (~quassel@144.193.95.79.rev.sfr.net) |
| 13:38.24 | *** join/#neo900 phre4k_ (~phre4k@55d4158a.access.ecotel.net) |
| 13:41.43 | *** join/#neo900 Kabouik_ (~quassel@144.193.95.79.rev.sfr.net) |
| 13:46.09 | *** join/#neo900 Kabouik (~quassel@144.193.95.79.rev.sfr.net) |
| 13:48.59 | *** join/#neo900 Kabouik (~quassel@144.193.95.79.rev.sfr.net) |
| 13:53.54 | *** join/#neo900 norly (~norly@enpas.org) |
| 14:01.06 | *** join/#neo900 sparetire_ (~sparetire@unaffiliated/sparetire) |
| 14:29.58 | *** join/#neo900 norly (~norly@enpas.org) |
| 14:36.10 | *** join/#neo900 j4s0nmchr1st0s (~j4s0nmchr@172.56.11.74) |
| 15:22.58 | *** join/#neo900 phre4k__ (~phre4k@55d43501.access.ecotel.net) |
| 15:34.54 | *** join/#neo900 lexik (~lexik@ip-62-245-77-103.net.upcbroadband.cz) |
| 15:58.23 | *** join/#neo900 phre4k_ (~phre4k@55d40526.access.ecotel.net) |
| 16:23.47 | *** join/#neo900 ashneo76 (~ashneo76@2002:47c2:f7fa:1::abf1:da7e) |
| 16:39.46 | *** join/#neo900 phre4k__ (~phre4k@55d42fd3.access.ecotel.net) |
| 16:43.07 | *** join/#neo900 phre4k (~phre4k@55d42fd3.access.ecotel.net) |
| 17:04.50 | *** join/#neo900 ashneo76 (~ashneo76@c-71-194-247-250.hsd1.il.comcast.net) |
| 17:13.24 | *** join/#neo900 che1 (~che@n136.tum.vpn.lrz.de) |
| 17:37.10 | *** join/#neo900 illwieckz (~illwieckz@rob92-15-83-156-208-169.fbx.proxad.net) |
| 17:43.26 | *** join/#neo900 illwieckz (~illwieckz@rob92-15-83-156-208-169.fbx.proxad.net) |
| 18:26.20 | *** join/#neo900 kolp (~quassel@brmn-5f7746db.pool.mediaWays.net) |
| 18:30.54 | *** join/#neo900 Pali (~pali@Maemo/community/contributor/Pali) |
| 19:48.19 | *** join/#neo900 b1101 (~b@fsf/member/b1101) |
| 20:06.38 | Steven__ | Hello, everyone. |
| 20:12.05 | *** join/#neo900 lexik (~lexik@ip-62-245-77-103.net.upcbroadband.cz) |
| 20:25.54 | *** join/#neo900 nox- (noident@freebsd/developer/nox) |
| 21:24.35 | *** join/#neo900 xes (~xes@unaffiliated/xes) |
| 21:39.52 | *** join/#neo900 lexik (~lexik@ip-62-245-77-103.net.upcbroadband.cz) |
| 21:50.16 | *** join/#neo900 Oksana (~chatzilla@129.94.239.199) |
| 21:53.30 | *** join/#neo900 nox- (noident@freebsd/developer/nox) |
| 22:12.39 | *** join/#neo900 jonwil (~jonwil@27-33-80-219.tpgi.com.au) |
| 22:27.20 | *** join/#neo900 xes (~xes@unaffiliated/xes) |
| 23:50.20 | *** join/#neo900 svetlana (noone@2400:8900::f03c:91ff:fe89:8366) |
