|
do it half & half ISRs in verilog, bookkeeping app logic in asm
|
#
?
Dec 14, 2015 21:37
|
|
|
|
| # ? May 15, 2024 19:05 |
|
|
im mad because my fun mathy way to kick a can down the road was voted down in favor of the proper solution
|
|
#
?
Dec 14, 2015 21:38
|
|
|
JawnV6 posted:im mad because my fun mathy way to kick a can down the road was voted down in favor of the proper solution you should have just done it your way and built so much on top of if that by the time someone noticed they'd be too fatigued to even bring up the arguement
|
|
#
?
Dec 14, 2015 21:46
|
|
|
its less dev work for me right now, more bookkeeping during integration testing i wanted to do more dev work and less unit tracking
|
|
#
?
Dec 14, 2015 21:48
|
|
|
Bloody posted: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 softcore cpus are fun Barnyard Protein posted:agreed i wouldnt feel bad, thinking about it, this is at heart a high-speed photodiode simulator. that honestly sounds boring as gently caress -- i need a cool project name, how can i start writing code or making project files / git repos if i don't have a project name!
|
|
#
?
Dec 14, 2015 21:52
|
|
|
edit: not the place for work rants, sorry
Jerry Bindle fucked around with this message at 22:35 on Dec 14, 2015 |
|
#
?
Dec 14, 2015 22:09
|
|
|
JawnV6 posted:do it half & half sounds like a deece idea basically what im trying to do is build a debug/logging over serial port side channel into my hardware and doing it entirely in verilog sounds unpleasant
|
|
#
?
Dec 15, 2015 00:33
|
|
|
i think ill probably just try to pack as much meaningful system state into as few bytes as possible, figure out a way to make position in the byte stream obvious, and just spam that out continuously over uart. definitely gonna take a lazy approach, like upper nibble is byte number, lower nibble is byte data, or base64, or something.
|
|
#
?
Dec 15, 2015 00:51
|
|
|
whoa there, "byte" stream? we're just going to give into those fascists who init on grouping up bits by 8?
|
|
#
?
Dec 15, 2015 00:57
|
|
|
hell yeah if it makes you feel better the other data link is 28 bits wide because the top 4 bits of the 32-bit wide bus inexplicably dont work
|
|
#
?
Dec 15, 2015 01:00
|
|
|
lol kind of like one of my first dmx dimming functions could only dim from the 100% to 0. couldn't start it at any other value for some raisin
|
|
#
?
Dec 15, 2015 01:03
|
|
|
did you forget ground return wires so you needed a certain number of '0' in the data lines to act as a ground return? parallel interfaces only, obv.
|
|
#
?
Dec 15, 2015 02:27
|
|
|
also, every development board ever:
|
|
#
?
Dec 15, 2015 02:31
|
|
|
saving that to put up on my classroom wall, tia (i may make a proper cleaned up version)
|
|
#
?
Dec 15, 2015 02:33
|
|
|
movax posted:did you forget ground return wires so you needed a certain number of '0' in the data lines to act as a ground return? extremely lol
|
|
#
?
Dec 15, 2015 02:58
|
|
|
movax posted:also, every development board ever: what do any of these scribblings say
|
|
#
?
Dec 15, 2015 02:58
|
|
|
the best dev board i have just has a processor socket and a poo poo ton of I/O on 100mill header, plus a bunch of on-board peripherals that go ignored 100% of the time
|
|
#
?
Dec 15, 2015 03:10
|
|
|
same but an fpga
|
|
#
?
Dec 15, 2015 05:10
|
|
|
project members mocked me when i said "yeah break every unused fpga pin out to a bigass 0.1" header" whos laughing now fuckers, thing owns
|
|
#
?
Dec 15, 2015 05:11
|
|
|
is there any sort of system-on-module solution similar to the Raspberry Pi compute module that isn't at least twice as goddamn expensive? I mean I'll use the RPi module but surely there have to be some alternatives out there.
|
|
#
?
Dec 16, 2015 22:14
|
|
|
variscite dart board? idk if you can buy just one some flavor of iMX might work as well
|
|
#
?
Dec 16, 2015 22:19
|
|
|
JawnV6 posted:variscite dart board? idk if you can buy just one yeah variscite are all "contact a salesprick so we can figure out exactly how much we can screw you for". gently caress off, compete with the rpi module's price or don't waste my loving time. all other modules are $100+ compared to the RPi CM's $40, I can't justify that at all. nobody is even remotely competitive.
|
|
#
?
Dec 16, 2015 22:48
|
|
|
https://www.olimex.com/Products/SOM/A20/A20-SOM-4GB/ Actually this looks kinda needs-suiting bonus points, it's open hardware so we can always get a cm to build us more if olimex goes tits up
|
|
#
?
Dec 16, 2015 23:07
|
|
|
have fun working w/ an allwinner part and never visiting a webpage without a variscite ad lol
|
|
#
?
Dec 16, 2015 23:37
|
|
|
JawnV6 posted:have fun working w/ an allwinner part Webpages have ads? 
|
|
#
?
Dec 17, 2015 01:41
|
|
|
The RPi2 we have jammed inside the case sometimes doesn't even boot up on power-on so if the A20 can do better than that it's already an improvement
|
|
#
?
Dec 17, 2015 01:42
|
|
|
im tired of working with cypress peesocks and am looking to move on. im working on a design now that doesn't require immense throughput but in the future will require more than the 12 Mbit/s ive been looking at TIs stuff and it seems pretty reasonable. 10/100 ethernet and high speed usb 2.0 would be nice, along with a million gpios all with interrupts. the 4 spi channels are nice since it will need a lot of extra ics. anyone worked with then before/horror stories? i dont think im ready to try fpgas yet due to cost
|
|
#
?
Dec 17, 2015 18:19
|
|
|
fpgas are horror stories so good choice
|
|
#
?
Dec 17, 2015 20:13
|
|
|
Bloody posted:fpgas are horror stories so good choice fpga the 13th
|
|
#
?
Dec 17, 2015 20:32
|
|
|
Fuuuuck it's just one of those days can't get anything working  Like can't even get sample code from a project I found to work without dealing with compilation errors and constant little crap here and there, finally get it all working. Well, "running" anyway. It's outputting crap instead of actually working so all the payoff(?) of Yay it compiles finally and none of the benefit of knowing whether you're at 0 or 9/10 to something working yet Been that way all week actually
|
|
#
?
Dec 17, 2015 21:03
|
|
|
I just cannot get the timing right for bit-banging this protocol via Arduino, even if I inline everything, go at the port directly instead of using digitalRead and digitalWrite, and wrap my little transmit and receive state machines in noInterrupts and interrupts I feel like I'm not going to do much better in assembly either, when I look at the generated code, maybe I'd avoid a few pushes & pops around my timer ISR but I can't imagine those being that huge in overhead for a 100kbps protocol vs a 16MHz CPU I figure I should just have a timer interrupt that looks a lot like this, which seems like it should fit in 160 cycles: code:and of course main loop code is writing to txBuf and reading from rxBuf do I need to move to oversampling, and would 2× be sufficient? could something like the above really fit in less than 80 cycles? or should I just bite the bullet and go to a faster board like the Due (which has a 48 MHz Cortex-M3) for something like this? I'd need to level shift between 3.3V and TTL then but I was thinking I could just use a transistor per channel for this, since the bus uses separate tx and rx lines wish I could just use a goddamn on-chip UART but lol if there's a UART that can handle 15-bit frames at 100kbps (1 start, 12 payload, odd parity, 1 stop) would I be better off just trying to adapt a real VHDL UART design and use a CPLD or FPGA? it seems like then I could plug together some pieces (UART, FIFO, SPI or I2C interface) and make everything easier on myself or I suppose I could try some 74HCT logic: a couple latches, shift registers, etc. I could use a PWM from the Arduino for clocking data to and from the bus, while reading and writing could be done at a much more leisurely pace (and several bits at a time)
|
|
#
?
Dec 17, 2015 22:58
|
|
|
how sure are you of the 16mhz? not just that the clock settings are correct, are you actually within <1% of that? uart needs better than 2% accuracy, so if it's based of an internal RC or something it's probably not working add something that flips a pin at the end of each interrupt, scope it and see if it's running at the expected freq
|
|
#
?
Dec 17, 2015 23:05
|
|
|
eschaton posted:just use a goddamn on-chip UART
|
|
#
?
Dec 17, 2015 23:06
|
|
|
160 cycles should be plenty
|
|
#
?
Dec 18, 2015 00:07
|
|
|
|
|
#
?
Dec 18, 2015 00:13
|
|
|
eschaton posted:a UART that can handle 15-bit frames at 100kbps (1 start, 12 payload, odd parity, 1 stop) you're talking to one, apparently? just use one of those chips
|
|
#
?
Dec 18, 2015 00:15
|
|
|
use a gpio edge detection interrupt to kick off the timer interrupt so it begins sampling half a bit time later in the middle of the bit and you should be able to avoid oversampling. you'd probably have to decouple the transmit and receive functionality though.
|
|
#
?
Dec 18, 2015 02:38
|
|
|
JawnV6 posted:you're talking to one, apparently? just use one of those chips unfortunately an HP 1RD2-6001 master link controller is pretty hard to come by these days (eg since the early 1990s) also they're not just UARTs, they do more of the protocol implementation than that, so I can't just use an HP 1RC8-6000 slave link controller pulled from a peripheral (which can be found pretty easily, and I already have a bunch) as a workaround
|
|
#
?
Dec 18, 2015 02:52
|
|
|
sund posted:use a gpio edge detection interrupt to kick off the timer interrupt so it begins sampling half a bit time later in the middle of the bit and you should be able to avoid oversampling. you'd probably have to decouple the transmit and receive functionality though. thanks, that seems like a good thing to try maybe I'll also try using a Due and oversampling, since 48 MHz and a 32-bit RISC CPU should give me a ton more room to be sloppy and still see something work
|
|
#
?
Dec 18, 2015 02:55
|
|
|
|
| # ? May 15, 2024 19:05 |
|
|
JawnV6 posted:how sure are you of the 16mhz? not just that the clock settings are correct, are you actually within <1% of that? huh, that's good to know, I have no idea but it's easy enough to figure out the HP-HIL spec also turns out to mention that implementations need to support ±8% quote:add something that flips a pin at the end of each interrupt, scope it and see if it's running at the expected freq this seems like great general hardware debugging advice I was also considering either setting up a PWM or even just the CPU clock so my analyzer would have a clock signal to use in capturing a trace of what my device and the device I'm talking to are putting on the lines, and how terrible my timing really is
|
|
#
?
Dec 18, 2015 03:03
|
|