| 00:07.40 | qi-bot | [commit] Werner Almesberger: cameo: "area" now also adds the outline cuts (master) http://qi-hw.com/p/cae-tools/35c0624 |
| 00:07.41 | qi-bot | [commit] Werner Almesberger: cameo: don't duplicate paths already cleared by the outline (master) http://qi-hw.com/p/cae-tools/5a599e1 |
| 00:07.42 | qi-bot | [commit] Werner Almesberger: cameo/area (hit_segment): only consider vectors pointing in the right direction (master) http://qi-hw.com/p/cae-tools/b607816 |
| 00:07.43 | qi-bot | [commit] Werner Almesberger: cameo/area.c (touch): also consider whether we're looking for entry/exit (master) http://qi-hw.com/p/cae-tools/6fbdfd7 |
| 00:07.45 | qi-bot | [commit] Werner Almesberger: cameo/area.c: removed debugging and obsolete code (master) http://qi-hw.com/p/cae-tools/6811df5 |
| 00:07.47 | qi-bot | [commit] Werner Almesberger: cameo: documented "area"; miscellaneous cleanup (master) http://qi-hw.com/p/cae-tools/489ca9c |
| 00:48.20 | *** join/#qi-hardware cladamw (~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw) |
| 01:00.19 | wpwrak | DocScrutinizer: btw, any more comments on the ether PHY ? anything that looks/sounds suspicious ? |
| 01:01.08 | DocScrutinizer | dang I forgot to follow up on it yesterday, been wasted when I came home |
| 01:01.31 | wpwrak | heh ;-)) |
| 01:02.08 | wpwrak | well, no rush. tomorrow is another day :) |
| 01:03.39 | *** join/#qi-hardware wolfspra1l (~wolfsprau@221.220.185.96) |
| 01:03.50 | DocScrutinizer | the schematics in that awful chinese datasheet look unsuspicious |
| 01:04.07 | DocScrutinizer | all pins poroperly named |
| 01:04.31 | DocScrutinizer | I'd simply connect it the way the pin names suggest |
| 01:05.16 | DocScrutinizer | NFC about TCT and RCT |
| 01:05.27 | DocScrutinizer | depends on chip that drives it |
| 01:05.55 | DocScrutinizer | if the chip doesn't need them, keep them NC |
| 01:06.24 | DocScrutinizer | wait a minute, didn't you also link to the current schematics in 'our' device? |
| 01:09.10 | DocScrutinizer | wpwrak: I'd have looked into your current design as well, to check if it looks fishy in any way, but I don't know where to find it |
| 01:12.16 | wpwrak | http://downloads.qi-hardware.com/hardware/milkymist_one/sch/tmp/MILKYMISTONE.pdf |
| 01:12.27 | wpwrak | that's the current draft for r4. ether is the same as for rc3 |
| 01:13.46 | *** join/#qi-hardware rejon (~rejon@118.143.62.3) |
| 01:16.33 | cladamw | DocScrutinizer, would you like me to update the latest draft sch to applied sch from all replies from last reviews of mail threads ? |
| 01:17.01 | DocScrutinizer | cladamw: no problem for now |
| 01:17.57 | cladamw | DocScrutinizer, okay. :) |
| 01:18.44 | DocScrutinizer | which page is ethernet? |
| 01:18.50 | wpwrak | DocScrutinizer: (pin names) there are the confusing differences between the component we use and all the others. e.g., 1) parallel transformers followed by antiparallel ones vs. antip. followed by parallel. 2) that the pin numbering suggests that TX and RX are swapped, along with the +/- polarity. not sure if the latter is a real difference or if they just got it wrong in the data sheet |
| 01:18.59 | DocScrutinizer | (this friggin thing isn't searchable) |
| 01:19.18 | wpwrak | the 3rd page |
| 01:19.24 | wpwrak | it is ! |
| 01:19.49 | wpwrak | the previous version (rc3) wasn't |
| 01:20.27 | DocScrutinizer | wpwrak: these are all differences I'd expect to see between upstream and downstream or between hub/switch and PC component |
| 01:21.19 | wpwrak | hmm :) |
| 01:21.42 | DocScrutinizer | you recall my 0modem patchcable remark ? |
| 01:22.31 | DocScrutinizer | this component is not symmetric thus won't really work well with the automatic swapping of newer chips |
| 01:22.42 | wpwrak | the AP vs. P. issue is trickier: some have P-AP on TX and RX. some have P-AP on one and AP-P on the other. now is this equivalent ? if yes, why would even the same company sometimes have both variants ? |
| 01:22.51 | wpwrak | something doesn't quite add up there |
| 01:24.07 | DocScrutinizer | this component is meant for chips that never swap RX and TX |
| 01:24.40 | wpwrak | hmm, that may be troublesome then |
| 01:25.00 | DocScrutinizer | other designs might chose to use TX config for both channels, as RX works with that suficently well while TX can't work with RX scheme |
| 01:25.13 | wpwrak | what's the likely consequence of doing it regardless ? massive degradation ? or just a very marginal difference ? |
| 01:25.18 | DocScrutinizer | od swap RX and TX in my last statement |
| 01:25.21 | DocScrutinizer | or* |
| 01:25.34 | DocScrutinizer | dunno |
| 01:25.39 | wpwrak | damn :) |
| 01:26.11 | DocScrutinizer | anyway, correctly connecting this component shouldn't yield any problems |
| 01:26.28 | DocScrutinizer | as afaik the chip can't do swapping either |
| 01:27.15 | DocScrutinizer | just make sure you connected RX to RX and TX to TX |
| 01:27.34 | wpwrak | our chip can swap TX and RX |
| 01:27.40 | DocScrutinizer | ooh |
| 01:28.01 | wpwrak | and if the pin numbering doesn't lie, TX and RX are reversed with respect to the reference component |
| 01:28.02 | DocScrutinizer | haven't seen any such switch/mux in the block diagram |
| 01:28.16 | wpwrak | it's inside the chip |
| 01:28.28 | wpwrak | ah. that block diagram |
| 01:28.31 | wpwrak | lemme see ... |
| 01:28.35 | DocScrutinizer | block diagram of chip of course :-D |
| 01:29.03 | wpwrak | yeah .. i';m a bit slow ;-) |
| 01:29.18 | DocScrutinizer | and I'm a bit late |
| 01:29.21 | wpwrak | anyway. page 21 quite clearly explains that is can do crossover |
| 01:29.30 | DocScrutinizer | ummm |
| 01:29.55 | DocScrutinizer | then for sure you're better off with a symmetric component for transformer |
| 01:31.00 | wpwrak | cladamw: how would you feel about replacing that connector with one of the many recommended by micrel ? |
| 01:31.01 | DocScrutinizer | not that I'd expect a huge impact with this one, it probably will still work flawlessly |
| 01:32.44 | wpwrak | DocScrutinizer: heh :) that's basically the answer i'm after. one of 1) it may be different, but irrelevant in practice. 2) it's something we can worry about later, when we're really bored some day. 3) what we have a is a very crippled ethernet that performs way below specification. |
| 01:32.58 | wpwrak | if it's 1) or 2), we can move on |
| 01:33.45 | DocScrutinizer | I'd not bet on 1 or 2, unless I have to |
| 01:34.12 | cladamw | wpwrak, although as a review you discovered which has such a great feedback, but those possible 'thoughts' were existed too as you just pointed three scenario. |
| 01:34.16 | DocScrutinizer | my guess is it's mainly about EMI |
| 01:35.40 | wpwrak | aah, another scenario: 4) it'll work but the death rays we emit will kill the entire neighbourhood :) |
| 01:35.48 | cladamw | wpwrak, no matter what if it's 1) or 2), M1 has not been retested for EMI test. |
| 01:35.54 | DocScrutinizer | and honestly it will still work great in at least one of two modes |
| 01:36.05 | cladamw | wpwrak, sure your 4) if later found. |
| 01:36.21 | wpwrak | cladamw: did you change J4 in the history of M1 ? |
| 01:37.24 | wpwrak | DocScrutinizer: you mean with TX/RX swapping ? only if the other side does that too (or if the data sheet has the pin numbering wrong) |
| 01:37.31 | DocScrutinizer | so while it may fail, perform sub par, or emit RF noise with one kind of patch cable, it will work absolutely correct with the other kind |
| 01:37.56 | wpwrak | okay. i think that's good enough for now :) |
| 01:39.17 | wpwrak | people regularly get cable crossing wrong. so we just blame the customer if it doesn't work properly :) |
| 01:39.32 | cladamw | (rc1 final) http://downloads.qi-hardware.com/hardware/milkymist_one/sch/20100424/MilkymistOne_draft2.pdf |
| 01:39.34 | DocScrutinizer | 1, 2 is TX in M1 schematics, so everything ok for me |
| 01:39.58 | cladamw | (rc2 final) http://www.milkymist.org/mmone/old/rc2_schematics.pdf |
| 01:40.35 | cladamw | (rc3 final) http://downloads.qi-hardware.com/hardware/milkymist_one/sch/20110523/rc3_design_20110523.pdf |
| 01:41.17 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 01:41.47 | wpwrak | DocScrutinizer: oh, and does it matter what we connect the midpoints (TCT, RCT) to ? we have them directly on 3.3 V. i saw one other design that had them via a series cap at GND |
| 01:42.15 | DocScrutinizer | dang, that for sure matters |
| 01:42.18 | wpwrak | cladamw: looks the same. so no change ? |
| 01:42.20 | cladamw | wpwrak, DocScrutinizer from http://en.qi-hardware.com/wiki/Milkymist_One_Schematic_Change_History there's no changes on J4 but replaced to UDE part. |
| 01:42.20 | wpwrak | hah ! ;-) |
| 01:42.28 | DocScrutinizer | it's depending on your chip's driver desigmn |
| 01:42.49 | cladamw | wpwrak, yeah...no changed in pin swapped or somethings in sch. |
| 01:43.28 | *** join/#qi-hardware Openfree` (~Openfreer@116.228.88.131) |
| 01:44.37 | DocScrutinizer | if your chip has open-collector outputs to GND on TX TX' then you want TCT on +whatever. if chip drivers are to +whatever, you need TCT to GND |
| 01:45.20 | DocScrutinizer | and if chip has a full H-bridge, you want to keep TCT NC |
| 01:45.24 | wpwrak | with or without series cap ? |
| 01:45.38 | DocScrutinizer | without of course |
| 01:45.50 | wpwrak | "output pin" |
| 01:47.21 | DocScrutinizer | series cap to GND only makes sense for input aka RX, I'd say |
| 01:48.25 | DocScrutinizer | there's really no black magic in all that |
| 01:49.00 | DocScrutinizer | just think it's audio ;-) |
| 01:49.11 | DocScrutinizer | or RF |
| 01:49.50 | wpwrak | no black magic in audio ? since when ? ;-)) |
| 01:50.52 | wpwrak | so you would disagree with page 3 of http://ww2.pulseeng.com/products/datasheets/H325.pdf ? |
| 01:50.54 | DocScrutinizer | anyway regarding TCT RCT do *exactly* what chip manuf suggests |
| 01:52.25 | wpwrak | they suggest absolutely *NOTHING* :-( |
| 01:53.20 | wpwrak | don't think i'd be bothering you if i had found an obvious solution ;-) |
| 01:54.03 | DocScrutinizer | nah, they must have some hint on that. don't they offer a application note? |
| 01:54.09 | kristianpaul | DocScrutinizer: the are LTE USB Dongles? |
| 01:54.30 | kristianpaul | why i cant find none in ebay... |
| 01:54.32 | DocScrutinizer | kristianpaul: eh? |
| 01:54.39 | DocScrutinizer | not yet |
| 01:54.54 | kristianpaul | ah ! |
| 01:55.00 | kristianpaul | why? :-) |
| 01:55.18 | DocScrutinizer | well, maybe because the chips are not ready yet |
| 01:55.26 | kristianpaul | fair point |
| 01:56.02 | DocScrutinizer | wpwrak: yep, that p.3 is horrible |
| 01:56.08 | roh | there are some, but not easily avail yet |
| 01:56.16 | wpwrak | hmm, they have a design kit. let's see ... |
| 01:56.19 | wpwrak | http://www.micrel.com/_PDF/Ethernet/hw_designkit/8001/KS8001_v1.2_DP.zip |
| 01:56.58 | DocScrutinizer | and it just says "typical" on p.3 |
| 01:57.25 | DocScrutinizer | this doesn't mean it's always the correct way to design it |
| 01:57.32 | wpwrak | no APP note. only MAC-PHY. let's see what the schematics offer .. |
| 01:57.35 | wpwrak | heh ;-) |
| 01:57.35 | DocScrutinizer | esp regarding that C1+2 part |
| 01:57.45 | wpwrak | "this is how people typically get it wrong" ;-) |
| 01:58.55 | roh | i meant lte dongles |
| 01:59.47 | roh | http://www.modem3g.com/samsung-gt-b3740-lte-vodafone-stick-4g-usb-modem-100mbps.html |
| 02:00.14 | DocScrutinizer | wpwrak: btw you noticed that this typical circuit on p.3 is about a component for auto-crossover |
| 02:01.06 | DocScrutinizer | which may well imply different circuitry inside chip regarding TX drivers than what's usually found on a non-xover version |
| 02:01.34 | DocScrutinizer | which in turn means that those TCT and RCT are diferent too |
| 02:01.49 | wpwrak | all voltage rails (V3.3, 1.8, and 2.5) connected to each other |
| 02:02.00 | DocScrutinizer | honestly read your chip datasheet, it has to yield some clue |
| 02:02.22 | DocScrutinizer | n8 |
| 02:02.30 | wpwrak | okay, thanks ! |
| 02:03.02 | wpwrak | i think the data sheet is hopeless. but at least there's nothing directly contradicting our design in the reference design |
| 02:07.40 | DocScrutinizer | your mayor problem is RCT |
| 02:08.46 | wpwrak | i don't now what to do about it |
| 02:08.53 | DocScrutinizer | as TCT will either just outright fail when done wrong, or will just result in output voltage doubled |
| 02:09.08 | wpwrak | the part we haev to J4 is too confusing |
| 02:09.20 | DocScrutinizer | for RCT it depends on what the inputs need for bias |
| 02:10.15 | wpwrak | the reference design (that assumed a symmetric transformer) has positive voltage on TCT and RCT |
| 02:11.03 | wpwrak | assumed->assumes |
| 02:11.34 | DocScrutinizer | then that's all ok |
| 02:12.26 | DocScrutinizer | also those 4 pcs 49.9R (what a value ;-D) suggest that |
| 02:13.47 | wpwrak | 50 Ohm seems to be unusual. so they optimized the sourcing for us. it's like this also in the reference design :) |
| 02:29.02 | *** join/#qi-hardware rejon (~rejon@118.143.62.3) |
| 02:52.09 | *** join/#qi-hardware wej (~j@m2.mullvad.net) |
| 03:38.16 | *** join/#qi-hardware panda|x201 (~hzhang@2001:5c0:1000:a::9bb) |
| 04:09.08 | *** join/#qi-hardware jekhor (~jek@leased-line-46-53-195-5.telecom.by) |
| 04:23.32 | qi-bot | [commit] Werner Almesberger: bacon/case/: top case part (almost machineable fped model) (master) http://qi-hw.com/p/wernermisc/b54f4a5 |
| 04:23.33 | qi-bot | [commit] Werner Almesberger: cameo/zstack.pl: convert 2.5D paths into a stack with limited Z steps (master) http://qi-hw.com/p/cae-tools/085754f |
| 04:23.34 | qi-bot | [commit] Werner Almesberger: cameo/fped2d2z.pl: convert fped 2D stacks into 2.5D paths with Z information (master) http://qi-hw.com/p/cae-tools/219e0a5 |
| 04:23.36 | qi-bot | [commit] Werner Almesberger: cameo/zstack.pl: option -r to reverse the stack (master) http://qi-hw.com/p/cae-tools/5ecce7d |
| 04:23.38 | qi-bot | [commit] Werner Almesberger: cameo: "area" now works on Z layers individually (untested) (master) http://qi-hw.com/p/cae-tools/18c9477 |
| 04:23.40 | qi-bot | [commit] Werner Almesberger: cameo/area.c (subordinates): fix trimming of list of subordinates (master) http://qi-hw.com/p/cae-tools/fb117b2 |
| 04:23.42 | qi-bot | [commit] Werner Almesberger: gp2rml: improved distance calculation; corrected compiler invocation (master) http://qi-hw.com/p/cae-tools/76b1b3e |
| 05:40.52 | *** join/#qi-hardware cladamw (~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw) |
| 06:02.23 | *** join/#qi-hardware rejon (~rejon@awork065028.netvigator.com) |
| 06:12.22 | DocScrutinizer | *sigh* |
| 06:12.40 | DocScrutinizer | 5 min sleep, how refreshing ;) |
| 06:13.27 | wolfspra1l | treat yourself well |
| 06:26.28 | DocScrutinizer | hah, my plans were different. I would enjoy retirement since 12 years, and only do jobs I like |
| 06:27.06 | DocScrutinizer | :-/ |
| 06:29.40 | DocScrutinizer | last naviy cis yesterday gave me strange mod, when Gibs told his boss "Vacations? do something pleasant? No thanks, my job is pleasant enough" |
| 06:29.47 | DocScrutinizer | mood* |
| 06:44.22 | wpwrak | that's the spirit ! :) |
| 06:54.27 | DocScrutinizer | that's the job for this spirit - at least for him |
| 06:56.00 | DocScrutinizer | well, I guess I should be happy it's some LTE module I may work on with winXP and clearcase and without proper docs even inhouse |
| 06:57.19 | DocScrutinizer | though quite obviously my company would make beter use of my talents when I was in chip design, not driver debugging |
| 06:58.54 | DocScrutinizer | I mean, when you got a function block with 5 fifo, but only 4 of them have the appropriate IRQs roted to IRQ controller... :-/ |
| 06:59.46 | DocScrutinizer | routed*, and this takes me 2 weeks to find out, when the according macro for the IRQ line is not defined in our sources |
| 07:00.29 | DocScrutinizer | you wonder what those chip designers do whole day |
| 07:02.50 | wpwrak | they spend their days thinking about practical jokes to play on the sw guys ;-) |
| 07:15.06 | *** join/#qi-hardware mrrhq (~mrrhq@c-67-160-138-174.hsd1.or.comcast.net) |
| 07:32.27 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 07:33.08 | *** join/#qi-hardware jekhor (~jek@mx2.promwad.com) |
| 07:33.24 | *** join/#qi-hardware LunaVorax (~LunaVorax@ABordeaux-651-1-152-50.w109-222.abo.wanadoo.fr) |
| 07:43.04 | *** join/#qi-hardware jekhor (~jek@mx2.promwad.com) |
| 07:49.05 | DocScrutinizer | obviously ;-) |
| 08:00.31 | qi-bot | [commit] Xiangfu: cgminer: add /etc/init.d/cgminer for autostart (master) http://qi-hw.com/p/openwrt-packages/f5c5a97 |
| 08:42.50 | *** join/#qi-hardware wolfspraul (~wolfsprau@222.130.122.205) |
| 08:43.57 | *** join/#qi-hardware rejon (~rejon@118.143.62.3) |
| 09:22.35 | *** join/#qi-hardware ezdagor (4cb28826@gateway/web/freenode/ip.76.178.136.38) |
| 09:23.40 | *** join/#qi-hardware Ayla (~paul@53.121.101.84.rev.sfr.net) |
| 09:36.33 | *** join/#qi-hardware killertux (~tux@en57.kuusnetikka.fi) |
| 09:46.49 | *** join/#qi-hardware cladamw (~Adam@host-222.80-43-115.dynamic.totalbb.net.tw) |
| 10:10.18 | ezdagor | Which configure options should I pass along to mp3lib? I'm trying to get GMU working... |
| 10:15.27 | xiangfu | ezdagor, make TARGET=nanonote MORE_DECODERS="decoders/mpg123.so" when compile gmu |
| 10:15.54 | xiangfu | ezdagor, also you needs compile libmpg123 by yourself. |
| 10:16.38 | ezdagor | Nod. I have. I noticed there are several options (for libmpg123) for "no fpu" machines. Just not sure which one to use. |
| 10:17.15 | ezdagor | mpg123 plays MP3s fine. But, when I launch and then run GMU, it doesn't work. |
| 10:17.30 | ezdagor | I mean, it won't play MP3s. |
| 10:19.32 | ezdagor | Let me run through this once more. Then i'll try from scratch, using your suggestions. |
| 10:20.31 | wolfspraul | suggestions? :-) I need to purge all this from the chatlogs... oh well :-) |
| 10:20.53 | wolfspraul | ben nanonote cannot play mp3 |
| 10:21.14 | wolfspraul | if you proove otherwise we send you straight to some good friends we know who will take care of you :-) |
| 10:21.18 | wolfspraul | (just kidding, just kidding) |
| 10:26.55 | zrafa | whitequark: when usb host idea came (and we knew v-usb exists) we found this as well http://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/s2007/blh36_cdl28_dct23/blh36_cdl28_dct23/index.html |
| 10:42.13 | *** join/#qi-hardware DocScrutinizer (~halley@openmoko/engineers/joerg) |
| 11:00.07 | whitequark | now this is more interesting |
| 11:00.41 | *** join/#qi-hardware GNUtoo (~gnutoo@host155-102-dynamic.10-188-r.retail.telecomitalia.it) |
| 11:07.21 | wej | ezdagor, have a look at the BUILD.txt file. everything is explained there, there is no such thing as MORE_DECODERS |
| 11:07.27 | wej | it is DECODERS_TO_BUILD |
| 11:11.13 | wej | also for libmpg123 you should use the generic-no-fpu flag. |
| 11:14.59 | *** join/#qi-hardware urandom__ (~user@p548A4381.dip.t-dialin.net) |
| 11:20.11 | Ayla | jz-kernel 3.3 soon? :D |
| 11:28.18 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 11:28.22 | *** join/#qi-hardware jluis (~jpddb@83.247.136.72) |
| 11:29.58 | DocScrutinizer | hah, nice. A sw USB HC implementation |
| 11:55.26 | Ayla | now we just need a linux driver for it |
| 12:01.40 | zear | does USB HC for any chance stand for "host controller"? |
| 12:01.58 | zear | ha, yes! Awesome |
| 12:03.16 | Ayla | with such a driver, and the UBB, we could have USB host on the dingoo/nanonote :D |
| 12:04.35 | GNUtoo | but is the hardware capable of it? |
| 12:04.46 | GNUtoo | because usb device don't have that many endpoints |
| 12:05.49 | zear | well, for one you wouldn't be able to plug devices that don't have their own power source |
| 12:05.59 | Ayla | I believe it just needs four GPIOs |
| 12:06.00 | zear | because (at least in the dingoo, but i bet also the nn) the usb port is unpowered |
| 12:06.13 | zear | but any other than that - i've got no idea |
| 12:06.28 | zear | but it would be nice if only for "linking" two devices together |
| 12:11.59 | wpwrak | zear: on the ben, you'd use UBB. as far s i remember, you can't bit-bang the USB controller enough to do some kind of reverse host |
| 12:12.22 | wpwrak | zear: with UBB, you have a 3.3 V power supply. so add a step-up converter, and voila ... |
| 12:12.40 | zear | :) |
| 12:22.43 | *** join/#qi-hardware cladamw (~adamwang@host-222.80-43-115.dynamic.totalbb.net.tw) |
| 12:25.24 | Ayla | wpwrak: but that software implementation does bit-bang the USB controller, no? |
| 12:28.10 | whitequark | Ayla: no, it bangs some GPIOs |
| 12:28.19 | whitequark | bit-banging USB controller is impossible, at least on NN |
| 12:28.30 | whitequark | and, well, it is barely enough for maybe an USB mouse or keyboard |
| 12:28.36 | whitequark | no WiFi, no mass storage |
| 12:28.38 | Ayla | I don't get the difference |
| 12:29.08 | whitequark | it won't work with the integrated USB port because processor pins which go to the port cannot be bit-banged |
| 12:29.19 | whitequark | but the pins going to 8:10 slot can be |
| 12:30.03 | Ayla | I know, what I meant is to use the UBB |
| 12:31.17 | Ayla | ok, I didn't understand what wpwrak said, now I get it |
| 12:33.13 | wpwrak | whitequark: yeah, the problem with mass-storage is that the device gets to choose whether we use low- or full-speed. there's no negotiation. and low-speed USB disks are kinda hard to find ... :) |
| 12:34.25 | whitequark | wpwrak: to be fair, I just thought that it'd be a performance disaster |
| 12:34.49 | whitequark | e.g. bitbanging an SD card on MIPS routers is _painfully_ slow (10k/s maybe) even on 250mhz or something |
| 12:34.58 | whitequark | and here we have a slow device and a protocol with even more overhead |
| 12:35.01 | whitequark | plus a non-RTOS |
| 12:35.32 | whitequark | but yes, absence of negotiation makes this just impossible |
| 12:36.56 | Ayla | whitequark, I get 250kb/s on dreamcast |
| 12:37.05 | Ayla | (bitbanging an SD card) |
| 12:37.14 | whitequark | Ayla, what platform is it? |
| 12:37.18 | whitequark | CPU/SoC |
| 12:37.26 | Ayla | SuperH 4 |
| 12:37.32 | whitequark | no knowledge of that |
| 12:37.42 | whitequark | these 10k/s come from my experience with wrt54gl |
| 12:37.58 | whitequark | maybe it was a little bit faster, but still unsuitable for anything real |
| 12:38.31 | Ayla | I *think* the implementation on dreamcast uses the 4-bit interface, not the 1-bit one |
| 12:38.40 | whitequark | I doubt it |
| 12:38.46 | whitequark | there is no spec for the 4-bit iface |
| 12:39.12 | Ayla | hmm |
| 12:39.16 | whitequark | if this is opensource, then a) it is violating some copyright laws b) can I take a look? |
| 12:39.42 | Ayla | sure, take a look at the Linux source code |
| 12:40.10 | whitequark | ah. |
| 12:40.15 | whitequark | no, it is SPI interface |
| 12:40.19 | whitequark | even slower than the 1-bit one |
| 12:40.41 | whitequark | see, SD cards have four data lanes, each running on 25MHz |
| 12:40.51 | whitequark | bound together, they can form a 100 Mbit/s interface |
| 12:40.55 | whitequark | but it is proprietary and closed |
| 12:41.20 | whitequark | (they have even higher speeds, but I don't know anything about that) |
| 12:43.10 | Ayla | ah, yes, I saw the 4-bit interface when reading some code, but it was not on the mmc-gpio driver |
| 12:45.43 | Ayla | well, the dreamcast implementation does use SPI |
| 12:45.57 | whitequark | yes, it is significantly faster than bitbanging |
| 12:46.13 | whitequark | depending on impl it can reduce the amount of functions called in kernel by 4x to 16x |
| 12:46.43 | Ayla | it's still bitbanging, the SD is connected to four GPIOs |
| 12:46.49 | whitequark | nope |
| 12:46.57 | whitequark | hardware SPI is not bitbanging |
| 12:47.03 | whitequark | it is a proper way to hook up an SD card |
| 12:47.07 | whitequark | through not very fast |
| 12:47.13 | Ayla | the hardware has no SPI |
| 12:47.14 | whitequark | my MIPS router did not have a hardware SPI port |
| 12:47.16 | whitequark | ahh |
| 12:48.16 | Ayla | the UART controller of the dreamcast can be disactivated, so that the TX/RX and CTS/RTS lines can be used as GPIO |
| 12:48.36 | Ayla | that's where the SD is connected |
| 13:34.37 | whitequark | wpwrak: suppose I want to connect two microcontrollers |
| 13:35.01 | whitequark | one has 2.8V IO and the other one has 3.3V IO (but the actual voltage is near to 3.0 due to Schottky diode in the VDD) |
| 13:35.26 | whitequark | should placing a 200 ohm resistors between every IOs enough to protect the low-voltage uC? |
| 13:41.29 | roh | whitequark: depends on the uC. sometimes it does. for when not or you need high speed its better to use level shifters |
| 13:55.00 | *** join/#qi-hardware aisa_ (~a@c-68-35-162-196.hsd1.nm.comcast.net) |
| 13:56.51 | *** join/#qi-hardware aisa (~a@c-68-35-162-196.hsd1.nm.comcast.net) |
| 14:09.47 | kristianpaul | <PROTECTED> |
| 14:09.54 | kristianpaul | GNUtoo: |
| 14:10.13 | kristianpaul | you just need bit.bang to drive that logic |
| 14:10.19 | kristianpaul | sorry late comment.. |
| 14:16.27 | GNUtoo | ok |
| 14:21.41 | *** join/#qi-hardware wej (~j@m2.mullvad.net) |
| 15:16.54 | whitequark | roh: I think it's 9600 baud. maybe 115200, but definitely not more |
| 15:17.02 | *** join/#qi-hardware frankblues (~alex@c-67-182-230-190.hsd1.ut.comcast.net) |
| 15:17.11 | *** join/#qi-hardware panda|x201 (~hzhang@2001:5c0:1000:a::e91) |
| 15:20.42 | *** join/#qi-hardware frankblues (~alex@c-67-182-230-190.hsd1.ut.comcast.net) |
| 15:26.45 | wpwrak | whitequark: depends on whether you have clamp diodes on the 3.3 V side and how they are rated |
| 15:27.12 | wpwrak | but yes, the voltage differential seems to be small enough that there usually shouldn't be problems |
| 15:42.12 | whitequark | wpwrak: on the 3V3 side there's STM32 |
| 15:42.21 | whitequark | it should be able to deal with 10mA of current or something like that |
| 15:43.06 | wpwrak | the higher-voltage side is usually the one who suvives :) |
| 15:51.15 | *** join/#qi-hardware emeb (~ericb@ip72-223-81-94.ph.ph.cox.net) |
| 16:00.56 | whitequark | yeah, I was a bit surprised by your question |
| 16:01.10 | whitequark | did you mean "clamp diodes on 2V8 side?" |
| 16:23.09 | *** join/#qi-hardware panda|x201 (~hzhang@2001:5c0:1000:a::e91) |
| 16:26.11 | wpwrak | yes |
| 16:26.28 | wpwrak | ah .. indeed, i was confused. now i see it :) |
| 16:28.25 | whitequark | so |
| 16:28.31 | whitequark | I don't know anything about 2.8V side |
| 16:28.37 | whitequark | but it has an ARM926EJS core |
| 16:28.51 | whitequark | ... and it has successfully withstanded a connection of 3.3V UART without any damage |
| 16:29.00 | whitequark | (I, errrr, misread the datasheet) |
| 16:33.27 | *** join/#qi-hardware jekhor (~jek@leased-line-46-53-195-5.telecom.by) |
| 16:58.49 | *** join/#qi-hardware kilae (~chatzilla@catv-161-018.tbwil.ch) |
| 16:59.03 | wpwrak | ;-) |
| 17:38.52 | kristianpaul | reads about Eye-fi cards |
| 17:45.43 | *** join/#qi-hardware wej (~j@m2.mullvad.net) |
| 17:47.28 | kristianpaul | argh, boring |
| 17:53.37 | wpwrak | ;-) |
| 17:53.53 | kristianpaul | mix of saas plus wifi you dont know what does.. |
| 17:54.38 | kristianpaul | hardware driven by SaaS is scary more if related to personal stuff |
| 17:58.11 | whitequark | eyefi is almost dead afaik |
| 17:58.25 | whitequark | seriously. you won't find a good SDIO wifi card. I searched for months |
| 17:58.29 | whitequark | http://www.microchip.com/pagehandler/en-us/press-release/microchips-8051-mcus-are-100-c.html |
| 17:58.36 | whitequark | wpwrak: just look at these necrophiliacs |
| 17:58.52 | viric | whitequark: there is that relatively new chip from TI |
| 17:59.14 | viric | whitequark: not a sdio card, but it's a full wifi device in a block, with sdio interface. |
| 18:03.19 | kristianpaul | whitequark: yeah, i decied move to wpan definitelly |
| 18:03.35 | kristianpaul | for the nanonote wireless link |
| 18:06.10 | viric | I can't find the TI link |
| 18:06.16 | viric | but the chip was sold for 30€ |
| 18:06.52 | whitequark | viric: so the device would be twice as expensive |
| 18:07.16 | whitequark | nah. I'd rather buy, like, three android tablets for the same cost. it's the problem with wifi. |
| 18:07.30 | viric | whitequark: http://openlink.org/ |
| 18:07.36 | whitequark | wpan is a good project as of itself, but not a solution to the wifi problem. |
| 18:08.11 | whitequark | viric: TI's wireless drivers are of exceptionally bad quality |
| 18:08.36 | whitequark | and, at least in some cases, they require some parts of the stack to be blobs while being advertised as "open" |
| 18:08.39 | kristianpaul | <PROTECTED> |
| 18:08.41 | whitequark | not sure if in this they do |
| 18:08.45 | viric | whitequark: I've no idea about that |
| 18:08.51 | whitequark | kristianpaul: not quite |
| 18:09.14 | whitequark | you're not going anywhere saying "I don't like all that technology produced in counts of billion because I just don't like it" |
| 18:09.28 | whitequark | ("because it's nonfree" = "because I don't like it") |
| 18:09.41 | kristianpaul | no no i dont want meant that |
| 18:09.50 | whitequark | as I've said |
| 18:10.17 | whitequark | 802.15.14 is great and it has a really interesting future as a part of "Internet of Things" or how do they call wireless sensor networks |
| 18:10.48 | whitequark | but it is very new (in terms of market) yet, I'd say |
| 18:11.04 | viric | isn't there bluetooth over sdio and ip over bluetooth? |
| 18:11.07 | whitequark | not known to general public. not even mostly known to geeks (compare with Arduino, or maybe Atmel) |
| 18:11.38 | whitequark | viric: theoretically yes |
| 18:11.47 | kristianpaul | bluetooth have pan ys |
| 18:11.50 | whitequark | but IP over Bluetooth is either PPP or encapsulateed ethernet |
| 18:12.06 | whitequark | good luck implementing that (apart from the fact that bt is just as nonfree as wifi is) |
| 18:12.45 | viric | ok |
| 18:13.19 | whitequark | well, I'm not saying it is hard as it is |
| 18:13.21 | whitequark | linux already does both |
| 18:13.31 | whitequark | but it relies on a non-free firmware in the dongle |
| 18:16.31 | whitequark | viric: (openlink) wait, that might be more sane than I thought |
| 18:16.43 | whitequark | did they just release a fully open wifi stack? |
| 18:17.36 | viric | whitequark: That happened one year ago... and I thought I might use it with one of those sdio boards... |
| 18:17.51 | viric | what was the name... made by wpwrak |
| 18:18.15 | whitequark | viric: UBB? |
| 18:18.18 | viric | that. |
| 18:18.33 | viric | but I got interested by other things meantime :) |
| 18:19.03 | whitequark | procrastination! |
| 18:19.42 | viric | whitequark: go investigate the openlink :) I did not read deep about it |
| 18:23.06 | *** join/#qi-hardware LunaVorax (~LunaVorax@ABordeaux-651-1-152-50.w109-222.abo.wanadoo.fr) |
| 18:26.00 | whitequark | well |
| 18:26.16 | whitequark | looks a 40 episodes long series of some random youtube shit |
| 18:27.09 | kristianpaul | whitequark: better get your milkymist and experiment a bit? :) |
| 18:27.51 | *** join/#qi-hardware GNUtoo-desktop (~GNUtoo@host155-102-dynamic.10-188-r.retail.telecomitalia.it) |
| 18:29.29 | whitequark | kristianpaul: my brain is too sleepy to do anything sensible now, unfortunately |
| 18:29.41 | whitequark | but when I'd get rid of higher priority projects, it's M1 time |
| 18:29.59 | kristianpaul | good ! |
| 18:30.03 | whitequark | it is a good opportunity to make something really useful. shouldn't miss it. |
| 19:07.44 | qi-bot | [commit] Werner Almesberger: cameo/zstack.pl (usage): describe option -r (master) http://qi-hw.com/p/cae-tools/ce243b6 |
| 19:07.44 | qi-bot | [commit] Werner Almesberger: cameo/fped2d2z.pl: added option -r, like in zstack.pl (master) http://qi-hw.com/p/cae-tools/9f5751a |
| 19:07.46 | qi-bot | [commit] Werner Almesberger: cameo/fped2d2z.pl: added Z position substitution (master) http://qi-hw.com/p/cae-tools/4ea94e7 |
| 19:07.46 | qi-bot | [commit] Werner Almesberger: bacon/case/: various bits and pieces for parametrization and correct positioning (master) http://qi-hw.com/p/wernermisc/3e39ae0 |
| 19:39.57 | qi-bot | The build was successful: http://fidelio.qi-hardware.com/~xiangfu/build-nanonote/openwrt-xburst.full_system-20120318-1841 |
| 19:50.27 | *** join/#qi-hardware GNUtoo-desktop (~GNUtoo@host155-102-dynamic.10-188-r.retail.telecomitalia.it) |
| 19:53.32 | kristianpaul | haha http://www.techradar.com/news/internet/pirate-bay-to-take-its-servers-to-the-skies-1072089 |
| 19:59.23 | Ayla | awesome :) |
| 20:02.43 | larsc | free clay pigeons! ;) |
| 20:05.18 | kristianpaul | roh: whitequark you know the thiness of the osPID case? |
| 20:05.48 | kristianpaul | I'm planning do sent to manufacture another M1 case, and was hoping also take advatage os full acrylic sheet so.. :-) |
| 20:23.34 | whitequark | kristianpaul: hm no |
| 20:23.41 | whitequark | but they have CAD files lying around at github |
| 20:23.51 | whitequark | osPID still not arrived yet, so I can't just measure it |
| 20:24.28 | kristianpaul | cad are 2d svg |
| 20:24.44 | kristianpaul | i dint noticed acrylic specs on the file |
| 20:24.47 | *** join/#qi-hardware frankblues (~alex@c-67-182-230-190.hsd1.ut.comcast.net) |
| 20:25.01 | kristianpaul | anyway alreay sent those to get a quote lets wait for tomorrow :) |
| 20:42.26 | *** join/#qi-hardware GNUtoo (~gnutoo@host155-102-dynamic.10-188-r.retail.telecomitalia.it) |
| 21:00.17 | *** join/#qi-hardware dandon (~dandon@178-191-248-72.adsl.highway.telekom.at) |
| 21:08.36 | *** join/#qi-hardware LunaVorax (~LunaVorax@ABordeaux-651-1-39-238.w109-223.abo.wanadoo.fr) |
| 21:20.12 | *** join/#qi-hardware GeorgeH (~George@c-69-141-105-145.hsd1.nj.comcast.net) |
| 21:34.14 | *** join/#qi-hardware LunaVorax (~LunaVorax@ABordeaux-651-1-39-238.w109-223.abo.wanadoo.fr) |
| 21:37.39 | whitequark | kristianpaul: oh. full acrylic sheet |
| 21:38.38 | whitequark | this will probably be my source of pain |
| 21:54.45 | kristianpaul | why? |
| 22:22.36 | whitequark | because I want my case to be made from exactly "2mm green transparent acrylic" |
| 22:23.03 | whitequark | and my initial investigation suggests that this is by some reason not the most often sourced material in local fabs |
| 22:23.41 | whitequark | (apart from the part that a lot of them will refuse to work with me whatsoever if the cost of work is less than $200. that's several meters of acrylic sheet.) |
| 22:35.02 | *** part/#qi-hardware frankblues (~alex@c-67-182-230-190.hsd1.ut.comcast.net) |
| 22:48.14 | kristianpaul | hmm |
| 23:14.57 | roh | acryllic 3mm is about 30-50E per m² |
| 23:26.54 | *** join/#qi-hardware kyak (~kyak@unaffiliated/kyak) |
| 23:32.10 | *** join/#qi-hardware wpwrak (~werner@234-171-231-201.fibertel.com.ar) |
| 23:41.25 | *** join/#qi-hardware urandom__ (~user@p548A4381.dip.t-dialin.net) |
| 23:42.51 | *** join/#qi-hardware jluis_ (~jluis@2001:5c0:1400:a::67) |