|
how do i test freeRTOS tick rollover 0xffffffffms is ~49 days, I need some way to start it at 0xfffff000. lot of internal structure means I can't just jam that value in at reset internally, there is literally nothing done to handle it. all the comparison math is ovf-safe, im not smart enough to make that same guarantee for my stuff
|
#
?
Dec 7, 2015 23:05
|
|
|
|
| # ? May 16, 2024 09:34 |
|
|
JawnV6 posted:how do i test freeRTOS tick rollover I think you can just jam it in there. tasks.c initializes it to zero statically and again when vTaskStartScheduler is called. xTaskIncrementTick handles the overflow event if you want to inspect that.
|
|
#
?
Dec 8, 2015 20:50
|
|
|
Bloody posted:it's 2.0 only but a 32x8192 fifo fills in idk a few milliseconds in our system and we're just using a bulk endpoint because i didnt want to figure out how to use a different one and then make a different one go fast enough USB3 Bulk is just horrible without some kind of backpressure support or endless FIFO. I worked on a board that transferred about 220 MB/s and it had to use bulk (thanks USB3 Vision, why can't I use isochronous which is there for video ???). Thing is, with bulk transfer Windows gives you the lowest priority to get rid of your data. Even just using the mouse or opening a browser would stop transfers for 10-20 miliseconds. Have fun compensating for that with FPGA SRAM. Isochronous transfers with enough reserved bandwith really help with that, especially with the data rate you're describing. But you do lose guaranteed packet delivery with it.
|
|
#
?
Dec 8, 2015 21:44
|
|
|
I have a lot of control over the computer and the user so I should be able to compensate with a reasonably large dedicated fifo ram in the next revision
|
|
#
?
Dec 9, 2015 01:52
|
|
|
sund posted:I think you can just jam it in there. tasks.c initializes it to zero statically and again when vTaskStartScheduler is called. xTaskIncrementTick handles the overflow event if you want to inspect that. hm, I was convinced it'd to something stupid like not have any ready tasks. worth a shot, should have time to set it up later this week anyway, ive finally gotten around to implement protobuf's and they're rocking my world. encoding is a fraction of the time, size is ~25% of equivalent JSON now, I haven't un-packed anything, but how could that possibly go wrÄ‚‘ôØ3
|
|
#
?
Dec 9, 2015 19:11
|
|
|
karasu posted:USB3 Bulk is just horrible without some kind of backpressure support or endless FIFO. I worked on a board that transferred about 220 MB/s and it had to use bulk (thanks USB3 Vision, why can't I use isochronous which is there for video ???). the USB video device class can actually work with high speed cameras and Windows seems prioritize it slightly higher. still no guarantees, which is a bit of a problem for a lot of machine vision applications still need the ram
|
|
#
?
Dec 9, 2015 19:22
|
|
|
I wrote a firmware for a wirelessly-networked electricity meter, that was kinda fun (not revenue-grade, it's for the customer's use, not the utility's) so i got to continue my informal (wikipedia) education about electricity and electronics by reading up on like active power and apparent power & stuff like that (i already had a vague understanding of how impedance is represented using complex numbers so it was fairly straightforward) this job is actually kinda fun the 10% of the time i'm doing the poo poo i was actually hired to do
|
|
#
?
Dec 10, 2015 16:57
|
|
|
i'm itching to do something with a fpga and it's been awhile since i've console nerded out tell me about optical drive pickup assemblies
|
|
#
?
Dec 10, 2015 21:11
|
|
|
wrong answer correct answer: dedicated twitch streaming box, hdmi in, rj-45 out
|
|
#
?
Dec 10, 2015 21:14
|
|
|
JawnV6 posted:wrong answer oh god i figure a zynq would be perfect for that though.
|
|
#
?
Dec 10, 2015 21:16
|
|
|
i posted awhile back in the retro games thread about wanting to roll my own ps2 modchip for shits and giggles (and to figure out how they did it back in the day) now i was recently thinking that if i could replace the optical pickup assembly in any given optical drive with a solid-state version, you can boot anything you want on the real hardware regardless of health of the wear item (laser) i figure this will interest approximately 7.32 people so they can play their ps2 jrpgs until the end of time
|
|
#
?
Dec 10, 2015 21:18
|
|
|
oh doing THAT end of it i thought you were emulating the host and wanted to control a drive, which seems a lot more complex/impossible
|
|
#
?
Dec 10, 2015 21:19
|
|
|
JawnV6 posted:oh doing THAT end of it oh yeah, no -- that's what a couple of things do right now, but there's always that slight weirdness for one title or another (that comes from emulating a reverse-engineered interface) i think the dreamcast was more or less atapi, but the ps1/ps2 in very japanese fashion have some hilarious large (probably like... .25um or larger) discrete asics that implement the drive controller (mechacon). studying the schematics i've found and the modchip install points, it looks like most chips hop onto some of the bios mask rom address/data lines, a couple of cs / oe lines and then a couple of pins on the mechacon however, if you build something with a dac that emulates the signals a laser would normally transmit, then no one will ever be the wiser (i think) -- you take in the motor control and turn that into your clock, trigger e/f to have 'perfect focus', and then a/b/c/d as the data, but i can't find any good documentation on this poo poo.
|
|
#
?
Dec 10, 2015 21:30
|
|
|
movax posted:i can't find any good documentation on this poo poo. hold the phone... this sorta implies you've found good documentation on other poo poo??? where??
|
|
#
?
Dec 10, 2015 21:41
|
|
|
yeah step 1 sounds like you're collecting traces of a working system so your FPGA is going to be a LA, connect all the right pins, 'watch' for a while on known inputs, then cut traces to the real components and start spoofing
|
|
#
?
Dec 10, 2015 21:43
|
|
|
JawnV6 posted:hold the phone... this sorta implies you've found good documentation on other poo poo??? where?? the schematic pdfs i have for the ps2 and ps1 are actually pretty loving amazing -- i don't know what cad package puts it out, or if it is a technical writing group but man it's hot
|
|
#
?
Dec 10, 2015 22:27
|
|
|
movax posted:now i was recently thinking that if i could replace the optical pickup assembly in any given optical drive with a solid-state version, you can boot anything you want on the real hardware regardless of health of the wear item (laser) there was a company that did something like this for a DVD jukebox to work around the CSS restrictions their jukebox just returned the same bitstream as the drive to a DVD decoder mechanism, so their customers could rip DVDs that were indistinguishable to it from physical discs but not otherwise decoded
|
|
#
?
Dec 11, 2015 07:14
|
|
|
so yeah do you actually need an analog signal like would come in off the laser? i bet that poo poo gets converted to bits awfully quickly, since the discs are digitally encoded, and that would give you a far better place to jump in you could also probably look at the signals going to the motors, and figure out what specific bits it wants from that
|
|
#
?
Dec 11, 2015 07:19
|
|
|
wouldn't the motor have to be encoded too? there's no way they're controlled precisely enough, gotta be reading back position where's the schematic, the intercept point is spread across a few different interfaces
|
|
#
?
Dec 11, 2015 08:48
|
|
|
peep it: i have the full pdf too, pm if you want it
|
|
#
?
Dec 12, 2015 03:31
|
|
|
i think IC801 is a TI op-amp but i'm not sure. it's the first stage interface to the optical drive, and then it goes further to ic605 which is a sony cxd1869aq asic (cd/dvd dsp) coupled with cxp101064, another asic which is on mechacon duty. (aside, i wonder if there's a list of sony part prefixes somewhere). the dsp does the real nasty work of reading from discs. the injection point is CN801. from what i have been able to find on how cd/dvd drives fuckin' work (greybeard heaven: http://www.repairfaq.org/REPAIR/F_cdfaq9.html#CDFAQ_009) A, B, C, D -- focus / data signals E, F -- tracking (potentially stupid simple to emulate since i will have perfect tracking / focus) PD1, PD2 -- photodiode 1, photodiode 2 (laser diode?) ABCD appear to be ac coupled cn804 is the spindle motor connector, which i think i only need to use as an input to get an idea of where the host wants the target disc H/H1/H2/H3/A1/A2/A3 -- drive motors and poo poo i need to find a datasheet on IC801 but it is tough. ic802 is Rohm i think judging from the part number prefix (and the japanese love rohm). PD1/PD2/A-F I think are the set of high-bandwidth signals to generate into the RF amp, and then the 'control bus' is my input as to what it's asking for. and can i reiterate again how loving nice these schematics are? absolutely miserable to print out i'm sure but beautiful on a screen e: 
movax fucked around with this message at 03:43 on Dec 12, 2015 |
|
#
?
Dec 12, 2015 03:37
|
|
|
yeah thats a nice schematic, what is it done in? zuken?
|
|
#
?
Dec 12, 2015 03:41
|
|
|
as a comparison, the ps1 uses the super common ksm-440aem opa: different rf amp this time (that was probably in a fuckload of sony cd players), but slightly less signals since it's a CD only still 2 PD signals, and only E and F out now. no A, B, C or D. spindle motor / sled motor is a separate connector i'm like 15 years too late to this -- i tried searching TIs/etc websites for their marketing poo poo intended for optical drive makers in the 90s and i can't find it anywhere. bet they'd have reference designs that would be more than happy to show how to use their parts to build this. Barnyard Protein posted:yeah thats a nice schematic, what is it done in? zuken? could be, i've heard good things about zuken.
|
|
#
?
Dec 12, 2015 03:48
|
|
|
now that i'm kind of revisiting this project (http://www.repairfaq.org/REPAIR/F_cdfaq1.html#CDFAQ_012) (editor note: this poo poo is complex and economies of scale always blow my mind -- these things became loving ubiquitous) using the ps1 rf amp as a reference -- * LD is laser diode output that uses Q701 and friends to power the actual laser diode inside the opa * the PD pins are sense inputs, for what i'm not sure -- closed loop control of laser power, most likely. *the actual reading element is essentially a quadrant detector i'm pretty sure -- the document says that focus is perfect when (A+C)-(B+D) = 0. i guess the ps1 may not be a 3-beam pickup system. E and F must be the only data coming out of the drive. found a datasheet for the CXA2586 which is a photodiode ic for cd-rom / dvd-rom drives and it basically confirms that each photodiode output is a high-speed iv amplifier -- converts photocurrent to a voltage. runs off the supply rail of said pdic as well. i think my block-diagram would be something like: data store -> buffer -> FPGA -> serial DAC -> AFE -> connector fpga handles taking raw iso data and applies efm to generate the appropriate signaling data store being a SD card (probably), or if i use a zynq or something (oh god $$$), it could be anything and i dma it into fabric from ethernet/sd/usb/sata/what have you e:  really need to get the datasheet(s) of the CXA2575N and SP3727ACA. movax fucked around with this message at 04:25 on Dec 12, 2015 |
|
#
?
Dec 12, 2015 04:04
|
|
|
how are you going to handle seeking, optical drives have some interesting stuff going on there which requires some kind of feedback in the data stream
|
|
#
?
Dec 12, 2015 05:10
|
|
|
so there's no tap where you can just inject a bitstream? maybe you can work backwards a bit more to a point where things are digital did PS2 Linux support the disc drive? maybe you could look at its driver and then just attach something to the CPU bus to emulate the registers/memory used to talk to the drive
|
|
#
?
Dec 12, 2015 05:21
|
|
|
eschaton posted:so there's no tap where you can just inject a bitstream? there is a tap where i could inject a bitstream; there's always the option of moving in layers and emulating different aspects of the interface, but there's some additional complexity there and additional risk of introducing weird one-off glitches because there's some game out there that expects certain timing behavior BobHoward posted:how are you going to handle seeking, optical drives have some interesting stuff going on there which requires some kind of feedback in the data stream the way i understand it, there's only a couple of possible inputs to the drive to set position / read speed stuff, and that's the spindle motor speed, the tray position (sliding) and a tilt angle. it looks like most of the amplifiers output tracking error and focus error signals too; if i can simulate zero tracking error and focus error, that might work -- but then again, some error might be expected because it (the actual dsp / controller) uses it as a control loop to figure out where on the disc it is vs. where it needs to be.
|
|
#
?
Dec 12, 2015 19:34
|
|
|
movax posted:the way i understand it, there's only a couple of possible inputs to the drive to set position / read speed stuff, and that's the spindle motor speed, the tray position (sliding) and a tilt angle. the control loop during a seek is what i was thinking of, iirc the drive tries to make an estimated seek movement, looks at the sector #, then makes a correction (which might be in the opposite direction), looks again, repeats until it hits a sector before and sufficiently close to the target sector of the seek, and then waits for it to arrive in the data stream you have no idea what the target is so so you're gonna have to figure out some approach for feeding that control loop in such a way that it actually does the right thing in the end. sounds like a lot of fun (non ironic cool reverse engineering fun)
|
|
#
?
Dec 12, 2015 21:25
|
|
|
BobHoward posted:the control loop during a seek is what i was thinking of, iirc the drive tries to make an estimated seek movement, looks at the sector #, then makes a correction (which might be in the opposite direction), looks again, repeats until it hits a sector before and sufficiently close to the target sector of the seek, and then waits for it to arrive in the data stream i just ordered a copy of 'dvd players and drives' from amazon for like $5 -- the google preview had some pretty good indications that the dude goes in depth about the details of the focus searching / tracking error stuff. i think i detailed the pinout of the ps2 dvd-rom to myself in sufficient fashion as well: code:i think in the end it all gets turned into the rf output which is all 1s and 0s (in both ac coupled and dc coupled form); i could maybe jump in there, but then soldering begins to be required instead of simple harnessing so the input seeking commands i believe would be based on the tracking coil, focus coil, and sled movement (on a different connector) inputs, all of which are fed to the ba5815fm driver ic. i can probably put a small dummy coil load in place, feed that into an adc and use that in the digital domain to see what the drive controller thinks he's requesting. for outputting simulated photodiode signals, the best option might actually be putting dummy diodes and outputting across them with a dac to generate the expected voltages. the PDIC inside the opa acts as a IV amplifier so maybe feeding an op-amp or diodes with a digital waveform may take care of my analog interface problems. i'm only semi-concerned about the power-budget -- there's a 5V connection on the PS2, but i have no idea how much current it could source. i'd really love to make ethernet an option for this, but sd card is sadly probably the simplest method. with ethernet i'd have to deal with embedded tcp/ip stacks, and i'm cringing thinking of implementing stable smb/cifs/nfs support, unless i use something that can run linux, and now i need ddr and it's going to miserable and lovely. maybe a wifi module + bluetooth serial modem (for config via phone app) is the most user-friendly way of streaming content to this thing, in conjunction with a local sd slot 'just in case'. e: the best part is i finally have a project to work on in the past few years that doesn't need to be concerned about radiation tolerance at all -- so every part is an option, hooray! movax fucked around with this message at 22:23 on Dec 12, 2015 |
|
#
?
Dec 12, 2015 22:11
|
|
|
cool, i didn't know these kinds of docs were out there what's the "tilt driver" chip in the ps2 for? does the dvd drive need to know the console orientation to work?
|
|
#
?
Dec 12, 2015 22:49
|
|
|
Spatial posted:cool, i didn't know these kinds of docs were out there im pretty sure it's for tilting the optical drive sled / lens to improve focus and tracking accuracy, but not 100% sure
|
|
#
?
Dec 13, 2015 01:47
|
|
|
this is a super cool idea
|
|
#
?
Dec 13, 2015 17:43
|
|
|
Bloody posted:this is a super cool idea agreed also i feel like a dipshit calling myself an embedded engineer while there are people fuckin around with stuff this complicated in their spare time. i mean good lord, the amount of time i wasted loving around with uarts
|
|
#
?
Dec 13, 2015 18:01
|
|
|
nah embedded is so broad and dumb never feel like a dipshit
|
|
#
?
Dec 13, 2015 18:07
|
|
|
there are huge tracts of embedded I know literally nothing about (amba /ahb/apb, rtos, anything bigger than a cortex m, hybrid fpga/mcu, plus a bazillion random other things) but still strongly identify as an embedded engineer. don't sweat it ever remember: Toyota, a real actual successful company, has car firmware using literally over 5000 global variables to do stuff
|
|
#
?
Dec 13, 2015 18:09
|
|
|
thanks for the perspective
|
|
#
?
Dec 13, 2015 18:13
|
|
|
on a small MCU all variables are global 
|
|
#
?
Dec 13, 2015 18:35
|
|
|
yeah "global" just means RAM
|
|
#
?
Dec 13, 2015 18:37
|
|
|
also I'm working with arm cortex a9 based systems and now and it feels like cheating
|
|
#
?
Dec 13, 2015 18:37
|
|
|
|
| # ? May 16, 2024 09:34 |
|
|
im thinkin about sticking a cpu core in my fpga because sending variable length strings over uart from verilog sounds like a horrendous pain in the rear end
|
|
#
?
Dec 14, 2015 21:34
|
|