<emeb>
tnt: interesting how the rx value isn't available until the next tx
<tnt>
so the general idea is that clearing of the bits in SPICSR puts the core in active mode. it will assrt the selected CS whenever it gets the first byte.
<emeb>
yeah - I was noticing that feature.
<emeb>
very different from most MCU-based SPI ports I've used which just leave the CS handling to the higher levels
<tnt>
emeb: yeah, it makes sense because you first fill SPITXDR. Then that register gets transferred into the shift register and you can already write the next TX byte. But of course at that point the shift register hasn't shifted anything yet, so you can't RX anything yet ...
<emeb>
tnt: ah, true. if you're keying off the tx empty flag.
<emeb>
but if you waited for rx full then there would be needless gaps.
<tnt>
you can simplify the logic a bit and just wait for RXRDY and when it's high you know you can both read a byte and write the next but you have a bit more dead time between bytes
<emeb>
:)
<tnt>
As it is I still have dead time because I only divide the bus frequency by 4 and the softcore can't keep up.
<emeb>
what clock rate do you give the spi core?
<tnt>
atm, 12 MHz
<tnt>
I haven't put a pll in that design yet so it's just the xtal frequency.
<emeb>
so 3MHz SPI sclk then
<tnt>
yes
<tnt>
apparently you need to at least divide by 4.
<emeb>
I read something about that - has to do with the auto CS logic IIRC
<tnt>
the 'cs hold' thing ... but ... if you don't use that feature, the core is basically unusable AFAICT because if it doesn't have any new data to TX, it just repeats the previous one !?!?
<emeb>
ugh - "feature"
<tnt>
mm, you can actually divide by 3, that still works. div-by-2 doesn't.
<tnt>
but ... tha really just increase the dead time, so not much point.
<tnt>
Anyway, I don't really care about speed here, I just wanted to be very small and use basically no-logic. If I wanted a high efficiency core, I'd use quad-spi ddr mode and all that stuff.
sgstair has joined ##openfpga
<emeb>
heh, yeah.
<emeb>
iirc you're trying to get access to read the flash chip for loading data after the system has started up.
<emeb>
since the original spi ifc in cliffords picorv just worked at init time
<tnt>
the spi in the picrorv does XIP so it can execute code from flash, but it's not super fast to do so and the core is also not that small. I have a risc-v design where I put my own minimal spi flash loader to 'boot' the picorv32 from flash (preloading a spram).
<tnt>
But here it's not actually for the picorv32 but for my own 16-bit softcore.
<emeb>
ah ok
<tnt>
It has a 'peculiar' bootsequence :
<tnt>
Basically it can only execute code from its main SPRAM.
<tnt>
but of course ... it's not initialized, and I didn't want to pay the code of another mux in the adress path for boot.
<emeb>
make sense
<emeb>
interesting - was just looking at the docs for the i2c and spi WRT the BUS_ADDR74 - seems there's a documentation error
<tnt>
So, for program space it has a SPRAM + a 16 word ROM. That ROM is the first-stage-boot-loader. It reads the 256 words from the data ram (which is initialized) and copies it to the program ram using the cpu itself.
<emeb>
they have the same BUS_ADDR74 value 0b0001 listed for both a SPI core and an I2C core.
<tnt>
And then that 256 words is the second stage bootloader which will use the hard-spi IP to populate the rest of the SPRAM with the full app from flash.
<tnt>
Yeah, that doc error is documented , I've seen a comment when implementing it.
<emeb>
ok
<tnt>
btw, I also connected the LEDDA_IP, it's fun to make the led breathe with no cpu involvement beyong loading registers.
<emeb>
hah, cute.
<emeb>
I've not played with that.
rohitksingh has quit [Ping timeout: 246 seconds]
dingwat has left ##openfpga [##openfpga]
<emeb>
w00t - getting activity on spi cs & sclk.
mietek has joined ##openfpga
<emeb>
cs looks like it needs a pullup though - goes hi-z when inactive.
<emeb>
must have misunderstood the MCSNO0 / MCSNOE0 hookups
<mietek>
why is level shifting such a difficult topic?
<mietek>
it’s supposedly designed to deal with open-collector
<emeb>
mietek: those are useful mostly for open-drain signals like I2C
<mietek>
yes, i need to deal with an open-collector bus signal
<tnt>
mietek: don't use bidirectional auto-sensing converters.
<mietek>
why?
<mietek>
what’s wrong with a product that seems to be made precisely for this use case?
<tnt>
the metric shit-ton of small prints in the datasheet that if you misread or misunderstand one will screw up your application.
<tnt>
dedicated i2c converters being the 'exception' (but they're often not general purpose bidir converters, they're _meant_ for i2c and nothing else).
<mietek>
okay. so do you suggest a direction-controlled level shifter?
<tnt>
and even then you better be careful.
<emeb>
if you know the direction then it's a better sol'n
<tnt>
ok, so open collector is actually the easy case.
<tnt>
the circuit in the sparkfun board should work fine.
<tnt>
but for instance a TXS0108 would definitely not because somewhere in there it says "oh yeah if you have any pull ups on the line, this isn't going to work".
<tnt>
(oh, I might have that chip confused though)
<mietek>
people say the sparkfun circuit is too slow
<mietek>
ADB is pretty slow
<mietek>
but i don’t know if it’s slow enough
<tnt>
what do you want to connect it to ?
<tnt>
because you might not even need any of this ...
<tnt>
like if it's to connect to a fpga or to a uc, just use two IO. One driving a mosfet if you want to force it low and another IO as input through a divider to 'sense' the current state.
<mietek>
that may seem simpler to you, but i only understand some of the words you used :)
<tnt>
if you look at page 293 of the book you sent, that's actually exactly what they're doing.
<tnt>
you have one of the teensy output connected to a transistor or nmos to pull the line low, that's your "output pin".
<tnt>
And then through a resistor divider, you can sense the current state of the line while ensuring your teensy never sees more then 3v3. That's your "input pin".
<mietek>
the circuit in the book works with 5V signals, right?
<mietek>
i understand there are two output pins, marked ADBO and /ADBO
<Forty-Bot>
hm, I was just modifying this from the example makefile they provide
<Forty-Bot>
ok, so when you call verilator without --exe it compiles some stuff and then archives it
<Forty-Bot>
so how would I run tests?
<tnt>
mietek: no you skip the 1k
<tnt>
mietek: the 470 ohm is the pull-up for the open-drain bus
<ZipCPU>
Forty-Bot: The tutorial discusses that in detail.
<ZipCPU>
By the end of the 3rd lesson, you should be a bit more comfortable. The lessons themselves consist of Verilog + Verilator + SymbiYosys.
<Forty-Bot>
ok, so you compile your testbench and link it against the .a?
<Forty-Bot>
then run that part
<mietek>
tnt: okay, thanks. i see i can use a pair of 1680 ohm and 3240 ohm resistors for the voltage divider. i understand the voltage divider will go between the pull-up and the bus, right?
<ZipCPU>
Forty-Bot: Yes. That's how I do it.
Asu` has joined ##openfpga
<tnt>
mietek: huh .. no ? it'll go from the bus to GND and the midpoint to the teensy. Also given the bus is not that low impedance (470 ohm) you want a diviver much higher, something in the 10k-100k range.
<mietek>
tnt: could an internal pull-up work here?
<tnt>
mietek: no
Asu has quit [Ping timeout: 250 seconds]
<mietek>
tnt: so you’re saying, use something like 17k and 33k resistors for the divider, and what value for a pullup?
<tnt>
470 ohm
<mietek>
thanks. any recommendations for what to read so that i can avoid asking such basic questions in the future?
Cerpin has joined ##openfpga
<tnt>
No idea ... I learned all the basic stuff when I was barely a teen, in the days of electronics magazine by reading up the circuit descriptions of the projects they published each months .... (and then later on a few electronics courses at uni).
<tnt>
I'm not sure if there still are magazines like that.
<tnt>
elektor still exists but not sure about the content.
<mietek>
right
<tnt>
I think I heard good things about "Learning the Art of Electronics"
<mietek>
what should be the wattage of the resistors?
<tnt>
well .. U = R * I and P = U * I and R = 470 ohm, U = 5V so you get P from that
ym has quit [Remote host closed the connection]
<mietek>
i see. thanks again
<tnt>
Just looked at the online preview of that book and it indeeds seems to be very nice and cover a wide range of topic going all the way to verilog as well ...
<mietek>
unrelated: when a desoldering bulb fills up, is it meant to be thrown away, or is there a clever way to empty it?
<mietek>
i found it easier to use than a solder sucker (the big thing)
<tnt>
huh, never saw that before, no idea.
<azonenberg>
i used to use suckers a lot
<azonenberg>
now i use braid for everything
<azonenberg>
works so much better
<tnt>
yeah I use braid and actual desoldering gun for through-hole
<emeb>
mietek: usually the solder in a sucker/bulb is kinda powdery. You should be able to just shake it out.
<mietek>
hmm.
<whitequark>
azonenberg: there is a serious issue with braid
<whitequark>
tearing off the pads if it gets stuck to the pad because of heatsinking
<whitequark>
suckers can't really do this by design
<azonenberg>
whitequark: that's why you don't put any force on the braid
<azonenberg>
hold loosely with tweezers and move super gently
<mietek>
i also use braid, and it does get stuck sometimes
<azonenberg>
yes it gets stuck
<azonenberg>
But as soon as that happens you take corrective action, you don;'t force it
<mietek>
it’s true, i haven’t pulled off any pads with the braid yet
<azonenberg>
I think it's more of a technique issue than a tooling issue
<azonenberg>
i'm not denying it can happen, but i consider that operator error
<mietek>
on the other hand, i like the desoldering bulb for removing larger amounts of solder
<mietek>
which would involve using a large amount of braid
<azonenberg>
also it's very hard to get super planar results with a sucker
<azonenberg>
e.g. for putting a BGA down on top
<mietek>
so, first the bulb, then the braid
<azonenberg>
or even a QFN
<mietek>
i’m mostly reworking old things. so it’s through-hole and sometimes it really doesn’t want to let go without a large amount of added solder
<azonenberg>
ah ok, yeah i do almost 100% SMT these days
<azonenberg>
when possible i don't even use QFP/SOIC/SOP
<azonenberg>
QFN and BGA are my preferred packages
<tnt>
01005 standard passive size too ?
<azonenberg>
tnt: no, lol
<azonenberg>
my default passive is 0402, i freely use 0201 when given a good reason
<azonenberg>
for example in FREESAMPLE an 0201 is a pretty close match to my 50 ohm traces
<azonenberg>
so i dont need to do any plane cutouts to impedance match
<whitequark>
18:36 < azonenberg> whitequark: that's why you don't put any force on the braid
<whitequark>
accidents happen
<azonenberg>
i also am using 0201 for parasitic reasons decoupling some 0.5mm QFNs on the top layer to get super small loop areas
<whitequark>
like, you don't need to want to put force on the braid, your hand can twitch a bit
<whitequark>
and the pad is gone
<azonenberg>
whitequark: maybe your hands are shakier than mine?
<azonenberg>
not a problem i've ever observed
<azonenberg>
Not saying you're wrong, but i havent seen it happen
<whitequark>
azonenberg: clomipramine gives me severe hand tremors, and even without that it happens occasionally
<whitequark>
it'll also become worse with age
<whitequark>
anyway, there's really no replacement to braid for SMT work
<whitequark>
but i wish there was
<whitequark>
cranking up the heat does help to an extent
<whitequark>
but that tends to go very badly on old PCBs as well
<TD-Linux>
yeah I've also taken pads off with braid. it's rare and kinda depends on the pcb construction
<TD-Linux>
suckers are hard to beat for through hole though
<azonenberg>
If you're using cheap boards or excessive heat, pads are more likely to delaminate
<azonenberg>
TD-Linux: yeah i just avoid PTH like the plague these days :p
<whitequark>
azonenberg: i do not have the choice of which boards to use
<whitequark>
when i rework some weird shit from 10 or 20 years ago
<whitequark>
azonenberg: most of the time when i rework BGA
<whitequark>
it's because i don't know the PCB layout and/or the ballout
<TD-Linux>
some sort of jig to hold the braid on both sides to pull it away without peeling action might b nice
<azonenberg>
whitequark: yeah very different set of problems
<azonenberg>
most of my rework is ECOs on buggy brand-new designs
<whitequark>
azonenberg: also you can spend basically inf$ on your designs
<azonenberg>
whitequark: what, and m-labs stuff is cheap?
<whitequark>
your budget on one PCB is more than my yearly PCB budget
<whitequark>
oh, i don't do hardware design for m-labs
<azonenberg>
i've seen the giant fpgas sb0 puts on those things
<Forty-Bot>
ended up just using absiolute paths
<whitequark>
yeah no, those things cost many thousands of dollars
<Forty-Bot>
let verilator handle the -Is
<whitequark>
and work quite badly anyway
<azonenberg>
Lol
<whitequark>
rgmii clock on a non clock capable ball...
<azonenberg>
...
<whitequark>
then a rework that would cause different boards to have non-matching phase
<azonenberg>
Anyway, FREESAMPLE is going to be an expensive board, no doubt about that, but also consider how long i've been working on it
<whitequark>
then some vivado bug that would make it work only when the mmcm is constrained to one specific loc
<whitequark>
and even then needed a lot of brute force
<azonenberg>
The original numerical modeling of the design started in mid November
<whitequark>
doesn't make me work with xilinx tools any more
<azonenberg>
And I probably won't have the board done and ready for tapeout until mid April at the earliest
<azonenberg>
That's five months for one board, so $1K of parts amortized over that is only $200 a month - and that's before you consider that I'll be getting samples from AD for a $200 delay line and probably some other high-dollar parts
<azonenberg>
So it will probably only cost me $600 or so plus the PCB
<azonenberg>
For somebody on a full time tech income $600 amortized over five months is pocket change
zem has quit [Ping timeout: 255 seconds]
zem has joined ##openfpga
m4ssi has joined ##openfpga
<tnt>
daveshah: is the meaning of TMG_xxx explained somewhere ? Like what's TMG_ENDPOINT for instance ? I thought that was 'lookup in the timing.txt file' ...