| 00:26.37 | *** join/#edev dasf (n=jamesdoe@pool-71-252-234-221.dllstx.fios.verizon.net) |
| 00:34.12 | *** join/#edev joe_bleau (n=joe_blea@adsl-68-90-142-36.dsl.fyvlar.swbell.net) |
| 01:15.08 | *** join/#edev Off_Namuh (i=GPS@gateway/tor/x-f7a6ba825101053c) |
| 01:25.36 | *** join/#edev FireEgl (i=FireEgl@Sebastian.Tcldrop.Com) |
| 01:32.48 | CP|too | his name isn't tomw |
| 01:33.23 | *** join/#edev redblue (i=star@ppp055.109-253-207.mtl.mt.videotron.ca) |
| 01:49.30 | *** join/#edev ico2_ (n=ico2@modem-633.chameleon.dialup.pol.co.uk) |
| 03:10.20 | *** join/#edev Off_Namuh (i=GPS@gateway/tor/x-4a73389226e4d85e) |
| 03:14.25 | *** join/#edev prpplague (n=dave@ppp-70-244-172-90.dsl.rcsntx.swbell.net) |
| 03:18.48 | *** join/#edev linac (n=lin@167.86.76.222.broad.fz.fj.dynamic.163data.com.cn) |
| 03:47.38 | *** join/#edev DrZimmerman (n=theo@2001:5c0:8fff:fffe:0:0:0:6af1) |
| 03:50.50 | *** join/#edev ico2_ (n=ico2@modem-633.chameleon.dialup.pol.co.uk) |
| 05:28.04 | *** join/#edev steliosk (n=Stelios@ipa226.211.tellas.gr) |
| 05:51.07 | *** join/#edev ico2__ (n=ico2@modem-1451.chimpanzee.dialup.pol.co.uk) |
| 06:05.39 | *** join/#edev MonMotha (n=monmotha@c-69-246-220-205.hsd1.in.comcast.net) |
| 06:23.29 | *** join/#edev lyakh (n=lyakh@dynamic-unidsl-85-197-26-24.westend.de) |
| 06:50.35 | *** join/#edev emil|k (n=emil|k@78.54.12.211) |
| 08:05.58 | *** join/#edev redblue (i=star@ppp123.108-253-207.mtl.mt.videotron.ca) |
| 08:36.04 | *** join/#edev _Exiles (i=wired57@is.a.unixwhore.info) |
| 09:53.07 | *** join/#edev ccjoe (n=ccjoe@c-67-166-124-229.hsd1.co.comcast.net) |
| 10:17.09 | *** join/#edev gener1c (n=Generic@unaffiliated/gener1c) |
| 10:17.16 | gener1c | hey |
| 10:17.37 | gener1c | anybody knows how to use this? http://www.vanguard-co.com.my/contents/product/test_measuring/beha/unitest/6742.htm |
| 10:19.01 | *** join/#edev gener1c (n=Generic@unaffiliated/gener1c) |
| 10:31.56 | *** join/#edev emil|k_ (n=emil|k@e179238194.adsl.alicedsl.de) |
| 12:21.34 | *** join/#edev leoncamel (n=leoncame@p6024-ipbfp305fukuokachu.fukuoka.ocn.ne.jp) |
| 13:02.24 | *** join/#edev lyakh (n=lyakh@dynamic-unidsl-85-197-26-24.westend.de) |
| 13:04.52 | *** join/#edev GPSFan (n=kenm@12.10.255.248) |
| 13:04.52 | *** mode/#edev [+o GPSFan] by ChanServ |
| 13:14.02 | *** join/#edev brad_mssw (n=brad@shop.monetra.com) |
| 13:16.44 | *** join/#edev prpplague (n=DaveAnde@mail.americanmicrosystems.com) |
| 13:17.11 | prpplague | morning all |
| 13:17.19 | prpplague | GPSFan / jbevren : ping |
| 13:17.32 | GPSFan | prpplague: g'day.. |
| 13:18.11 | prpplague | GPSFan: morning |
| 13:18.56 | prpplague | GPSFan: question, can you give me a short list of things (other than being busy with other work), that are holding up your tinkering with the hammer? |
| 13:19.08 | prpplague | GPSFan: want to get those items addressed and make some notes |
| 13:22.22 | GPSFan | prpplague: ok, first is the lack of 2.6 mmc & enc28j60 driver, it none existed it would be a "write fropm scratch" but since you say one is "almost ready, but lacking release approval" . Next is waiting for the "latest release" of the rootfs code that you said would be on the wiki a few days ago (or yesterday. |
| 13:23.16 | prpplague | GPSFan: yea, i;ve been swampped with work, i'm about 3 days behind |
| 13:23.25 | prpplague | GPSFan: those are the main issues? |
| 13:23.25 | GPSFan | prpplague: I don't want to go off making changes & patches to something that's already fixed. |
| 13:23.37 | prpplague | GPSFan: indeed |
| 13:24.13 | prpplague | GPSFan: any other issues other than kernel code? |
| 13:24.47 | GPSFan | thost are keeping me from getting anywhere on those two parts of the project. The kernel compiles fine, as does rootfs, so the buildroot is ok (except for the above) and I ahve the 5Vpower issue under control. |
| 13:25.25 | prpplague | GPSFan: okie dokie, i forgot what project are you working on? |
| 13:25.43 | GPSFan | I have had networking via a usb dongle running. |
| 13:25.56 | GPSFan | mmc & enc28j60 |
| 13:26.40 | prpplague | GPSFan: sorry i meant what kind of project are you planning to use the hammer with? |
| 13:28.50 | prpplague | GPSFan: i did tell you the current driver does not utilize the spi subsystem, right? |
| 13:28.53 | GPSFan | prpplague: ah, that's all really a tbd, I just like the form factor. I have a small formfactor dstn color LCD that I'd like to check out as well as a couple of small mono lcd's but the platform needs low power ehternet, and since I did most of the zipit mmc driver I thought I'd poke in there too. |
| 13:29.04 | GPSFan | yes. |
| 13:29.27 | prpplague | GPSFan: okie dokie, got a url of the dstn you are planning to use? |
| 13:30.08 | prpplague | GPSFan: well the mmc driver for the zipit could be used, but the spi-mmc driver in the kernel would be prefered |
| 13:30.50 | GPSFan | prpplague: not sure it's still made, but the interconnection & driver work will be useful for other lcd's |
| 13:31.21 | prpplague | GPSFan: yea i figured as much |
| 13:31.47 | prpplague | GPSFan: as far as the driver work, the s3c2410 fb is very robust, and you really would only need to plug in the values for the lcd |
| 13:33.08 | GPSFan | prpplague: I gathered that from your comments over the last few months, it just needs a roadmap for others to be able to follow. |
| 13:33.19 | *** join/#edev dasf (n=jamesdoe@pool-71-252-234-221.dllstx.fios.verizon.net) [NETSPLIT VICTIM] |
| 13:33.35 | prpplague | GPSFan: agreed |
| 13:33.36 | GPSFan | prpplague: as well as how to deal with issues of bias generation, and possibly level translation. |
| 13:34.33 | prpplague | GPSFan: question, have you got a pinout that you are using for your enc28j60 configuration? |
| 13:34.47 | prpplague | GPSFan: i'd like to set mine up here the same as yours |
| 13:35.39 | GPSFan | hold on a bit... |
| 13:35.44 | prpplague | GPSFan: btw, the rev2 of the carrier board will remove the 5v regulator and the wall-wort be replace with a 1.5A +5v regulated one |
| 13:35.57 | GPSFan | good plan. |
| 13:40.00 | GPSFan | prpplague: I haven't drawn up a diagram as yet, but it's all wired up as shown http://elinux.org/How_to_Enc28j60 the pin connections are as follows: |
| 13:41.40 | GPSFan | enc -- hammer. 1 - 7, 2 - 6, 3 - 5, 4 - nc, 5 - 8, 6 - nc, 7 - 11, 8 - 9, 9 - gnd, 10 - tp9 |
| 13:42.51 | prpplague | GPSFan: ok thanks i'll grab the pinouts from sparkfun and see if i can make a table entry |
| 13:43.53 | *** join/#edev lyakh_ (n=lyakh@dynamic-unidsl-85-197-26-24.westend.de) |
| 13:45.26 | GPSFan | prpplague: I just updated that wiki page with the list, at least now it's documented. |
| 13:45.49 | *** join/#edev sjdsphreaker (n=sjdsphre@72.22.146.148) |
| 13:46.12 | *** part/#edev sjdsphreaker (n=sjdsphre@72.22.146.148) |
| 14:05.24 | chouimat | morning |
| 14:22.05 | prpplague | chouimat: morning |
| 14:22.10 | prpplague | GPSFan: http://www.elinux.org/How_to_Enc28j60 better? |
| 14:32.25 | *** join/#edev dfarnsworth_ (n=dfarnswo@65.200.49.156) |
| 14:51.08 | prpplague | GPSFan: got the ok for the enc28j60 code, cleaning it up now |
| 14:51.24 | prpplague | GPSFan: should have the basic driver out there for you by eod |
| 14:52.16 | *** join/#edev lyakh_ (n=lyakh@dynamic-unidsl-85-197-26-24.westend.de) |
| 15:03.44 | *** join/#edev CosmicPenguin (n=nobody@crank.laptop.org) |
| 15:11.50 | prpplague | GPSFan: the driver currently is configured to use SPI1, i'll make the change to use SPI0 |
| 15:30.41 | *** join/#edev ico2 (n=ico2@modem-1772.chameleon.dialup.pol.co.uk) |
| 15:44.09 | brad_mssw | CosmicPenguin: oh, btw, that setpci hack doesn't work for the soekris net5501 .... for whatever reason, when the amd74xx module is loaded it resets the bit, so lspci -xxxnv shows 40 as 00 again (though before the module loading, it does show 02 properly) |
| 15:45.56 | CosmicPenguin | it resets the bit? |
| 15:46.04 | CosmicPenguin | where? |
| 15:46.07 | *** join/#edev ico2_ (n=ico2@modem-1772.chameleon.dialup.pol.co.uk) |
| 16:23.17 | *** join/#edev ico2_ (n=ico2@modem-1838.cougar.dialup.pol.co.uk) |
| 16:29.27 | GPSFan | prpplague: thanks, wiki page is better, I'll look for the driver later today. ;>)) |
| 16:30.20 | prpplague | GPSFan: doing some testing on it now |
| 16:30.29 | prpplague | GPSFan: its by no means perfect, but its a start |
| 16:31.13 | *** join/#edev lyakh_ (n=lyakh@dynamic-unidsl-85-197-26-24.westend.de) |
| 16:31.56 | brad_mssw | CosmicPenguin: that DMA issue we were working on ... |
| 16:32.20 | CosmicPenguin | where in the code does the PCI space get changed? |
| 16:32.41 | brad_mssw | CosmicPenguin: oh, haven't looked at the amd74xx code ... |
| 16:33.01 | brad_mssw | CosmicPenguin: just noting that when loading the driver, it gets set back to bios defaults |
| 16:33.10 | CosmicPenguin | you can't assume that the driver changes the bit without verifying that the driver actually resets the bit |
| 16:33.12 | brad_mssw | CosmicPenguin: which means I need to bang on soekris to update their bios |
| 16:33.16 | CosmicPenguin | thatss why we have source code |
| 16:33.47 | CosmicPenguin | There really isn't any reason why the amd74xx would have occassion to muck around in the PCI space, which is why I was interested in knowing where it happened |
| 16:33.53 | brad_mssw | CosmicPenguin: well, loading the module resets it, whether the driver is responsible or not is moot at this point (to me at least) ... pretty much tells me that trying to 'hack' a userland fix isn't going to work |
| 16:34.15 | brad_mssw | just need to get my vendor to fix their bios |
| 16:34.42 | CosmicPenguin | yes, but if the driver is behaving badly, then that needs to be fixed as well |
| 16:36.03 | brad_mssw | I think the driver is sane, though I can't explain why 40 was reset to 00 ... I'm not familiar enough with how that stuff works, or if there are any other interactions with, say, udev that could cause that, etc |
| 16:36.09 | brad_mssw | (no clue here) |
| 16:36.13 | brad_mssw | ...obviously |
| 16:37.32 | CosmicPenguin | It doesn't look to me like the driver is changing that bit |
| 16:38.12 | CosmicPenguin | it reads it, but thats it |
| 16:38.18 | CosmicPenguin | its possible that VSA isn't letting you write that space |
| 16:46.04 | brad_mssw | no clue, after I setpci it, I lspci it and it shows that it was set ... but after a modprobe amd74xx ... another lspci shows it is no longer set |
| 16:46.07 | brad_mssw | that's all I was going off of |
| 16:55.12 | *** join/#edev chouimat (n=dieu@kde/developer/chouinard) |
| 17:48.18 | *** join/#edev dfarnsworth (n=dfarnswo@65.200.49.156) |
| 17:57.55 | *** join/#edev ico2_ (n=ico2@modem-1838.cougar.dialup.pol.co.uk) |
| 18:26.21 | prpplague | GPSFan: ping |
| 18:28.33 | GPSFan | prpplague: pong |
| 18:29.35 | prpplague | GPSFan: question |
| 18:29.49 | GPSFan | shoot |
| 18:29.56 | prpplague | GPSFan: the enc28j60 doesn't have a mac address by default |
| 18:30.12 | prpplague | GPSFan: normally people add a serial eeprom to store the mac |
| 18:30.23 | prpplague | GPSFan: any ideas on how you'd like to see that handled? |
| 18:30.34 | prpplague | GPSFan: i.e. pass the mac as module param |
| 18:32.36 | *** join/#edev Off_Namuh (i=GPS@gateway/tor/x-5a958573ead8f5ec) |
| 18:33.08 | prpplague | holy cow |
| 18:33.16 | GPSFan | prpplague: hmm, if the hammer + enc28j60 is to be part of an end product, sold as a whole to consumers, the serial eeprom idea is probably best. passing the MAC as a parameter will certainly work for now. |
| 18:33.22 | Exiles | are you serious? |
| 18:33.31 | chouimat | prpplague: 1st version of one of the board from the nutcase |
| 18:33.33 | prpplague | chouimat: what product is that |
| 18:34.09 | chouimat | prpplague: something that will never be released ... I just cleaning the shelves and decided to play a little bit with the board ... |
| 18:34.15 | prpplague | GPSFan: we weren't planning at this stage to sell our own enc28j60 board, we were going to just recommend the olimex one |
| 18:34.41 | Exiles | yeah, the olimex one seems simpler |
| 18:34.52 | prpplague | GPSFan: what i had envisioned was having a file on the rootfs that would include the mac which would be read on loading |
| 18:35.00 | prpplague | GPSFan: i.e. similiar to the loading of firmware |
| 18:36.13 | chouimat | prpplague: and the stupid thing use a text based protocol ... /me is ashamed to have wrote this code but I didn't have anything to say about the design |
| 18:36.47 | prpplague | chouimat: hey, as long as it pays the bills |
| 18:36.51 | Exiles | I've got the ethernet chip, the ethernet port with all electronics built into it |
| 18:37.05 | GPSFan | prpplague: ok, so it will then be up to the user to obtain/steal/create a usable MAC address. Passing it as a parameter seems to the module seems to be a good solution. what happens if the module is compiled into the kernel? |
| 18:37.40 | chouimat | prpplague: not really the guy still owe me a lot of money ... which I will never see, so it's why I have all those prototype here ... |
| 18:38.09 | ds2 | prpplague: do you have a serial number readable by software on the boards? |
| 18:38.36 | chouimat | prpplague: the saga with the gp is over ... I will get a new one soon ... need to finish the paperwork for the customs :( |
| 18:38.40 | prpplague | Exiles: ?? |
| 18:39.39 | Exiles | just need some 1% resistors to make it work |
| 18:39.56 | prpplague | Exiles: what ethernet chip are you refering to? |
| 18:40.07 | Exiles | enc28j60 |
| 18:40.15 | prpplague | ds2: no, no serial number |
| 18:40.30 | prpplague | Exiles: ahh you are doing it by hand? |
| 18:40.38 | ds2 | prpplague: any plan to? you could then do the same game the gumstix folks do... has the S/N for a MAC |
| 18:40.49 | Exiles | well, I have 6 of the ethernet chips |
| 18:41.16 | prpplague | ds2: i am sorry, i am not understanding you |
| 18:41.31 | prpplague | ds2: nm, gotcha now |
| 18:41.37 | ds2 | oh okay |
| 18:41.43 | prpplague | ds2: no we don't have a serial number |
| 18:41.52 | ds2 | prpplague: just a nice easy common repository for generating unique stuff |
| 18:42.00 | prpplague | ds2: indeed |
| 18:42.33 | prpplague | ds2: we own a block Of macs , but we wouldn't be using them for someone else's product |
| 18:42.40 | ds2 | btw, after I catch up... I should have time to do projects (just got back from a trip) |
| 18:42.44 | ds2 | *nod* |
| 18:43.26 | ds2 | always the option of random 20 bits + setting the locally admin bit + 24bits of S/N for a MAC |
| 18:43.26 | prpplague | Exiles: so you got all the magnetics and everything to build a enc28j60 board? |
| 18:43.37 | ds2 | should be legit with IEEE |
| 18:43.46 | Exiles | except the few 1% resistors it needs, lol |
| 18:44.02 | Exiles | magnetics are built into the thernet jacks I have |
| 18:44.03 | GPSFan | prpplague: in fact olimex should provide tha MAC since the enc28j60 module is a NIC. |
| 18:44.16 | prpplague | GPSFan: i don't believe they do |
| 18:44.32 | prpplague | GPSFan: nope |
| 18:44.42 | GPSFan | prpplague: iwasnt' saying that they do, but they should. |
| 18:45.48 | prpplague | GPSFan: ahh, well, alot of nic vendors don't provide mac's they generally expect people to purchase their own |
| 18:46.13 | GPSFan | prpplague: maybe on the new carrier board you could have a generic serial eeprom that the user could store whatever he wanted. |
| 18:46.45 | prpplague | GPSFan: well, no reason you can't use one block of the nor flash(128k) to do store values |
| 18:46.55 | GPSFan | afterall it's a development board, intended to be a prototype for many different types of projects. |
| 18:47.02 | prpplague | GPSFan: you could actually set the mac in the bootloader and have the driver read it from there |
| 18:47.48 | prpplague | GPSFan: we do that on the M5900/M7200 for things like contrast and default security settings |
| 18:47.51 | GPSFan | prpplague: I've seen that before, apex should be able to do that. |
| 18:47.59 | prpplague | GPSFan: it already does |
| 18:48.15 | prpplague | GPSFan: i guess thats a future feature |
| 18:48.23 | prpplague | GPSFan: that i can add to the driver |
| 18:48.31 | GPSFan | my bad, there is already a generic flash storage area in along with apex. ;>( |
| 18:48.42 | prpplague | GPSFan: yep |
| 18:48.54 | prpplague | GPSFan: anyway, i've got the driver just about ready for testing |
| 18:49.06 | prpplague | GPSFan: i've got to do a few things on the board and i'll test |
| 18:49.27 | GPSFan | ok, I can test it tonight after you think it's ready. |
| 18:49.34 | prpplague | GPSFan: okie dokie |
| 18:52.48 | Exiles | nope, dosn't seem they implemented a serial # in the enc chip |
| 19:10.07 | prpplague | CosmicPenguin: ping |
| 19:26.15 | *** join/#edev sunrunner20 (n=jamesdoe@pool-71-252-234-221.dllstx.fios.verizon.net) |
| 19:35.22 | *** mode/#edev [+o CosmicPenguin] by ChanServ |
| 19:35.43 | prpplague | CosmicPenguin: you alive? |
| 19:37.43 | CosmicPenguin | hi |
| 19:38.21 | prpplague | CosmicPenguin: got a second to look at something in the 2.6.22 kernel build? |
| 19:40.53 | CosmicPenguin | sure |
| 19:41.15 | prpplague | CosmicPenguin: drivers/scsi/Kconfig |
| 19:41.31 | prpplague | CosmicPenguin: see the SCSI_WAIT_SCAN option |
| 19:41.55 | *** join/#edev koen (n=koen@dominion.kabel.utwente.nl) |
| 19:42.13 | prpplague | CosmicPenguin: its only needed if the SCSI_SCAN_ASYNC is configured as a module |
| 19:42.50 | prpplague | CosmicPenguin: but currently as the Kconfig is, it builds as a module when SCSI and MODULES are enabled |
| 19:43.17 | prpplague | CosmicPenguin: hence if you are doing so scsi emulation it builds an unnessary module, i.e. with usb thumbdrives |
| 19:44.51 | CosmicPenguin | it is tristated |
| 19:44.56 | *** join/#edev lyakh (n=lyakh@dynamic-unidsl-85-197-26-24.westend.de) |
| 19:45.18 | CosmicPenguin | it depends on SCSI and MODULES, but isn't forced on |
| 19:45.45 | prpplague | CosmicPenguin: yep, but not select option, and if you read the help on the SCSI_SCAN_ASYNC you'll see its only need when SCSI_SCA_ASYNC is set as a module |
| 19:46.37 | CosmicPenguin | How do you know that? |
| 19:47.03 | prpplague | CosmicPenguin: by looking at the code and checking all the other Kconfig options |
| 19:47.43 | CosmicPenguin | is scsi_wait_scan designed to only be used by scsi_scan_async? |
| 19:49.06 | prpplague | CosmicPenguin: it looks so |
| 19:49.49 | CosmicPenguin | thats key - if it is designed only for scsi_scan_async, then it should be a dependency of SCSI_SCAN_ASYNC |
| 19:50.08 | CosmicPenguin | But if it just happens to only be used by scsi_scan_async, then it should be enabled as its own option |
| 19:50.59 | prpplague | CosmicPenguin: well, for me, thats not really even the issue, the fact that it gets configured as module even if you aren't using anything else is what bothers me |
| 19:51.33 | prpplague | CosmicPenguin: i.e. if you compile in scsi support to do something like a thumbdrive, it automatically builds the scsi_wait_scan as a module |
| 19:52.49 | CosmicPenguin | right |
| 19:53.10 | CosmicPenguin | that should probably be fixed - but the answer might not to be to tie to to SCSI_SCAN_ASYNC |
| 19:53.23 | prpplague | CosmicPenguin: yea, my thoughts too |
| 19:53.32 | prpplague | bbiab |
| 19:58.44 | *** join/#edev adyer (n=adyer@adsl-69-223-13-78.dsl.chcgil.ameritech.net) |
| 19:59.43 | *** join/#edev redblue (i=star@ppp238.109-253-207.mtl.mt.videotron.ca) |
| 20:10.46 | *** join/#edev MothaWork (n=monmotha@host-69-95-169-16.cwon.choiceone.net) |
| 20:10.59 | *** join/#edev MothaWork (n=monmotha@149.164.193.61) |
| 20:17.45 | *** join/#edev T0mW (n=Tom@24.238.86.158.res-cmts.sth.ptd.net) |
| 20:19.59 | prpplague | T0mW: hey crack baby |
| 20:20.08 | T0mW | prpplague: hey |
| 20:20.35 | T0mW | prpplague: just planning what I need to do today. |
| 20:20.56 | prpplague | T0mW: fun fun |
| 20:21.09 | T0mW | comix read, news articles read, email answered, now to think about what needs to be worked on. |
| 20:21.10 | prpplague | T0mW: hey, questions, there a reason you only need a buzzer on your board? |
| 20:21.29 | T0mW | prpplague: yeah, it would be used to signal a communication loss etc. |
| 20:21.59 | prpplague | T0mW: what i meant was, did you want to use a pwm audio channel instead? |
| 20:22.08 | T0mW | prpplague: that is a transducer really, you bang it at exactly 2048Hz and it sounds off. |
| 20:22.16 | prpplague | T0mW: ahh |
| 20:22.45 | prpplague | T0mW: oh and you do realize that on the second usb interface, you can use it as a host OR slave, but not both? |
| 20:23.20 | *** join/#edev ico2_ (n=ico2@modem-238.chameleon.dialup.pol.co.uk) |
| 20:23.29 | T0mW | prpplague: I did put the RS232 port on the board as well. It pins out into an RJ45 connector which occupies a smaller footprint than a DB9 (EIA-232 pinout). |
| 20:24.11 | T0mW | prpplague: correct, but I put both connectors on the board so you could elect which mode to use. |
| 20:26.00 | T0mW | prpplague: I did find a touch driver for the TSC2003 written by Bill Gatliff for a 2.6.12 kernel. I don't see it in any mainstream ARM distros though. |
| 20:26.09 | prpplague | T0mW: hmm |
| 20:26.12 | prpplague | T0mW: looking |
| 20:26.34 | T0mW | prpplague: maybe it was snobbed-out? |
| 20:30.14 | prpplague | T0mW: hmm you do know you need a pullup for the usb slave to work ? |
| 20:31.12 | *** join/#edev lyakh (n=lyakh@dynamic-unidsl-85-197-26-24.westend.de) |
| 20:34.36 | prpplague | T0mW: looking |
| 20:35.03 | T0mW | prpplague: that pullup is on both DP1 and DN1? |
| 20:35.12 | *** join/#edev sunrunner20 (n=jamesdoe@pool-71-252-234-221.dllstx.fios.verizon.net) |
| 20:35.36 | prpplague | T0mW: yea i don't see the pullup on the usb slave |
| 20:35.55 | prpplague | T0mW: look at the schematic for the carrier board for the usb slave port |
| 20:36.25 | T0mW | prpplague: ok, good point then. I'm still going over the schematic as I am sure that I have missed something else as well. You never get it "right" on the first board. |
| 20:36.46 | prpplague | T0mW: yea, that pullup i missed on our first board too |
| 20:37.23 | prpplague | T0mW: you might want to put in two 3-pin jumper headers so you can configure it for either host or slave |
| 20:37.49 | T0mW | prpplague: if I had GPIO pins instead of AINx pins, I could use two FETs to switch a pullup on/off there. |
| 20:38.19 | T0mW | prpplague: then, it could be done 'on-demand' instead of hard-wired. |
| 20:38.47 | prpplague | T0mW: doesn't work that way, the controller has to be configured |
| 20:38.56 | prpplague | T0mW: its either/or not both |
| 20:39.15 | prpplague | T0mW: i.e. it has be set when the kernel driver starts |
| 20:39.57 | prpplague | T0mW: most people who need more than one host port add a usb hub chip |
| 20:39.58 | T0mW | prpplague: well, it could be that two drivers are built. One does a dual host, the other does host + slave. Unload the dual host driver and load the split driver. done. |
| 20:40.52 | T0mW | prpplague: ok, good point, only need to find room to put more USB circuitry. |
| 20:40.53 | T0mW | heh |
| 20:41.06 | T0mW | prpplague: did you get that file? |
| 20:41.15 | prpplague | T0mW: yea looking it over |
| 20:42.23 | prpplague | T0mW: yea, the only thing that is jumping out for me is the usb host/slave stuff |
| 20:42.40 | T0mW | prpplague: ok. I used dual 1.3amp switchers fed from 12 volts. the backlight HV supply needs the +12. Input to the board is diode protected against reverse polarity (diode + PTC fuse). |
| 20:42.41 | prpplague | T0mW: you using the rs-232 port strictly as a console? |
| 20:43.27 | T0mW | prpplague: no. I would use that as a PPP link in one scenario, in another the ethernet would be the data link to the "backend" unit. |
| 20:44.29 | T0mW | prpplague: still not sure exactly how the design would play-out, but I felt that I would need the option not to use the ethernet. |
| 20:45.55 | T0mW | prpplague: I'll put the shunt jumpers on the board for the Slave pullup for now. I'm trying to keep this design filled out as much as possible. |
| 20:47.06 | prpplague | okie dokie |
| 20:49.53 | T0mW | prpplague: the arrangement that you have there with the 74HC14's with: nCABLE and nUSB_EN, how necessary is it? Would a simple pullup on DP1 suffice? or, does the cable detect and dynamic enable all that important? |
| 20:50.24 | prpplague | T0mW: neither are nessary |
| 20:50.28 | T0mW | good |
| 20:50.38 | prpplague | T0mW: a simple pullup will work for the slave |
| 20:51.02 | prpplague | T0mW: the cable detect and enable are there to make it more robust |
| 20:51.49 | prpplague | T0mW: there are alot of applications where the cable detect is really needed as well as the ability to force a disconnect to the host |
| 20:52.05 | T0mW | so, I just need to add a jumper selectable 1.5K pullup. The 15k pulldowns should be just to avoid floating pins and should not interfere with the USB operations. |
| 20:53.22 | prpplague | T0mW: correct, they help with the disconnection |
| 20:53.41 | prpplague | T0mW: if you don't have them, when you disconnect the USB device, it will still think there is a device attached |
| 20:53.54 | T0mW | prpplague: well, the design could morph later if a force-down is desired. e.g. remove CARD_DETECT from the miniSD drive. The SD card is not intended to be removed in my normal application as the root filesystem would be on it. In someone else's application, they may have a romFS and be swapping SD cards. |
| 20:54.33 | T0mW | prpplague: right now, it is generalized, I would fork a new design as conditions demand it. |
| 20:54.58 | T0mW | heh, aka "Development Kit". |
| 20:55.02 | prpplague | hehe |
| 20:55.04 | prpplague | yea |
| 20:55.08 | T0mW | :P |
| 20:55.18 | T0mW | aka "Tom is having fun again" |
| 20:55.41 | T0mW | aka "forking off" |
| 20:55.48 | T0mW | heh |
| 20:56.15 | T0mW | prpplague: ok, back to work |
| 20:57.40 | prpplague | T0mW: one sec |
| 20:57.56 | prpplague | T0mW: what;s your overall feeling/impression about the Hammer so far? |
| 21:12.35 | *** join/#edev ico2 (n=ico2@modem-238.chameleon.dialup.pol.co.uk) |
| 21:13.44 | *** mode/#edev [+o prpplague] by ChanServ |
| 21:43.47 | *** join/#edev Off_Namuh (i=GPS@gateway/tor/x-ee81e539a9b57960) |
| 22:01.25 | ds2 | Hmmm |
| 22:05.48 | *** join/#edev ico2__ (n=ico2@modem-190.chameleon.dialup.pol.co.uk) |
| 22:21.14 | *** join/#edev ico2__ (n=ico2@modem-190.chameleon.dialup.pol.co.uk) |
| 22:56.37 | *** join/#edev joe_bleau (n=joe_blea@adsl-68-90-142-36.dsl.fyvlar.swbell.net) |
| 22:57.16 | *** join/#edev dasf (n=jamesdoe@pool-71-252-234-221.dllstx.fios.verizon.net) |
| 23:16.14 | *** join/#edev sunrunner20 (n=jamesdoe@pool-71-252-234-221.dllstx.fios.verizon.net) |
| 23:17.28 | *** join/#edev joe_bleau (n=joe_blea@ppp-69-154-118-57.dsl.fyvlar.swbell.net) |
| 23:29.34 | *** join/#edev linac (n=lin@167.86.76.222.broad.fz.fj.dynamic.163data.com.cn) |