#qi-hardware IRC log for Sunday, 2013-09-15

larscwpwrak: we have that CapTouch family of devices, even with Linux drivers09:14
viricmh this zswap thing may be nice in the nanonote.09:29
pcercueiit was nice on the Dingoo with LZO09:34
larscdidn't we already had it long time ago?09:34
pcercueiit may even be nicer with Snappy or LZ409:34
viriclarsc: maybe. I've seen it in 3.1109:35
viricthere was that zram thing, before09:35
larscit's all the same09:36
viricauhm is it?09:37
viricI thought zram made a block device compressed in ram09:37
larscso for zswap you need some kind of physical swap space09:42
larscfor zram you don't09:42
larscso yea, me saying 'it's all the same' was wrong09:42
larscbut zswap + ramfs = zram09:43
larscwell not exactly09:43
larscbut kind of09:43
viricright, that's how I saw it09:45
wpwraklarsc: hmm, if going cap, i would hope to do it with the resources already in the mcu. all you really need is an ADC.10:59
larscand some magic11:02
wpwrakthe main problems i found are material thickness, sensor size, and robustness against voltage swings and maybe other components in the system distorting the capacitance11:02
wpwrake.e.g, diodes :)11:02
wpwrakviric: zsawp is what made my ubb-jtag work :) urtag is very memory-hungry with xilinx11:03
wpwrakor was is zram ? checking ...11:04
cdeI sense a great disturbance in the capacitance11:05
wpwrakyeah, ZRAM. though it is swap ...11:06
whitequarky u no fix ur jtag11:08
larscwith zram the compression happens in the block device code, with zswap the compression happens in the swap code11:08
larscthe end result is very similar though11:09
larscif you are going form ram based swap11:09
wpwrakwhitequark: a fix may get a little deep. and it really was just a weekend hack.11:10
whitequarkwpwrak: it was just word play on the name :)11:11
whitequarkby the way... https://gist.github.com/whitequark/182569b68f3910248c31 and http://imgur.com/PNMhVPJ11:14
whitequarkoh and the resulting assembly: https://gist.github.com/whitequark/b122443b9c83c7ad10f311:15
whitequarkso my compiler works, and does it quite well :)11:15
wpwrakwhich stm32 ?11:16
cdevery cool! I've always wanted to design & build a compiler too :)11:16
whitequarkwpwrak: it's maple leaf... stm32f103cb11:16
cdewhitequark: how long did it took you?11:16
whitequarkcde: it depends on how you measure it11:17
whitequarkthe original idea was born two years ago; I knew absolutely nothing about compilers back then11:17
whitequarkso it took a lot of research11:17
whitequarkthe latest, hopefully production-quality, iteration of the software itself, written in ocaml, took me about two months of full-time work to write11:18
whitequarkI've tweaked some language features and fixed my type inferencer in that time, too, but mainly it was just a rewrite of Ruby prototype code in ocaml11:18
cdedo you plan on self-hosting-ness at some point? then you could have a self-hosting OS11:19
whitequarkcde: not really, ocaml is OK11:19
whitequarkbesides, it uses LLVM as its low-level optimizer and code generator11:19
whitequarkthe compiler, which includes an interpreter and type checker/inferencer itself, is 8400LOC11:20
cdeso you feed llvm the ast and it spoouts asm?11:21
whitequarkno, I have my own SSA IR11:21
cdeah cool. I guess this is where you enforces the types and so on?11:22
cdedo you do boundary checking or is it like C?11:22
whitequarkit's safe by default: the language doesn't prohibit direct memory access (it's not java), but all the simple actions, say iterating over an array, are safe11:23
whitequarkin case of iteration, you don't even need bounds checking most of the time11:24
cdeyes true11:24
whitequarkif you have closures, yeah11:24
whitequarkfoo[idx] would do checking; foo.unsafe_get(idx) won't.11:24
cdevery cool! btw why the choice of OCaml over say Haskell?11:25
whitequarkocaml is practical11:26
whitequarkhaskell... uh... well if you listen to haskell programmers, sure :)11:26
cdeyeah ocaml is great for parsing11:27
whitequarkocaml also has very simple (and I mean C-level simple) runtime representation and native compiler11:27
cdeso you made a safe language that can be used for system programming, is very lightweight and easy to use11:28
cdeit kinda sounds too good to be true ;)11:28
whitequarkI had to invent a bag of tricks. :)11:28
whitequarkfor example there isn't really a meaningful separate compilation mode11:32
cdeyou mean debug/release?11:32
whitequarkno, think of how you can compile several .o files with clang and then link them11:32
cdeah you mean you compile everything at once11:33
whitequarkit works fine if you have C-like (not C++-like, though) type system11:33
whitequarkit also works fine if you have complete signatures on module (think .o file) boundaries11:33
cdeso no type abstractions I guess?11:34
cdewell, headers defining abstract types that are then implemented11:34
whitequarkah. yes. I have value types11:35
whitequarkthis means that the code using those value types must at least know their size11:35
whitequarkthings get much more interesting when you throw automatic memory management into the mix: now code may need to know contents as well11:35
cdehmm. you could have an opaque type system with a kind of identifier + size11:35
cdeand a module for resolving identifiers to actual code, sort of like a vtable11:36
cdeI'm not sure it would be very efficient though11:36
whitequarkthat's unacceptable if it means runtime overhead11:36
whitequarkright now, all calls in foundry are fully static (no indirection) unless explicitly declared as dynamic11:37
whitequarkthe result is very strong IPO11:37
whitequarkand I need to keep that11:37
cdeyeah my proposal was more like rtti11:37
cdeit's not really needed for systems programming11:37
whitequarkwell it's dumb to have dynamic dispatch over everything11:37
whitequarktoo slow.11:38
cdeI think it has some use cases though. consider Qt's slots, it's very flexible and allows connecting objects at runtime11:38
cdetrue that Qt does not recommend using it for everything, because of the overhead11:38
whitequarksure, but you can easily do that within my type system. method(:foo) -> returns a closure with the corresponding signature11:39
cdeoh, you have closures. nice :)11:40
whitequarkthey're also rather efficient11:40
whitequarkthe runtime representation is like struct { e* env; void(*)(e*, ...); }11:40
whitequarkso, two words11:40
whitequarkand liveness of the environment is verified with region inference11:41
whitequarkin fact, with the representation being so simple, LLVM has zero problems inlining such closures, so for example all iterators just naturally get inlined and are as efficient as C loops11:41
whitequarkI didn't even have to do anything :)11:41
cdeit all sounds really cool! you should write a book on your experience creating a language and interfacing with llvm. a lot of people would be interested11:45
whitequarkeh, just grab reference manuals for ocaml and llvm, and dragon book and appel's compiler implementation in ml11:46
whitequarkthat's about it :)11:46
cdeoh. ok :)11:46
larscin short: RTFM11:55
wpwrakRTFL ;-) L for Library11:56
larscwpwrak: I see you don't like parenthesis of any sort12:01
larscs/wpwrak/whitequark/ 12:02
whitequarklarsc: hm?12:13
whitequarknot sure what you mean12:13
whitequarkah, good old syntax holy war :)12:15
whitequarksince I don't have field accesses (e.g. "backlight=" is a method), it doesn't make sense to require parentheses here12:16
whitequarkperhaps you're interested in the implementation of that LCD class: https://gist.github.com/whitequark/40447e26eb3be8132ab112:17
whitequarkand the GPIO register block: https://gist.github.com/whitequark/17cad7fec8dbcb63201412:18
whitequarkand the metaprogramming which defines register field accessors: https://gist.github.com/whitequark/e2b75c8f125097f1a85112:19
wpwraklarsc: would apply to me, too :)   ((a == 1) || (b == 2))  makes me angry12:20
ysionneau13:14 < whitequark> by the way... https://gist.github.com/whitequark/182569b68f3910248c31 and http://imgur.com/PNMhVPJ       kilae12:44
rjeffrieswpwrak said yesterday: or the jog wheel, i have two options: a 22 mm wheel with rotation and a center button. or a 32 mm wheel with rotation, center button, and four "cursor keys"14:01
rjeffriesIMO the 2nd option would be more useable. the extra size is worth having cursor keys. ymmv14:02
wpwrakdunno. first, the size increase is substantial: more than +1/3. and it also gets a little thicker. second, with so many functions crammed into a single device one may trigger other movements than the one intended.14:31
rjeffriesToday is Sunday, in USA. Quiet.14:31
wpwrakbut i've ordered a few of the big wheels, too, so i can experiment :)14:32
rjeffrieswhich display did you choose, remind me pls14:32
wpwraki'll first evaluate this one: http://www.buy-display.com/default/oled-graphic-display.html14:34
wpwrakno choice has been made yet :) i first have to see it14:34
whitequarkoled ones are quite expensive and degrade, no?14:39
wpwrakwhitequark: about 170% the price of an LCD the same size. dunno if they all degrade or only some. in any case, that one should at least not suffer aging due to excessive use :)14:44
wpwraki have LCDs as plan B: http://www.buy-display.com/default/128x64-st7565p-lcd-module.html14:44
whitequarkoh, they got cheaper since I last looked14:44
whitequark(which is to be expected)14:44
wpwrakbig disadvantage of most LCDs is that they always draw maximum power for the backlight14:45
whitequarktransflective lcds?14:45
whitequarki.e. what about transflective lcds? they can be used without backlight.14:47
wpwrakunsure about sourcing. also, they usually have poor contrast.14:49
whitequarkyeah, true14:52
whitequarktalking about degrading14:52
whitequarkI had a phone with an OLED display14:52
whitequarkdegrading *is* noticeable (especially if it heats up, which it *of course* does), but unless you look at photos, it doesn't make a difference14:52
whitequarkno idea how much different your display will be14:52
wpwrakwe'll see :) i should get it this week14:54
rjeffries(high) contrast is your friend in this use case. and this display will almost always be OFF so wear is unimportant IMO14:57
whitequark>Interface 6800 8-bit Parallel , 8080 8-bit Parallel , I2C, 3-Wire Serial SPI, 4-Wire Serial SPI14:59
whitequarkdo *all* displays have the same set of interfaces?14:59
whitequarkI recently had an, uh, pleasure to write a few drivers and they look almost exactly alike.15:00
larscthere aren't that many display controller vendors15:00
wpwrakyeah, that's pretty much identical for all displays15:00
wpwrak6800 and 8080 look kinda suckish. i'll just go with 4-wire SPI15:01
whitequarkit's fine if you don't need fast updates.15:01
wpwrakannoyingly, they don't bring out the frame sync signal, so there will be tearing15:01
whitequarkthough, this one is b&w... could work regardless15:01
rjeffrieswpwrak for the safe to work in conjunction with a mobile phone or tablet, that device must support (???) USB OTG that allows external keyboard?15:06
wpwrakyes. well, for now via an external box. so you don't see it if you don't use it. (it's just a micro-AB receptacle instead of micro-B)15:13
rjeffriesI need to investigate (I am ignorant) how widely the popular mobile phones implement OTG, It's not a universal, I'm pretty sure. will look into this point.15:42
wpwraki'm thinking of just implementing A/B detection. not the fancy negotiation protocol15:43
wpwrakhmm, pcb gets mightly crowded15:47
rjeffriesyou do not need complications at this stage. KISS rules. having said that...15:49
rjeffriesa future possibly derivative product targeted squarely at mobile devices woudl have appeal. USB in that case may not be preferred connection between safe and mobile15:50
rjeffriesblue sky... NFC or Bluetooth Low Energy might be attractive to users, but may also be way outside teh scope of what you wish to attempt. that's fair.15:52
whitequarkuh, nfc is easily hijacked from afar15:53
wpwrakBT would be nice. is there a chip/module that's flexible enough, can be sourced, and has publicly-accessible documentation ?15:55
rjeffriesis that true when power levels are REALLY low? physics is on our side. LOL  but my point (for 2014 maybe) is MOBILE is the majority computing device now, period. one eventually want to solve password issue for tablets and smartphones15:55
rjeffrieswpwrak those are great questions, while you focus on USB (wisely) others including me can poke at BLE devices. Your requirment on open documentation may or may not be met, I dunno15:57
wpwrakthat requirement is pretty crucial ... :)15:58
rjeffriesI get it15:58
whitequarkwpwrak: define "documentation"15:58
whitequarkpretty much all BT modules I've seen had docs in public15:59
wpwrakand did they implement more than just UART ? :)16:13
rjeffrieswhitequark: that's useful to know! re BT technical documentation. BT chip cost must also be VERY (!) low these days. although high volume stuff is prolly buried in an SoC that also does e.g. wi-fi and more16:14
rohwpwrak: on bt you usually have the choice between hci via usb or serial and 'stack in the module' via serial where you use AT-commands to configure the stack and only get a 'serial via bt' link16:14
rohsome can also do audio feats on the module, but thats not the point for your app.16:15
wpwrakUSB .. the idea low-power interface :)16:15
rohwpwrak: usb is often choosen not because of simplicity or power needs, but because there is nothing which has real serialports on it around16:16
rohalso serialports never had a power-line and some negot. for that with it... and 'multi-link bundling'.16:17
rohif there'd be a serial conn, which is smaller than sub-d9, widely used (doesnt exist) and has power, people whould use that.16:17
rohah.. and also serial usually maxes out at 1-2 mbit.... usb doesnt. thats why its often used in addition to serials too. from 3g on, serial is too slow, also for audio out of a bt module (when decompressed there)16:18
whitequarkalso protocols16:19
whitequarkeveryone invents their own on serial16:19
rohwhitequark: yes. and sometimes no. i mean.. some hdlc usually should be ok16:48
rohthats how the people i know do it ;)16:48
rjeffrieswhitequark: can you suggest some BT modules that might be candidates? 17:12
qi-bot[commit] Werner Almesberger: modules/qfn.fpd: add QFN48-Freescale for KL25 chips (draft) (master) http://qi-hw.com/p/kicad-libs/e8e681318:47
qi-bot[commit] Werner Almesberger: components/: add Freescale Kinetis KL25 in 48 pin package (master) http://qi-hw.com/p/kicad-libs/38cb8de18:47
qi-bot[commit] Werner Almesberger: add EastRising OLED FPC-30 connector (symbol and footprint) (master) http://qi-hw.com/p/kicad-libs/2c2637318:47
qi-bot[commit] Werner Almesberger: components/memcard8.lib: add MEMCARD8-SHIELD3-SW1 for Amphenol 10100660 (master) http://qi-hw.com/p/kicad-libs/4a9b06e18:47
qi-bot[commit] Werner Almesberger: modules/memcard8-amp-10100660.fpd: Amphenol 10100660 footprint (draft) (master) http://qi-hw.com/p/kicad-libs/81c2a4818:47
qi-bot[commit] Werner Almesberger: flip er-oled-fpc30.fpd; add new footprints to Makefile; fix comp ref in kl25-48.lib (master) http://qi-hw.com/p/kicad-libs/2aa323318:47
qi-bot[commit] Werner Almesberger: add C&K TSWA series switch with 22 mm wheel (master) http://qi-hw.com/p/kicad-libs/3f1b97819:19
qi-bot[commit] Werner Almesberger: HIERARCHY: change QFN32-Freescale to QFN48-Freescale (master) http://qi-hw.com/p/kicad-libs/a6aca6e19:19
whitequarkhuh http://www.caravan.net/ec2plus/19:58
wpwrakremoves templates, inheritance, and all that nonsense ?20:18
larscyeay, party like it is 199920:26
whitequarkwhat is the point of using C++ if you don't have any of that?..20:32
larscFrom their Q&A 'Why is X removed? X it is too new to be used widely.'20:42
larscbut given that the page was last updated 2002 I think it is safe to assume that the project is dead20:43
whitequarkthat is a strange rationale nevertheless20:44
whitequarkif we've followed this logic, we'd still be writing assembly :)20:44
--- Mon Sep 16 201300:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!