IRC log for #openjtag on 20090303

00:28.49*** join/#openjtag brolin (n=brolin@190.157.13.75)
00:32.51*** join/#openjtag brolin (n=brolin@190.157.13.75)
02:57.26*** join/#openjtag rje`mac (n=rje`mac@75.150.1.254)
03:05.41*** join/#openjtag sn9 (n=danielg4@gimpelevich.san-francisco.ca.us)
03:07.10sn9is there any particular reason not to use an ft232 directly on a jtag header without buffers?
03:07.52sn9parallel i can understand, but ft232?
04:17.15*** join/#openjtag rje`mac (n=rje`mac@75.150.1.254)
04:29.09*** join/#openjtag sesters (n=sesters@76-191-131-184.dsl.static.sonic.net)
04:38.12*** join/#openjtag brolin (n=brolin@190.157.13.75)
06:15.58*** join/#openjtag rje`mac (n=rje`mac@c-67-185-128-239.hsd1.wa.comcast.net)
06:21.01*** join/#openjtag pleemans (n=toi@116.54-246-81.adsl-static.isp.belgacom.be)
07:41.07sn9surely, someone here can answer that...
09:55.13*** join/#openjtag inertial (n=xyz@114.78.168.130)
11:49.03*** join/#openjtag pirho (i=pirho@gateway/gpg-tor/key-0x2CEEC9CB)
13:07.06*** join/#openjtag L_Deluxe (n=lou@c-68-53-134-58.hsd1.tn.comcast.net) [NETSPLIT VICTIM]
14:56.47*** join/#openjtag pirho (i=pirho@gateway/gpg-tor/key-0x2CEEC9CB)
15:09.09*** join/#openjtag L_Deluxe (n=lou@c-68-53-134-58.hsd1.tn.comcast.net) [NETSPLIT VICTIM]
15:39.36*** join/#openjtag L_Deluxe (n=lou@c-68-53-134-58.hsd1.tn.comcast.net) [NETSPLIT VICTIM]
15:43.36*** join/#openjtag L_Deluxe (n=lou@c-68-53-134-58.hsd1.tn.comcast.net) [NETSPLIT VICTIM]
15:47.14*** join/#openjtag L_Deluxe (n=lou@c-68-53-134-58.hsd1.tn.comcast.net) [NETSPLIT VICTIM]
15:52.40*** join/#openjtag L_Deluxe (n=lou@c-68-53-134-58.hsd1.tn.comcast.net) [NETSPLIT VICTIM]
18:08.42*** join/#openjtag L_Deluxe (n=lou@c-68-53-134-58.hsd1.tn.comcast.net)
18:30.51sn9anyone: ping
18:33.35L_DeluxeAnyone?
18:33.39L_DeluxeIf so, pong.
18:34.31L_DeluxeApparently not just anyone, then.
18:38.50sn9L_Deluxe: know anything about jtag adapter design?
18:40.38L_DeluxeSort of.
18:41.23sn9i'm thinking of adding support to openocd for ftdi bitbang mode
18:42.05sn9the idea of a usb jtag adapter cheaper than a parallel one is intriguing
18:42.29L_DeluxeMSEE isn't a winner?
18:42.43L_Deluxe(or whatever they call the SPI/JTAG serial engine in the FT2232)
18:42.58sn9mpsse is only in the dual-channel chips
18:43.09sn9the single-channel ones don't have it
18:43.18L_DeluxeBit bang is going to be _really_ slow.
18:43.34sn9even async bitbang?
18:43.34L_DeluxeLike 500Hz.
18:43.56L_DeluxeIt's still a USB packet per clock transition, isn't it?
18:44.21sn9hmm -- you think that would be slower than parallel?
18:45.27L_DeluxeHow would you do it with parallel?
18:45.35L_DeluxeAnd how would you do it with bit banging?
18:45.45sn9parport.c
18:46.01L_DeluxeOh, a real parallel port?  Yeah.  Slower than that.
18:46.26sn9keep in mind parport.c does not use epp or ecp
18:47.18L_DeluxeThe biggest bottleneck is going to be the USB.   Refresh me on how commands are sent to the FTDI chip when you want to bit bang.
18:47.41L_DeluxeEmphasis on how much stuff can fit into one packet.
18:47.45sn9similar to how they are sent to a parport
18:48.02L_DeluxeParport just writes values to a hardware register.
18:48.06sn9yep
18:48.27sn9here, you'd basically write the same to the chip
18:48.40L_DeluxeWith USB, you have to assemble a command packet and send it to the device.  And you can only send one packet per millisecond.
18:50.11sn9so, basically, every bit turns into a packet, which in turn turns into many bits
18:50.51L_DeluxeDepending on the command structure, yes.  Likely.  Even if each command is (make the following byte appear on some GPIO lines).
18:51.35L_DeluxeAnd if it is possible to queue several commands to be executed (by the FTDI chip) in sequence, such that they fit into one packet, that is a huge win.
18:51.48sn9and usb maxes out at 12Mb, even in theory
18:52.15L_DeluxeFor Full Speed, yes.  But there is still the 1ms framing.
18:52.59sn9the prospect is that the chip will be able to bang faster than it can receive cmds
18:53.13L_DeluxeIf your endpoint size is, say, 64 bytes, that's how many you can send in your 1ms window.  And if you've got other stuff going on on the USB bus, that will slow things down further.
18:53.26L_DeluxeOh yes.  Hence the bottleneck being the USB.
18:53.45sn9not sure which pdf will state the endpoint size
18:54.02L_DeluxeDo you have the device now?  Plugged in?  On a Linux box?
18:54.30sn9only a ft2232 -- but ft232r/ft245r are in question
18:55.04L_DeluxeAnd the reason not to use a 2232 is unit cost, I assume.
18:55.38sn9can't beat this: http://alldav.com/index.php?main_page=product_info&products_id=10
18:55.46sn9even parallel costs more
18:57.06L_DeluxeLooking for datasheet...
18:57.08sn9my original question, though, was whether buffers between the chip and the jtag connector really mean much when the ftdi chip is already speaking cmos levels
18:58.07L_DeluxeWow, that is entirely different.
18:58.22L_DeluxeBuffers would help you drive a longer cable.
18:58.36L_DeluxeAnd protect your FTDI chip.
18:58.49sn9protect it from the target?
18:59.02sn9even at cmos-to-cmos?
18:59.11L_DeluxeFrom any misc voltages that might appear on the pins.  ESD, etc.
18:59.49L_DeluxeAccidentally plugging it into a target with the wrong voltage.  Plugging the cable in backward, etc.
19:00.18sn9ftdi chips have no esd protection a la max323 chips?
19:00.47L_DeluxeMaybe they do.  I don't know.  I'd hope they do.  But it is silly to assume such things without knowing.
19:02.38L_DeluxeYou could always risk it.
19:03.52L_DeluxeJust searched the datasheet for "ESD" and came up empty.
19:07.12sn9what about endpoint size?
19:07.51L_DeluxeHaven't found mention of it yet.  If you had one hooked up, you could just look at the descriptors as reported by your operating system and it would tell you.
19:08.37L_DeluxeFTDI's DLL/so probably abstracts that away, anyway.
19:08.49sn9obviously
19:09.11L_DeluxeBut it's going to be a power of two between 8 and 64.
19:09.37sn9assuming 64, would it still be slower than parallel?
19:10.11L_DeluxeParallel is good for hundreds of thousands of transitions per second, isn't it?  In which case, yeah.
19:11.27sn9i don't think it is hundreds of thousands without epp
19:13.38L_DeluxeReally?  What do you think it is, then?  EPP is what lets the port run bidirectionally byte wide, isn't it?  You don't need that for JTAG.
19:15.11L_DeluxeOld school LPT ports were nothing more than plain old data registers.  Those shouldn't have much trouble with 1 MHz assuming the ISA bus could feed them that fast.
19:15.27sn9no, there are five parport modes:
19:15.57L_DeluxeYes.  And the new ones are various improvements upon the original.  I don't know what all they are, and it appears you don't either.
19:16.10sn91) output only 2) nybble mode 3) SPP bi-di 4) epp 5) ecp
19:16.34L_DeluxeYou should be able to do JTAG with #1.
19:16.45sn9what about TDI?
19:16.54L_DeluxeAssuming #1 gives you the 5 or so input lines.
19:17.09sn9#1 is 8 output lines, iirc
19:17.19sn9no input
19:17.28L_DeluxeSo what about BUSY, ACK, etc?
19:17.44sn9oh, yeah, one can use those
19:17.51L_DeluxeYes.
19:18.14L_DeluxeBe aware that some of them are inverted, though.  That could get confusing should one forget.
19:18.30sn9inversion can be done in software
19:18.48L_DeluxeCertainly.  Or the logic can just expect the inverted values.  
19:19.15L_DeluxeYou'll have to map bits around anyway.  Inversion is just an XOR with a mask.
19:19.54sn9from the openwrt wiki: With a parallel port cable, however, you will be lucky to achieve more than about 400,000 bits-per-second.
19:20.30L_DeluxeOk.  That is still hundreds of thousands of transitions.
19:20.37sn9from an ftdi pdf: The clock for the Asynchronous Bit Bang mode is actually 16 times the Baud rate. A value of 9600 Baud would transfer the data at (9600x16) = 153600 bytes per second, or 1 every 6.5 mS.
19:22.06L_DeluxeSo with those numbers, you could shift out 1 JTAG bit every 26ms.
19:22.07sn9the wiggler design uses a data bit for TDI, fwiw
19:22.43sn9the ftdi chips can do up to 921kbps, and those numbers are for 9.6
19:22.53L_DeluxeThen scale appropriately.
19:23.41sn9rough guesstimate: 50 uS
19:25.20sn9hmm, that exceeds the jtag spec
19:25.39L_DeluxeReally?
19:26.03L_DeluxeThe FTDI driver can allegedly go up to 6MHz.
19:26.12sn912MHz
19:26.28L_DeluxeOk.  50us is less than 1MHz.
19:26.58sn9ok, i miscounted
19:27.20sn9the previous sentence on the wiki, btw: In fact, the JTAG spec allows for up to 25 million bits-per-second transfers.
19:28.28L_DeluxeDependent on target, of course.
19:28.54sn9yes, most targets would be slower
19:29.26sn9presumably, mpsse always maxes out the target
19:30.21L_DeluxeYou give it a signaling rate and it spits out whatever data you tell it to at that rate, yes.  Then it waits until you send it more.
19:31.01L_DeluxeAnd, that might be awhile, depending on how fast you're running the JTAG and how much USB traffic there is and any other demands on your system.
19:31.16L_DeluxeAwhile being on the scale of microseconds or milliseconds.
19:33.55L_DeluxeGoing on that bitbang stuff you mentioned above, the BRG for 921k seems to get you a bit per 271ns.  Which would be 3-4MHz.
19:34.19L_DeluxeReading TDO will probably slow things down.
19:34.32L_Deluxe1000000000 * 4 / (921000 * 16)
19:35.06sn9921600bps is 92160Bps when taking start and stop bits into account
19:35.23L_DeluxeIn bitbang mode?
19:36.24sn9that translates into 92160 jtag bps
19:36.45L_DeluxeReally?  How?
19:37.22sn9every byte over the cmos has a single jtag bit
19:37.52L_DeluxeActually, no.  At best, every 4 bytes over the cmos has a single jtag bit.
19:38.12L_DeluxeSetup data, toggle clk, delay, toggle clk.
19:38.46sn9those don't all count as jtag bits when figuring the 400kbps max speed of parallel?
19:38.46L_DeluxeAnd you've got to read TDO in there somewhere before the second toggle.
19:39.10L_DeluxeYou are bit banging JTAG.  
19:39.33sn9read TDO? you mean TDI, right?
19:39.34L_DeluxeYou have to make 4 writes per JTAG bit when doing parallel as well for the same reason.
19:39.46L_DeluxeYou read TDO from the target.  You write TDI to the target.
19:40.27L_DeluxeIt's confusing.  It's from the POV of the target, not the host.
19:40.35sn9facepalms
19:41.27sn9still, in async bitbang, tdo reading need not be dependent on writes, right?
19:42.12L_DeluxeTDO becomes valid after the falling (I think) edge of TCK.  You have to read it before TCK transitions the other way again.
19:42.32sn9so async is out altogether?
19:42.40L_DeluxeMost likely.
19:42.44sn9eww
19:43.12L_DeluxeAs I cursorily read, sync just means you have to initiate a read by doing a write.
19:43.22L_DeluxeBut that's just what I got from reading quickly.
19:44.42L_DeluxeIt might not be that bad.  You might be able to combine reading TDO with a TCK transition.
19:45.03sn9in syync mode?
19:45.07sn9*sync
19:45.14L_Deluxe1.3 Synchronous Bit Bang Mode
19:45.14L_Deluxe<PROTECTED>
19:45.14L_Deluxe<PROTECTED>
19:45.14L_Deluxe<PROTECTED>
19:45.15L_Deluxe<PROTECTED>
19:45.15L_Deluxe<PROTECTED>
19:45.43L_DeluxeThe datasheets always seem to say just a little bit less than is needed.
19:46.37L_DeluxeHey, what's happening with RD# and WR#?  Anything you can use for TCK?
19:47.49L_DeluxeFrankly, if this were easy to do, you'd think people would be doing it instead of using the FT2232 so heavily.
19:48.26sn9mpsse would still be faster, which i think is the primary impetus for the ft2232
19:48.32L_DeluxeYes.
19:49.02L_DeluxeBut it didn't always exist.  Chips with this sort of bitbang mode existed first.  Yet I've never heard of a JTAG programmer using it.
19:49.13*** join/#openjtag roxfan (n=dunno@152.161-244-81.adsl-dyn.isp.belgacom.be)
19:49.13L_DeluxeEven though it is certainly possible.
19:50.26sn9look at the diagram on page 5
19:51.23L_DeluxeI'm lookin' at it.
19:51.54sn9you were asking about tck
19:52.25L_DeluxeYeah.  That's where I saw something was happening with RD# and WR#.
19:52.38L_DeluxeHave you coded against these chips in bitbang mode before?
19:53.02L_DeluxeUsing FTDI's API or native USB.
19:53.25sn9shouldn't be too hard, with the existing bitbang.c and ft2232.c as a base
19:55.53*** join/#openjtag noz (n=peterd@cpc2-oxfd5-0-0-cust122.oxfd.cable.ntl.com)
20:00.02L_DeluxeThe API may dictate how you can do things.   Specifically, you may have to issue separate FT_Write and FT_Read commands.
20:00.27sn9yes, but the API can abstract that away
20:00.53L_DeluxeThose commands aren't in the API itself?
20:01.34sn9they are; i mean those commands abstract away relationships between reads and writes at the usb level
20:01.52L_DeluxeYes.  You apparently don't have access to the USB level.
20:03.05sn9having access to the usb level would slow things down, no?
20:03.51L_DeluxeThat depends on many things.  There are circumstances under which it could speed things up.  I do not know whether those circumstances are present here.
20:04.27sn9libftdi is generally considered to be slower than libftd2xx
20:04.30L_DeluxeThe API may or may not efficiently handle grouping commands together.
20:05.53L_DeluxeThe FTDI datasheets seem to assume that the API abstracts to the FIFO level.  As such, there would be little or no control over things like USB buffer filling.  Any consolidation would be done or not done at the library's discretion.
20:06.06L_DeluxeAssuming consolidation is even possible.
20:06.06sn9right
20:06.21sn9presumably, it does those things
20:06.43sn9at least in the case of libftdi, one can look and see
20:06.49L_DeluxeYes.
20:08.21sn9the primary question at this point then is whether tck would need more flexibility than the strobes would provide
20:09.41sn9if not, that's a speed boost, but if so, ft245r support becomes possible, since that chip is missing the strobes
20:12.36L_DeluxeIt's looking like WR# won't be usable directly as TCK.  You'll have to bit bang it.
20:13.07L_DeluxeIf you were interested in speed, you'd be using a 2232.
20:13.34L_DeluxeSpeed over things like cost.
20:13.35sn9i'm assuming RD# is out, too
20:13.49L_DeluxeRD# doesn't seem to do anything that would be useful at all.
20:14.29sn9WR# can be hardware-inverted, not that it makes a difference
20:14.35L_DeluxeAnd it is unclear whether those lines do that all the time, or whether WR# strobes only when doing a write via the API and RD# strobes only when doing a read via the API.
20:15.23L_DeluxeAnd you might have to do something with a configuration EEPROM to even make those strobes come out the CBUS lines.
20:15.51sn9"For the data to change there has to be new data written and the Baud rate clock has to tick. If no new data is written to the device, the pins will hold the last value written."
20:16.11L_DeluxeAnd?
20:16.15sn9referring to cbus
20:16.44sn9you said that was unclear
20:17.20L_DeluxeDifferent subject.  And I don't think that's referring to cbus.
20:17.34L_DeluxeI think it's referring to the 8 bit bang pins.
20:17.54sn9i read it as unambiguously referring to cbus
20:18.00L_DeluxePage#?
20:18.07L_Deluxe(it occurs at least twice)
20:18.25sn95
20:18.54L_DeluxeOk.  I see it.  Why do you think it applies unambiguously to cbus?
20:19.25sn9because it's talking specifically about the strobes, which are only on cbus
20:19.25L_DeluxeIn the case of the FT232R, any of CBUS0, CBUS1, CBUS2 or CBUS3 can be configured to bring
20:19.25L_Deluxeout the internal RD# or WR# strobes when the device is in Synchronous Bit Bang mode.
20:19.25L_DeluxeAlternatively, the CBUS pins can be used to provide clock signals by setting the appropriate values
20:19.25L_Deluxein the EEPROM. The CBUS must be configured in the FT232R EEPROM. This option is not
20:19.25L_Deluxeavailable for the FT245R.
20:19.47L_DeluxeNo, it's not.  It's talking about "the data".
20:21.15sn9ok, i misread, then
20:22.57sn9seems to me RD# is more like tck, then
20:23.10sn9after inversion, that is
20:23.29L_DeluxeBoth of its transitions occur at a time when the data lines are not necessarily determinate.
20:24.05L_DeluxeAnd it might not even occur when doing a write.
20:24.56sn9it's synchronous, remember?
20:25.31L_DeluxeOk, what exactly does that mean to you?
20:27.22L_DeluxeIt seems to me like you have to write a value in order to read one.  
20:27.47sn9yes, so the writes are locked to the read clock, too
20:27.59L_DeluxeBut you can write without reading, can't you?
20:28.19L_DeluxeSo no RD#
20:28.25L_DeluxeMaybe.
20:28.59sn9one can force dummy reads, i guess, but that would likely increase the bottleneck
20:29.25L_DeluxeIt would.  But that seems to be exactly what Synchronous Bit Bang Mode is about.
20:30.08L_DeluxeIt's hard to read.
20:30.48L_DeluxeNo matter how I read it, it looks like there's at least one dummy read, just because the value read is one behind.
20:32.49sn9the strobes are also available in async: "The maximum Baud rate is 3MBaud, but to allow time for the data to be setup and held around the WR# strobe the Baud rate should be less than 1MBaud."
20:38.39*** join/#openjtag brolin (n=brolin@200.24.16.55)
20:41.02L_Deluxehttp://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=399199
20:46.06L_Deluxesn9: There was this, but it appears to be obsoleted by a 2232 version.  http://www.lura.sk/?&LP=114EN&MP=3&ML=3&PO=''
20:54.03sn9L_Deluxe: looks like that person did not use the strobes
20:54.10L_DeluxeLooks like it.
20:54.39sn9i'm still wondering whether the strobe(s) could do tck in async
20:55.00sn9also, i think that person used sync
20:57.34L_DeluxeI don't know whether it can or not.  I banged my head against a dongle that was not at all based on an FTDI chip.    I _had_ to bit bang my own clock.
20:59.42L_DeluxeSo automatic strobes didn't enter into it.  They were simply not available.
21:39.33*** join/#openjtag pleemans (n=toi@d54C2AAB7.access.telenet.be)
23:30.53*** join/#openjtag govert (n=chatzill@c-68-39-252-155.hsd1.nj.comcast.net)
23:33.54*** part/#openjtag govert (n=chatzill@c-68-39-252-155.hsd1.nj.comcast.net)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.