| *** tpb has joined #timvideos | 00:00 | |
| *** sb0 has quit IRC | 00:05 | |
| cr1901_modern | John_K: Also mention that you'll lose the UART if you associate w/ libusb | 00:47 |
|---|---|---|
| cr1901_modern | mithro: Not that it's going to matter in a few days :P, but there seems to be a few versions of fxload. Which version are you currently using for mode-switch? | 01:00 |
| *** nikivi has left #timvideos | 02:19 | |
| mithro | cr1901_modern: the one that gets installed with "apt-get install fxload" | 03:24 |
| John_K | Mithro: any luck? | 03:54 |
| mithro | John_K: sorry, only just starting to take a look now | 04:24 |
| *** rohitksingh has joined #timvideos | 04:44 | |
| *** twoolie has joined #timvideos | 04:48 | |
| mithro | John_K: Afraid it doesn't quite work... | 04:49 |
| mithro | John_K: investigating now... | 04:49 |
| mithro | http://pastebin.ubuntu.com/25405371/ | 04:49 |
| tpb | Title: Ubuntu Pastebin (at pastebin.ubuntu.com) | 04:49 |
| mithro | https://www.irccloud.com/pastebin/jQO8q0b2/ | 04:53 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 04:53 |
| mithro | John_K: It also looks like you only support intelhex file format? | 04:55 |
| paddatrapper | mithro: heading back to Cape Town now. Should be available in 1.5-2 hours | 05:09 |
| mithro | paddatrapper: okay cool | 05:09 |
| *** rohitksingh1 has joined #timvideos | 05:26 | |
| *** rohitksingh has quit IRC | 05:27 | |
| mithro | John_K: http://pastebin.ubuntu.com/25405796/ | 06:06 |
| tpb | Title: Ubuntu Pastebin (at pastebin.ubuntu.com) | 06:06 |
| *** paradisaeidae has joined #timvideos | 06:07 | |
| mithro | John_K: It looks like there is an issue with parsing the segments? | 06:17 |
| mithro | John_K: I pushed some small fixes into your branch | 06:18 |
| mithro | write on-chip, addr 0x0100 len 128 (0x0080) | 06:20 |
| mithro | rohitksingh1: ping? | 06:20 |
| mithro | John_K: I would also like to move the changes into the hdmi2usb/modeswitch/libusb.py file | 06:24 |
| mithro | rohitksingh1: Do you know anything about https://numato.com/lm4550-ac97-stereo-audio-codec-expansion-module/ ? | 06:28 |
| tpb | Title: LM4550 AC'97 Stereo Audio Codec Expansion Module (at numato.com) | 06:28 |
| *** twoolie has quit IRC | 06:33 | |
| *** twoolie has joined #timvideos | 06:35 | |
| mithro | Ishan_Bansal: ping? | 06:50 |
| Ishan_Bansal | mithro : pong | 06:51 |
| mithro | Ishan_Bansal: I'm just reviewing paddatrapper's stuff now - I plan to look at your stuff after | 06:52 |
| mithro | Ishan_Bansal: Where are we at with things? | 06:52 |
| paddatrapper | mithro: been a massive accident and traffic is horrendous, so going to be probably another hour | 06:53 |
| mithro | paddatrapper: No worries | 06:53 |
| Ishan_Bansal | mithro : among the pull request we are on RLE-core, you made the comments twice and I have changed the RLE accordingly. | 06:53 |
| mithro | Ishan_Bansal: Okay, I'll take another look at hopefully merge it | 06:53 |
| Ishan_Bansal | Also regarding the final report I also made the changes as per your comments on Google docs. | 06:54 |
| mithro | Ishan_Bansal: Then you have more pull requests to send, right? | 06:54 |
| Ishan_Bansal | mithro : yup. | 06:54 |
| mithro | Ishan_Bansal: Okay cool | 06:54 |
| *** paradisaeidae has quit IRC | 07:00 | |
| *** rohitksingh1 has quit IRC | 07:10 | |
| mithro | Ishan_Bansal: ping? | 07:17 |
| Ishan_Bansal | mithro : pong | 07:17 |
| mithro | Ishan_Bansal: Couple more tips when writing comments | 07:17 |
| *** rohitksingh has joined #timvideos | 07:18 | |
| mithro | Ishan_Bansal: You should never write something like "Under this module a matrix containing" or "Since the data we get" -- instead say "This module takes a matrix containing 64 blocks of XXXX and verifies the RLECore produces the same output as the reference data" | 07:20 |
| mithro | Ishan_Bansal: If you find yourself writing words like "Under", "Since" and "Get" you are probably going down the right path | 07:22 |
| mithro | s/right/wrong/ | 07:22 |
| mithro | Ishan_Bansal: If you find yourself writing words like "Under", "Since" and "Get" you are probably going down the *wrong* path | 07:22 |
| mithro | Ishan_Bansal: As well, you should reply to each of my comments on your code saying if you have fixed the issue | 07:23 |
| mithro | Ishan_Bansal: You have comments on your pull request now too - it's pretty close, mainly just some comment clean up | 07:25 |
| Ishan_Bansal | mithro : Ok, I will fix them. | 07:27 |
| mithro | Ishan_Bansal: Oh, as well - generally I think you'll probably want "then" (--> I went to the shops then went home.) not "than"(--> I'd rather walk than drive there.) | 07:29 |
| mithro | English is kind of stupid though | 07:29 |
| John_K | Mithro: thanks for the fixes, I wasn't quite sure what was being done there | 07:30 |
| John_K | And yes, only intelhex support at the moment - I believe that is what was described in the issue | 07:30 |
| mithro | John_K: libusb.py and lsusb.py are suppose to provide the same API to the rest of the code | 07:30 |
| John_K | Ah | 07:31 |
| John_K | Also my bad, the issue doesn't mention intelhex | 07:31 |
| John_K | As for the Invalid parameter, it seems the request may be too large | 07:31 |
| mithro | John_K: Yeah - it doesn't seem to be parsing the input file correctly | 07:32 |
| John_K | Oh? I'm using the python intelhex module - it seems to do the right thing | 07:32 |
| mithro | fxload reads that segment as only 128 bytes long, but your code thinks its much larger | 07:33 |
| John_K | Hrm, re-reading the pastebibs | 07:33 |
| John_K | Pastebins | 07:33 |
| mithro | John_K -> http://pastebin.ubuntu.com/25405796/ | 07:33 |
| tpb | Title: Ubuntu Pastebin (at pastebin.ubuntu.com) | 07:33 |
| mithro | I think that is probably the most informative one | 07:34 |
| John_K | It seems they both do 128 byte transfer just fine | 07:34 |
| John_K | But the fxload code breaks the next fragment up into multiple USB transfers | 07:35 |
| John_K | I hadn't encountered a test file like this so far | 07:36 |
| John_K | Can you pastebin this hex file? | 07:36 |
| John_K | Yeah from inspecting pyusb it looks like the control transfer is failing, strongly suspect due to transfer size | 07:38 |
| mithro | I'm pretty sure it's not the ezusb_write code? | 07:38 |
| mithro | https://github.com/wkoszek/fxload/blob/master/ezusb.c#L213-L236 | 07:38 |
| tpb | Title: fxload/ezusb.c at master · wkoszek/fxload · GitHub (at github.com) | 07:38 |
| mithro | John_K: I wonder if there is just a bug in the intel hex loading? | 07:41 |
| mithro | John_K: file I'm loading is here -> https://github.com/timvideos/HDMI2USB-mode-switch/blob/master/hdmi2usb/firmware/fx2/opsis/ixo-usb-jtag.hex | 07:41 |
| tpb | Title: HDMI2USB-mode-switch/ixo-usb-jtag.hex at master · timvideos/HDMI2USB-mode-switch · GitHub (at github.com) | 07:41 |
| John_K | It's entirely possible, checking ezusb.c to see how they handle fragmentation | 07:42 |
| John_K | Thanks for linking that file | 07:42 |
| mithro | John_K: Does look like the error is occuring on the first multi-line segment | 07:43 |
| mithro | John_K: https://github.com/timvideos/HDMI2USB-mode-switch/blob/master/hdmi2usb/firmware/fx2/opsis/ixo-usb-jtag.hex#L17-L18 | 07:44 |
| tpb | Title: HDMI2USB-mode-switch/ixo-usb-jtag.hex at master · timvideos/HDMI2USB-mode-switch · GitHub (at github.com) | 07:44 |
| John_K | Ah I think I see what's happening, the python intelhex module is reconstructing things in memory instead of processing the file line-by-line | 07:48 |
| mithro | Actually | 07:48 |
| John_K | And there happens to be a large contiguous segment once it reconstructs things | 07:48 |
| mithro | I think I ran across this before... | 07:48 |
| mithro | John_K: Take a look at https://github.com/mithro/hexfile ? | 07:49 |
| tpb | Title: GitHub - mithro/hexfile: Python library for parsing Intel Hex files. (at github.com) | 07:49 |
| John_K | I think I just need to break up the segments I get back from the intelhex module if they're too large for a single ctlrl transfer | 07:49 |
| John_K | Sure | 07:49 |
| John_K | This seems like it would have the same issue | 07:51 |
| mithro | John_K: Looks like you might be right -> https://github.com/timvideos/HDMI2USB-litex-firmware/blob/v0.0.2/firmware/fx2/generate_fx2_microboot.py#L204-L215 | 07:53 |
| tpb | Title: HDMI2USB-litex-firmware/generate_fx2_microboot.py at v0.0.2 · timvideos/HDMI2USB-litex-firmware · GitHub (at github.com) | 07:53 |
| John_K | https://GitHub.com/libusb/libusb/issues/110 | 07:54 |
| tpb | Title: Document upper limits on control transfers (INVALID_PARAMETER) (re: MAX_CTRL_BUFFER_LENGTH) · Issue #110 · libusb/libusb · GitHub (at GitHub.com) | 07:54 |
| John_K | tl;dr: libusb internals support 4K max control transfer buffer | 07:55 |
| John_K | Patch should be easy | 07:55 |
| mithro | Ishan_Bansal: you seem to have removed my access to put comments on your gsoc file report... | 08:12 |
| mithro | s/file/final/ | 08:12 |
| John_K | Mithro: try re-pulling CypressFX | 08:13 |
| mithro | https://www.irccloud.com/pastebin/mUEL3Rgz/ | 08:15 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 08:15 |
| John_K | Well that's embarrassing, flubbed the commit | 08:17 |
| John_K | Fixed, retry please | 08:19 |
| *** twoolie has quit IRC | 08:21 | |
| John_K | It appears to succeed in uploading ixo-USB-JTAG.hex to my test FX2 device | 08:22 |
| mithro | John_K: the device re enumerates as the ixo-usb-jtag device? | 08:22 |
| John_K | It does not appear to, no | 08:23 |
| Ishan_Bansal | mithro : https://docs.google.com/document/d/1hXhApH3lDt4gT7ULloFavc0kUgBTPp0yphXEUjW9RKo/edit?usp=sharing | 08:24 |
| tpb | Title: GSOC Final Project Report - Google Docs (at docs.google.com) | 08:24 |
| mithro | John_K: It should? | 08:26 |
| Ishan_Bansal | mithro : going to lunch, come within half an hour. | 08:27 |
| mithro | John_K: Doesn't seem to work here either... | 08:27 |
| John_K | Just verifying functionality on windows with fxload.exe now | 08:28 |
| John_K | Ok that works as you described, I'll Debug here and ping you once I have the device reenumerating properly | 08:29 |
| John_K | Likely will happen in about 16 hours, its late here | 08:30 |
| mithro | John_K: No worries | 08:31 |
| mithro | John_K: fxload.exe with --verbose might be useful to figure out what is going on.... | 08:31 |
| John_K | So now it seems to work | 08:34 |
| John_K | Oh hah | 08:34 |
| John_K | Fxload.py will work because it reboots the device for you but the API doesn't | 08:35 |
| paddatrapper | mithro: just waiting for travis to build the fixes on that PR | 08:36 |
| John_K | Actually that's a lie, it IS in the API | 08:36 |
| mithro | paddatrapper: You coding in a car, or made it home? | 08:36 |
| paddatrapper | mithro: just got home. I did some work in the car, then my battery died | 08:36 |
| mithro | paddatrapper: Okay cool | 08:42 |
| mithro | paddatrapper: I haven't made much progress on the audio side of things been reviewing code and John_K has been distracting me :-P | 08:43 |
| *** twoolie has joined #timvideos | 08:43 | |
| *** twoolie has quit IRC | 08:48 | |
| paddatrapper | mithro: no worries. I see version_data is causing issues with my PR and travis... | 08:55 |
| paddatrapper | mithro: I doubt I'll be able to get the loopback working in time for Tuesday. I'm going to keep working on it, but it feels like it needs a lot more work than there is time before submission | 09:14 |
| mithro | paddatrapper: Okay | 09:14 |
| mithro | paddatrapper: Were are things at the moment? | 09:14 |
| paddatrapper | mithro: master isn't populating FIFO buffer correctly, so it is writing the same 512 bytes all the time. Slave isn't reading them | 09:15 |
| mithro | paddatrapper: Do you want to have a look at it in a little bit? | 09:16 |
| paddatrapper | mithro: sure, though I think we probably want to try get the PR merged first as I'm already dreading the merge conflicts :) | 09:16 |
| mithro | paddatrapper: Sure | 09:17 |
| paddatrapper | mithro: I don't have the git-foo to know what on earth travis is complaining about when it fails to generate the version_data stuff | 09:23 |
| mithro | paddatrapper: Don't worry about it - I'll figure it out | 09:23 |
| paddatrapper | mithro: thanks | 09:23 |
| mithro | paddatrapper: This AC97 codec looks pretty simple - I should have firmware working for it in an hour or two | 09:25 |
| paddatrapper | mithro: awesome | 09:26 |
| mithro | But first I'm going to go find some dinner | 09:26 |
| mithro | paddatrapper: Be back in about 30 minutes | 09:27 |
| paddatrapper | mithro: ok cool | 09:27 |
| mithro | paddatrapper: Back now, but eating dinner | 10:11 |
| paddatrapper | mithro: no stresss | 10:11 |
| mithro | should I be looking at a pull request again now? | 10:14 |
| paddatrapper | mithro: Yup, it's ready for you | 10:15 |
| paddatrapper | also opened one for fixing serial docs | 10:15 |
| mithro | paddatrapper: just merged that one | 10:18 |
| mithro | paddatrapper: I think you missed some of my comments - just a few small things and we can merge it | 10:27 |
| paddatrapper | mithro: which ones (aside from those you've commented on in the last 5 minutes)? | 10:29 |
| *** rohitksingh has quit IRC | 10:30 | |
| mithro | paddatrapper: you might need to open the "outdated" bits... | 10:30 |
| *** rohitksingh has joined #timvideos | 10:32 | |
| paddatrapper | mithro: I've fixed those outdated bits | 10:34 |
| mithro | paddatrapper: Can you make sure you have replied fixed to everything? | 10:34 |
| paddatrapper | mithro: sure will do | 10:35 |
| paddatrapper | mithro: think I've replied to them all | 10:36 |
| mithro | maybe I was looking at an old version... | 10:37 |
| mithro | paddatrapper: You missed the bMaxPower in the .fullspeed | 10:37 |
| paddatrapper | mithro: fixed | 10:39 |
| mithro | paddatrapper: BTW what is UAC_FORMAT_TYPE_I_PCM ? | 10:40 |
| paddatrapper | mithro: PCM formatted audio | 10:40 |
| mithro | paddatrapper: Oh - It means "UAC Format: Type I (PCM)" ? | 10:41 |
| paddatrapper | mithro: yup (UAC = USB Audio Control) | 10:41 |
| mithro | paddatrapper: So the AC97 seems to use 18bit/20bit samples at 48kHz | 10:42 |
| paddatrapper | mithro: ok. Need to change the frequency in the descriptors too | 10:44 |
| mithro | paddatrapper: Yeah but lets get this merge first | 10:44 |
| paddatrapper | +1 | 10:45 |
| paddatrapper | mithro: seems travis only works if it is building a single commit's difference | 10:46 |
| paddatrapper | so if I make 3 commits then push, it will fail | 10:46 |
| mithro | 16, 18, or 20-bit PCM data for Left and Right channels | 10:47 |
| paddatrapper | 18 bit should probably be good enough, CD is 16 and studio is usually 20+ | 10:52 |
| mithro | Putting the codec into anything other than 18bit is going to take a little longer then an hour or two | 10:54 |
| paddatrapper | then 18 is good :) | 10:55 |
| *** rohitksingh has quit IRC | 11:03 | |
| *** rohitksingh has joined #timvideos | 11:03 | |
| *** twoolie has joined #timvideos | 11:04 | |
| paddatrapper | mi | 11:19 |
| paddatrapper | mithro: also I've replied to two of your comments on my final report just seeking clarity on what you mean | 11:20 |
| *** rohitksingh has quit IRC | 11:23 | |
| mithro | paddatrapper: Happy for me to merge? | 11:25 |
| paddatrapper | mithro: yup | 11:26 |
| *** rohitksingh has joined #timvideos | 11:30 | |
| *** twoolie has quit IRC | 11:40 | |
| *** rohitksingh has quit IRC | 11:53 | |
| *** rohitksingh has joined #timvideos | 11:54 | |
| mithro | paddatrapper: So what is next? | 11:55 |
| paddatrapper | mithro: the loopback device or the Travis stuff | 12:00 |
| mithro | I can dig into the travis stuff tomorrow | 12:01 |
| paddatrapper | I've opened a PR for the loopback just so that we can be on the same page | 12:01 |
| paddatrapper | Ok cool. I'm just grabbing lunch. Will be back in 30 minutes | 12:02 |
| mithro | paddatrapper: Okay, can you tell me how to wire them together? | 12:03 |
| paddatrapper | mithro: https://docs.google.com/document/d/16eDShtKzo70vBi_XYxIYivrKqvq-xRCOFcRqp2E75Yc/edit?usp=drivesdk | 12:04 |
| tpb | Title: GSoC Project Report - Google Docs (at docs.google.com) | 12:04 |
| paddatrapper | Not that one... | 12:05 |
| paddatrapper | mithro: https://docs.google.com/document/d/16eDShtKzo70vBi_XYxIYivrKqvq-xRCOFcRqp2E75Yc/edit?usp=drivesdk | 12:05 |
| tpb | Title: GSoC Project Report - Google Docs (at docs.google.com) | 12:05 |
| paddatrapper | No... | 12:05 |
| paddatrapper | mithro: https://docs.google.com/document/d/1EorbduvRUTyo7F9cKXOaUv8S_PKbAmPScTQEOOjun0I/edit?usp=drivesdk | 12:05 |
| tpb | Title: FX2 FIFO Interface - Google Docs (at docs.google.com) | 12:05 |
| paddatrapper | This one... | 12:05 |
| mithro | paddatrapper: Great, I'll go find some wires | 12:08 |
| *** rohitksingh has quit IRC | 12:20 | |
| *** rohitksingh has joined #timvideos | 12:21 | |
| *** rohitksingh has quit IRC | 12:30 | |
| *** rohitksingh has joined #timvideos | 12:30 | |
| *** rohitksingh has quit IRC | 12:32 | |
| *** rohitksingh has joined #timvideos | 12:39 | |
| paddatrapper | mithro: I'm back | 12:49 |
| *** rohitksingh has quit IRC | 12:57 | |
| *** rohitksingh has joined #timvideos | 12:58 | |
| mithro | paddatrapper: Well, it seems I don't have enough wires here | 12:59 |
| paddatrapper | mithro: You can use only FD[0:7] and I'll reduce the data bus width | 13:00 |
| mithro | I managed to find 6, seems someone has raided the makerspace supplies... | 13:00 |
| *** rohitksingh has quit IRC | 13:00 | |
| paddatrapper | hmm... yeah that is a tad short | 13:02 |
| paddatrapper | mithro: perhaps just use the single board and serial to look at EP8FIFOBUF for the moment? Need to try figure out why reading from the FIFO isn't clearing it | 13:04 |
| paddatrapper | mithro: added build instructions to the directory | 13:05 |
| mithro | paddatrapper: So, are you writing manually or using the FIFO? | 13:12 |
| paddatrapper | mithro: the FIFO fills automatically from the endpoint, I then manually read from the FIFO and activate the pins in port B (FD) | 13:13 |
| paddatrapper | mithro: moved everything to 8-bit wide so that serial can be on the same pin as the video firmware and the example | 13:16 |
| mithro | paddatrapper: So when doing the copying out of the buffers to the output pins manually, you want to make sure you disable the Auto-In / Auto-Out modes | 13:32 |
| paddatrapper | mithro: but then data are not copied into the FIFO | 13:33 |
| paddatrapper | s/are/is | 13:33 |
| mithro | The EZ-USB’s CPU is not in the host-to-master data path when AUTOOUT = 1. To achieve the maximum bandwidth, the host and master are directly connected, bypassing the CPU. | 13:33 |
| paddatrapper | mithro: so then I need to do the reading into the FIFO too? | 13:37 |
| mithro | paddatrapper: So, lines 117->122 are suppose to read the data from the buffer and write them to the FDL/FDH output, right? | 13:39 |
| paddatrapper | mithro: yup | 13:39 |
| mithro | paddatrapper: So what you are doing doesn't involve the FIFO stuff at all | 13:42 |
| mithro | paddatrapper: You want to follow the "Access to endpoint buffers" on page 87 | 13:42 |
| paddatrapper | mithro: Well I read from it | 13:42 |
| mithro | paddatrapper: So the docs are actually annoyingly confusing here | 13:44 |
| mithro | What is really happening is the following | 13:45 |
| mithro | PC -> FX2 Buffer RAM | 13:45 |
| mithro | Then there is a FIFO which can do FX2 Buffer RAM <-> IO Pins automatically | 13:46 |
| paddatrapper | ah ok | 13:47 |
| paddatrapper | that is not at all how it came across in the docs... | 13:47 |
| mithro | "When outside logic is connected to the interface FIFOs, the normal data flow is for the EZ-USB to commit OUT data packets to the outside interface FIFO as they become available." | 13:48 |
| mithro | In some cases, it may be desirable to insert a ‘hook’ into this data flow, so that – rather than the EZ-USB automatically committing the packets to the outside interface as they are received over USB – firmware receives an interrupt for every received OUT packet, then has the option either to commit the packet to the outside interface (the output FIFO), or to | 13:48 |
| mithro | discard it. The firmware might, for example, inspect a packet header to make this skip/commit decision. | 13:48 |
| paddatrapper | How it came across to me was PC -> FX2 Buffer RAM -> FIFO Buffer -> FD pins | 13:50 |
| mithro | paddatrapper: So it kind of works like a frame buffer | 13:51 |
| paddatrapper | mithro: ok. So how do you suggest I do the sending from PC? | 13:52 |
| mithro | paddatrapper: In double buffering mode, the PC writes into one buffer region | 13:52 |
| mithro | The buffer is then handed to either the CPU or the FIFO and the PC starts writing into the other buffer | 13:52 |
| mithro | s/buffer/buffer address/ | 13:53 |
| paddatrapper | ah ok | 13:53 |
| mithro | paddatrapper: So if you are trying to manually copy the data out of the buffer onto the pins, you need to tell the FX2 to skip the packet | 13:57 |
| paddatrapper | mithro: skip discards the packet thoug, is that what we want? | 13:58 |
| mithro | paddatrapper: If you just looped over the the whole packet and wrote it manually to the data pins | 13:59 |
| mithro | paddatrapper: Otherwise the packet will be used by the FIFO and you'll get every packet twice... | 13:59 |
| paddatrapper | mithro: well currently the same packet is sent infinitely | 14:00 |
| mithro | paddatrapper: So in manual mode you want to make sure the pins are in "ports" mode | 14:01 |
| paddatrapper | mithro: yup, done that. I've veified that they are triggered when I write to them | 14:02 |
| mithro | You want ENH_PKT set to "1" | 14:03 |
| paddatrapper | mithro: yup, got that | 14:04 |
| mithro | paddatrapper: AUTOOUT should be 0 | 14:05 |
| paddatrapper | yup, doing that now | 14:05 |
| mithro | paddatrapper: Then after writing out the contents of the packet, set SKIP | 14:07 |
| paddatrapper | cool | 14:08 |
| mithro | paddatrapper: You also going to want to bit-bank the clock yourself, rather than using the IFCLK | 14:09 |
| mithro | paddatrapper: That will also let you slow down the rate at which you are clocking the data out, so you can use the other FX2 in logic mode | 14:10 |
| paddatrapper | mithro: ok... how do I do that reliably? | 14:10 |
| paddatrapper | ah yes | 14:10 |
| mithro | paddatrapper: Choose a pin to be the clock | 14:10 |
| mithro | paddatrapper: pull it low, write your data, pull it high, sleep for a bit, pull it low, write your data, pull it high, sleep for a bit, ..... | 14:11 |
| paddatrapper | but I will only be toggling it during the transfer, between them them it will be constant | 14:11 |
| *** rohitksingh has joined #timvideos | 14:16 | |
| mithro | paddatrapper: That should be fine I think? | 14:16 |
| paddatrapper | mithro: ok. I shall give it a try | 14:17 |
| mithro | paddatrapper: I need to head home to bed | 14:22 |
| paddatrapper | mithro: ok no problem. Thanks for your help! | 14:23 |
| mithro | paddatrapper: But yeah, slow the data output down a lot | 14:24 |
| mithro | paddatrapper: And see if you can figure out what is going on | 14:24 |
| paddatrapper | mithro: I'm running it at a quater of the speed | 14:24 |
| mithro | paddatrapper: It's worse than that because the CPU takes X cycles per instruction | 14:25 |
| paddatrapper | mithro: ok it's under a quater of the speed | 14:26 |
| mithro | paddatrapper: Yeah - the FIFO mode which avoids the CPU is much faster as it can transfer 16 bits of data per clock cycle.... | 14:28 |
| mithro | paddatrapper: Feel free to submit your stuff | 14:30 |
| mithro | paddatrapper: I'm sure we'll get it working eventually even if its after GSoC officially ends | 14:30 |
| paddatrapper | mithro: thanks. Will try find a way of speeding that video up and will do | 14:31 |
| paddatrapper | mithro: I certainly want to get it working! It's annoying me now :) | 14:31 |
| mithro | paddatrapper: I'll help you figure out the fast way later too :-) | 14:31 |
| paddatrapper | mithro: awesome, long run that is probably the way to go | 14:32 |
| *** CarlFK has quit IRC | 18:07 | |
| *** thaytan_ has joined #timvideos | 19:00 | |
| *** thaytan has quit IRC | 19:04 | |
| *** CarlFK has joined #timvideos | 19:41 | |
| *** ChanServ sets mode: +v CarlFK | 19:41 | |
| *** CarlFK has quit IRC | 20:01 | |
| *** techman83 has quit IRC | 22:01 | |
| *** techman83 has joined #timvideos | 22:02 | |
| *** ChanServ sets mode: +v techman83 | 22:02 | |
| mithro | paddatrapper: any luck? | 22:52 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!