a thread about janitoring individual bits and using oscilloscopes and stuff

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > a thread about janitoring individual bits and using oscilloscopes and stuff

«‹›2 »

Jerry Bindle: May 16, 2003

Werthog 95 posted:

hey so here's a hobbyist's question for the actual experts itt

i was gonna make a usb adapter for my ADB keyboard
()
because the protocol is super simple

but then i found somebody else had already made one, all you had to do was stick an s-video port on a teensy and load his firmware https://geekhack.org/index.php?topic=14290.0

the problem is: it sucks

so if i wanted to make my own, what's the hip good microcontroller for making usb adapters (that doesn't require me to use TI's lovely loving dev environment)

if you don't have a usb analyzer, whatever mcu you choose, be sure there is a good working demo to use as a starting point. if you use a pic you'll already have a really good keyboard usb project to start with, you'd just have to implement the ADB protocol. i only work with pic's, maybe some other vendors also have good keyboard demos to start from.

# ¿ Dec 2, 2014 02:27

Adbot: ADBOT LOVES YOU

# ¿ May 4, 2024 04:26

Jerry Bindle: May 16, 2003

Tin Gang posted:

not joking, I once partially wrote some pic assembly code to read output from ps2 devices and it was easy as hell. writing a usb interface from scratch would be a nightmare though

dsPIC/PIC24 ASM is really fun. its like a baby pdp11. you can still squeak out better performance than the C compiler, so its not completely pointless either.

you probably know of him if you read the pic list, but this guy named olin from embed inc taught a class at microchips conference about ASM. he has this software package for writing in pic ask, iirc he wrote a USB stack with it

# ¿ Dec 2, 2014 02:50

Jerry Bindle: May 16, 2003

1+1=0 in GF(2)

# ¿ Feb 1, 2015 19:50

Jerry Bindle: May 16, 2003

the total phase aardvark is a pretty cheap spi/i2c host adapter that can do SPI @ 8MHz

# ¿ Feb 15, 2015 21:39

Jerry Bindle: May 16, 2003

Mido posted:

bit bang it with an arduino (really easy to do actually, and potentially "fast enough")

is there any reason you wouldn't use the arduino / avr's hardware SPI? i'm not familiar with the arduino but i'm familiar enough with mcu's to know the simplest peripherals can be broken pos's

# ¿ Feb 15, 2015 21:48

Jerry Bindle: May 16, 2003

Yeah maybe its not the flashrom thats the problem. i googled "64Mbit spi flash" and this is the first data sheet i found. http://ww1.microchip.com/downloads/en/DeviceDoc/25036B.pdf

this fellow has 256 byte pages, a "fast" 1.5ms page program time, this is about 45 seconds ~~6 minutes to program the whole 64Mbit. maybe 30 minutes is reasonable for your flash device~~ i did a bad math

Jerry Bindle fucked around with this message at 03:46 on Feb 16, 2015

# ¿ Feb 16, 2015 03:08

Jerry Bindle: May 16, 2003

where does the 115k baud come from?

# ¿ Feb 16, 2015 04:54

Jerry Bindle: May 16, 2003

Bloody posted:

pretend this is added to my list of bullshit spi interfaces: an interface which is change rising/capture falling when writing registers, and is capture rising/change falling when reading registers

what would this get you? full duplex spi with 1 shared IO pin, 1 clock pin and 1 cs?

# ¿ Apr 3, 2015 21:12

Jerry Bindle: May 16, 2003

xilinx ise 12.4 is great. it supports the Spartan 3E on digilent's nexys2 board, AND schematic entry!

# ¿ Apr 5, 2015 19:46

Jerry Bindle: May 16, 2003

Star War Sex Parrot posted:

I think I set my fuses wrong on my ATMega32 while trying to get it working with an external crystal. I'm not sure if it's expecting an external clock signal or what but it doesn't work anymore. Gonna try either a function generator or another ATMega to generate a clock and see if that gets it back to life long enough to program the fuses again

Lesson learned

i know very little about AVRs, it is surprising to learn that you can brick a part that easily. on dspic/pic24's you can clock the CPU from the programming port to recover from situations like that (flash is always clocked from the internal oscillator). it looks like you might be able to do something similar on atmega32's, http://www.atmel.com/images/doc2503.pdf page 261. welp good luck

# ¿ Apr 7, 2015 20:32

Jerry Bindle: May 16, 2003

does it make sense to use FPGAs to prototype an ASIC that has several different power modes and clock domains?

# ¿ Jun 28, 2015 20:30

Jerry Bindle: May 16, 2003

It'd be so nice to get to play with logic pre-silicon. oh the inputs for this module didn't get synthesized because reasons :downs:

lets do a new revision!

# ¿ Jun 29, 2015 18:54

Jerry Bindle: May 16, 2003

i think it depends on what kind of work you want to do. if you want to do digital design, well, i'm under the impression that fpga work is that it is something that digital designers kind of fall into based on the requirements of the project that they're given.

# ¿ Jun 30, 2015 16:08

Jerry Bindle: May 16, 2003

not having a ground connection is messing up my head, i can't do it. how are you supposed to do these without a gnd? i got as far as doing the 4-input-and, but i have some kind of mental block on the 4-or

# ¿ Jul 20, 2015 14:47

Jerry Bindle: May 16, 2003

i was over thinking it -- you don't have to think about currents/voltages, just delay and logic. finally got the POR working, but im stumped on the oscillator. i get the idea that it should have an inverter ring, but... hmm.

# ¿ Jul 20, 2015 15:59

Jerry Bindle: May 16, 2003

i feel bad for people who don't either sit up in an ivory tower at a si company and thus have no need for a data sheet, or order in large enough volume to have a field engineer's cell #.

# ¿ Jul 22, 2015 05:29

Jerry Bindle: May 16, 2003

Sweevo posted:

for reals tho, the worst is every datasheet written by microchip

ding ding ding ding

# ¿ Jul 22, 2015 14:01

Jerry Bindle: May 16, 2003

Mr Dog posted:

the worst is everything produced by microchip

ding ding ding ding

# ¿ Jul 22, 2015 14:02

Jerry Bindle: May 16, 2003

i've recently written pic datasheet and boy are my appendages that are used to navigate disastrously poor documentation processes tired

# ¿ Jul 22, 2015 14:08

Jerry Bindle: May 16, 2003

the pic16's and pic18's are pretty solid. if you're using anything else then i hope you have access to a good FAE!

# ¿ Jul 25, 2015 00:06

Jerry Bindle: May 16, 2003

Hesh Ballantine posted:

im working on a project to upgrade some lab equipment used in photon coincidence counting, basically replicating a NIST setup that uses FPGAs for time-stamping coincidences with about 2.5ns resolution

http://www.nist.gov/pml/div684/grp03/multicoincidence.cfm

ask me about janitoring quantum entanglement detection apparatus, idk is this even the right thread for this thing?

yeah you're in the right place imo. i'm surprised to see 2.5ns resolution with an off-the-shelf FPGA board. i would have suspected that you'd need a special pcb layout to make sure the lengths are correct and the impedances matched. what kind of analog front end are you using?

# ¿ Jul 26, 2015 00:30

Jerry Bindle: May 16, 2003

Hesh Ballantine posted:

I think the capability you are describing came a year or two after the custom solution was designed, they published the paper on it in early 2009 so they must've started designing at least a year prior.
that said, as you pointed out it's an academic lab and none of us are EEs, trust physicists to find the most convoluted solution possible

at my university we had some cross-discipline cooperation. EE students would help the physics/chemistry department with instrumentation. perhaps you could get a more reliable HW setup for free* and give someone a master's thesis topic at the same time. i don't know the details of your role in the project so maybe doing what i suggested would take work off your plate that you wanted to do. being able to setup your own instrumentation must be a valuable skill for a physicist to have, but it'd be a shame to spend all your time being a FPGA janitor when what you really want to do is jerk off to quarks and bosons.

# ¿ Jul 28, 2015 15:32

Jerry Bindle: May 16, 2003

be nice to validation people, unless they just assume the design is right and write a bunch of tests that always make sure the design is what the design is, then smack them!

# ¿ Aug 5, 2015 17:40

Jerry Bindle: May 16, 2003

i guess this is as good as time to ask as any. how is chip level validation _supposed_ to work?

I get this basic idea: 1) Design reads <IP-SPEC> then implements <IP-RTL>. 2) Validation reads <IP-SPEC"> then tests "IP-RTL" against the spec.

how reasonable is it for design to make a mistake, then validation to make the identical mistake that results in the mis-configuration of entire modules?

Should validation have a black-box view of the RTL? Should validation have access to any of the definitions internal to the design?

# ¿ Aug 5, 2015 18:09

Jerry Bindle: May 16, 2003

JawnV6 posted:

microprocessors and microcontrollers

I started to type out a post to answer this one but god drat is it difficult.

# ¿ Aug 9, 2015 02:32

Jerry Bindle: May 16, 2003

i have a hard time with communicating that an explanation is a simplification that won't hold up for more advanced applications of the concept i'm talking about. like for the microprocessor vs microcontroller comparison: the 100k ft view is the differences in level of integration. but there are so many other factors that feed into why and how and what that i get lost in my head about what to write next.

# ¿ Aug 9, 2015 02:37

Jerry Bindle: May 16, 2003

Mido posted:

I would draw the line between the philosophy behind the MCU/processors intended use of the internal byte code architecture

no one (sane) is making really elaborate operating systems that run on PIC, you... could but it's not suited for it compared to say a Motorola SoC with an arm core

yeah but there are PICs with MIPS cores :colbert:

# ¿ Aug 10, 2015 03:52

Jerry Bindle: May 16, 2003

yeah i get what you mean and i agree, the dividing line is the application, the architecture typically follows from that.

# ¿ Aug 10, 2015 03:59

Jerry Bindle: May 16, 2003

i'm pretty sure that is the motivation behind MIMS. the worlds tiniest bird-flipper.

# ¿ Sep 17, 2015 00:27

Jerry Bindle: May 16, 2003

the thing about i2c is that there is no magic resistor value that will always work, but 100k is insanely weak. 4k7 is a good starting point, but it might not work depending on a number of factors that would be comparatively difficult to model when you could just pick a resistor footprint, order a PCB and try it out.

# ¿ Oct 12, 2015 17:23

Jerry Bindle: May 16, 2003

digital designers have a deep hatred of clock domain crossings. some hate them so much that they will completely ignore implementing the main feature of a module in order to not have to deal with them.

# ¿ Oct 20, 2015 14:09

Jerry Bindle: May 16, 2003

here is a halloween tip that you can try at work, instead of "BOO!" scare a digital designer by saying "CDC!"

# ¿ Oct 20, 2015 14:11

Jerry Bindle: May 16, 2003

yeah i'm not a digital designer so idkwtf i'm talking about really but i work with them and they talk about CDC's like they are this insurmountable problem. stuff like - no no no we had to synchronize that async clock input because clock domain crossings.

# ¿ Oct 20, 2015 14:55

Jerry Bindle: May 16, 2003

"throw it out and start over" is what they did for this one module that didn't work, the redesign didn't work so they threw that one out too, then they did it another time. maybe the fourth time will be different!!

tbqh tho i don't think the designers are really to blame, there are other issues at play

Jerry Bindle fucked around with this message at 23:23 on Oct 20, 2015

# ¿ Oct 20, 2015 23:19

Jerry Bindle: May 16, 2003

Fanged Lawn Wormy posted:

idiot embedded programming question:

I'm working on moving out of the arduino environment - I've been using VisualMicro w/ Visual Studio for a spare time project, and it's really awesome. I'm working on separating things into different .cpp files... but is there a standard place for putting all my #define statements? Like, I guess stuff specifically for the functions of that cpp file would go there, but what about global stuff? Does that go in my main file or what?

sounds like you've got the right idea, you'll have to figure out the details yourself based on your workflow preferences, tools, etc. over time, you'll refine the conventions you use to organize and develop your firmare.

this shows the source for two applications.

. ├── include │�� └── spi.h └── src ├── app │�� ├── adapter │�� │�� ├── config.h │�� │�� ├── main.c │�� │�� └── Makefile │�� └── logger │�� ├── config.h │�� ├── main.c │�� └── Makefile └── driver ├── spi_x.c └── spi_y.c

both applications use the same API for the communicating with a spi device, so both main files start out like this,

code:

#include "spi.h"
int main () {
	...

but 'adapter' uses one kind of MCU, and 'logger' uses another. the same driver can't be used for both mcu's because they have different spi peripherals. to sort this out, each makefile needs to compile the right file.

you should try to avoid using global #defines to configure drivers when possible.. there are some good reasons to do it, e.g. you really want to maximize battery life and minimize wake-time, so you don't want to configure your modules at run time. configuring your code with defines will however make your code less maintainable. at first its one #if, then its another, before long it becomes a mess.

logger/config.h

code:

#ifndef CONFIG_H
#define CONFIG_H
#define SPI_BAUD 1E6
#endif

adapter/config.h

code:

#ifndef CONFIG_H
#define CONFIG_H
#define SPI_BAUD 2E6
#endif

for the driver to see that define, we just include it from the driver,

driver/spi_x.c

code:

#include "config.h"
#include "device_header.h"
void spi_init() { SPI1BAUD = SPI_BAUD; } // SPI1BAUD provided by device_header.h

we could create a new application that sets SPI_BAUD to the desired value and re-use spi_x.c without breaking the other project.

a side effect of including config.h in the driver is that it ties your driver implementation to the workflow conventions you've defined. at best, your code will be difficult to share with others, at worst your source tree will become difficult to maintain over time.

a better way would be to expose the functionality you want through an API call rather than a global define. here i'm replacing the SPI_BAUD define with a setter

include/spi.h

code:

void set_baud(uint16_t baud);

implement that function correctly for both spi_y and x, and remove the "config.h"
spi_x.c

code:

// #include "config.h"
#include "spi.h"
void set_baud(uint16_t baud) { SPI1BAUD = baud; }

then instead of the #define SPI_BAUD line, call the set_baud function from the app/.../main.c

logger/main.c

code:

#include "spi.h"
int main () {
	set_baud(2E6);
	...

Jerry Bindle fucked around with this message at 23:14 on Dec 4, 2015

# ¿ Dec 4, 2015 23:09

Jerry Bindle: May 16, 2003

i can't imagine what it is that hosed up in the usb to make that much ram needed to solve the problem, but at the same time it sounds like the right call

# ¿ Dec 7, 2015 22:02

Jerry Bindle: May 16, 2003

oh i've only worked with usb2.0, i bet 3.0 has a whole nest of catches i have no clue about

# ¿ Dec 7, 2015 22:06

Jerry Bindle: May 16, 2003

yeah thats a nice schematic, what is it done in? zuken?

# ¿ Dec 12, 2015 03:41

Jerry Bindle: May 16, 2003

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

Adbot: ADBOT LOVES YOU

# ¿ May 4, 2024 04:26

Jerry Bindle: May 16, 2003

thanks for the perspective

# ¿ Dec 13, 2015 18:13

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > a thread about janitoring individual bits and using oscilloscopes and stuff

«‹›2 »