tecepe has quit [Remote host closed the connection]
digshadow has quit [Ping timeout: 265 seconds]
tecepe has joined ##openfpga
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
doomlord has joined ##openfpga
doomlord has quit [Client Quit]
talsit is now known as talsit_idiot
doomlord has joined ##openfpga
eightdot has quit [Ping timeout: 268 seconds]
eightdot has joined ##openfpga
<cyrozap>
That feel when arm-none-eabi-gcc won't warn you about trying to assign a value to data[7], when you initialized the array with length 7...
<cyrozap>
In case you missed the bug (like I did): I was supposed to assign the value to data[6], which is inside the array, not data[7], which is outside it.
tecepe has quit [Ping timeout: 260 seconds]
<qu1j0t3>
.b 16
digshadow has joined ##openfpga
digshadow1 has joined ##openfpga
digshadow has quit [Ping timeout: 268 seconds]
<azonenberg>
cyrozap: cppcheck
<azonenberg>
if you're not using it as part of every build, you should
<digshadow1>
that archive
<cyrozap>
azonenberg: Does that work on embedded C?
<azonenberg>
cyrozap: it's a generic static analyzer
<azonenberg>
should work on any legal C, although if you are using custom libc functions for memory management, file storage, etc some of the resource-leak checks won't work (not sure how easy it is to extend it to do that kind of stuff)
<azonenberg>
as in, it only knows how to find leaks using malloc, fopen, etc
<cyrozap>
Ah, interesting. It managed to detect the bug I posted about.
<whitequark>
does cppcheck actually work on c?
<azonenberg>
Yes
<whitequark>
c is not a subset of c++...
<whitequark>
ok
<azonenberg>
whitequark: it's not?
<whitequark>
nope
<azonenberg>
there's only a handful of situations i can thin kof
<whitequark>
"new" is a valid C identifier etc
<azonenberg>
like "auto" in c++ 11 not being the same as in older c/c++ revs
<whitequark>
VLAs
<azonenberg>
VLA?
<whitequark>
variable length array
<azonenberg>
hmm, that might be an edge case it doesnt handle right
<whitequark>
char c[some_other_var];
<whitequark>
that got gutted from C++ and remarkably even C++11
<azonenberg>
but still in c99?
<whitequark>
yep, required
<whitequark>
er
<whitequark>
remarkably even C11*
<azonenberg>
oh wait
<whitequark>
in C11 it's permitted but optional
<azonenberg>
ah ok
<azonenberg>
and i have not tried running cppcheck on a c file with "new" as a variable name
<whitequark>
theres a lot of keywords in C++
<whitequark>
all of the new ones are valid C idents
<whitequark>
bool, template, ...
<azonenberg>
yeah i know
<azonenberg>
good point there
<azonenberg>
My guess is, it can figure out from context
<azonenberg>
in general, though, all of the C I write is indeed a strict subset of C++
<azonenberg>
even if i am writing it as embedded C etc i avoid c++ identifiers in case you ever need to build it under a c++ compiler
<azonenberg>
as a result, i've never tested how cppcheck behaves in that corner
<azonenberg>
What i can say is, it has never failed to parse any of the embedded C i've thrown it
<whitequark>
ok
<azonenberg>
This includes client code (I use cppcheck as the first step in any C/C++ code review @ $WORK to find low-hanging fruit)
landley__ has joined ##openfpga
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<whitequark>
azonenberg: opinion on naming of passives?
<whitequark>
SMD passives that is
<whitequark>
there are both metric and imperial, and I think we should support both
<azonenberg>
whitequark: in my personal kicad library, to date
<azonenberg>
I did stuff like EIA_0603_blah
<azonenberg>
to clearly mark imperial sizes
<rqou>
as an ugly american, i've only seen them referred to by imperial sizes :P
<whitequark>
does "EIA" signify "imperial" enough in your opinion?
<pcbhdl-github>
pcbhdl/master 7482ab1 whitequark: Add footprint support to Eagle post-processor.
talsit_idiot is now known as talsit
<rqou>
did you leave your computer unlocked or something talsit? :P
doomlord has joined ##openfpga
<talsit>
rqou: because of the "idiot"?
<talsit>
no, i was actually an idiot for a while
<rqou>
yeah :P
digshadow1 has quit [Ping timeout: 265 seconds]
digshadow has joined ##openfpga
digshadow1 has joined ##openfpga
digshadow has quit [Ping timeout: 260 seconds]
digshadow1 has quit [Ping timeout: 252 seconds]
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
digshadow has joined ##openfpga
tecepe has joined ##openfpga
clifford has quit [Ping timeout: 265 seconds]
clifford has joined ##openfpga
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
digshadow has quit [Quit: Leaving.]
carl0s has joined ##openfpga
digshadow has joined ##openfpga
digshadow has left ##openfpga [##openfpga]
amclain has quit [Quit: Leaving]
carl0s has quit [Quit: Leaving]
<cr1901_modern>
whitequark: So yea, be back in 1 hour turned into "I got sick was awake for 2 hours of the past 15". Should we move the v2pcb wiki stuff to your repo. I want to put the package dimensions and their sources all in a central location.
<whitequark>
ack
<cr1901_modern>
Should we move the v2pcb wiki stuff to your repo. <--- that should be a question
<cr1901_modern>
or should I just make pages there?
<azonenberg>
cr1901_modern, whitequark: if you do migrate to the other repo let me know when you're done
<whitequark>
just make pages for your findings
<azonenberg>
so i can purge the current one to avoid confusion
<whitequark>
ah
<whitequark>
hm
<azonenberg>
i dont want two independent non-forked repos for one project
<rqou>
hm other repo?
<azonenberg>
one should be authoritative and the other deleted
<cr1901_modern>
^This was my concern
<azonenberg>
rqou: my v2pcb and whitequark's pcbhdl
<azonenberg>
are the same project
<azonenberg>
but not linked in any way
<whitequark>
rqou: github.com/pcbhdl/pcbhdl
<azonenberg>
right now he has code and i have wiki
<azonenberg>
the two need to get consolidated
<rqou>
ah i see
<azonenberg>
i'm about to go to sleep, i dont have strong feelings one way or the other besides "we cant keep two repos"
<azonenberg>
so i'll let you guys hash it out and get back to me in the morning
<whitequark>
azonenberg: btw i made you an owner of the org
<whitequark>
but you haven't accepted that yet
<rqou>
i'm going to go to bed too; really need to improvve my sleep schedule
<azonenberg>
yeah i know been very busy
<whitequark>
ah ack
<azonenberg>
barely had a chance to go through personal mail
<rqou>
shouldn't be on HK time in the US :P
<azonenberg>
rqou: lol
<azonenberg>
i had a dentist appt in the morning
<azonenberg>
then went to work, worked late to make up th ehours lost from the doc
<azonenberg>
grocery shopping, then coding on antikernel infrasrtucture for a little bit
<cr1901_modern>
My sleep schedule current is approx 6PM to 1AM. Not exceptionally ideal.
<azonenberg>
Mine right now is about 2am - 7am
<azonenberg>
so... worse?
<rqou>
i'm 2am to 12pm
<rqou>
even worse
<cr1901_modern>
I'd rather have yours azonenberg, tbh
<azonenberg>
rqou: i wish icould get away with that
<azonenberg>
i need >5 hours of sleep
<rqou>
funemployed :P
<azonenberg>
problem is, i have to get up early for work
<azonenberg>
and if i work until i'm tired and am at a stopping point in my projects
<rqou>
gonna steal some of my roommate's melatonin :P
<azonenberg>
its only 5-6 hours before the next morning :p
* azonenberg
goes off to bed for real now
Bike has quit [Quit: no such]
<cr1901_modern>
I like pcbhdl as its own group for aesthetics reasons. All things being equal, move the wiki stuff to pcbhdl (and v2pcb could be the name of the verilog frontend or something).
<pcbhdl-github>
pcbhdl/master 3a791b5 whitequark: Use __all__ in libraries.
<cr1901_modern>
whitequark: Just to make certain: The dimensions of surface mount parts are given in their names (i.e. 0402 Imperial = 1.0x0.5mm) I'm assuming you want extra information just as tolerances. I'm looking for the JEDEC/EIA standard for this now.
<cr1901_modern>
DIPs are spaced nominally 0.1in pins apart in a row, and the two rows are either 0.3, 0.4, 0.6, or 0.9in apart nominally
<whitequark>
how the *fuck* do you calculate the E series from first principles?
<whitequark>
ah apparently you don't
landley__ has quit [Ping timeout: 250 seconds]
biot has quit [Ping timeout: 260 seconds]
biot has joined ##openfpga
cyrozap has quit [Ping timeout: 260 seconds]
whitequark has quit [Ping timeout: 260 seconds]
whitequark has joined ##openfpga
cyrozap has joined ##openfpga
marcus_c has joined ##openfpga
<cr1901_modern>
you mean the weird resistor values that are default?
<cr1901_modern>
Multiply by 1.05 again to get the value of the next resistor, 1.21. Repeat until you get to the next decade, which "conveniently" ends up being exactly 10
<cr1901_modern>
Starting from 1 multiply by 1.05. This is the maximum value a 5% tolerance resistor can take w/o being thrown into the scrap heap. It is also the minimum value the next resistor value can take w/o being thrown away.
<cr1901_modern>
erm, not 1.21, I'm looking at the Wikipedia article XD
<marcus_c>
And it becomes 10.4 (after 24 resistors), not exactly 10. :-)
<whitequark>
yeah it turns out you just look at IEC60063 and copy the numbers from there
<cr1901_modern>
marcus_c: Oh, my mistake. Was too good to be true XD
<marcus_c>
cr1901_modern: Well, it was true within a 5% tolerance. :-D
<marcus_c>
The correct value for the 48:th root of 10 is 1.04913972913631, which is pretty close to 1.05.
<cr1901_modern>
whitequark: Re: parts, I assume you wanted maximum manufacturing tolerances as well? Otherwise the SMT dimensions are given in the part type.
<cr1901_modern>
Actually finding information from an authoritative source (if there is one) isn't proving fruitful.
landley__ has joined ##openfpga
<whitequark>
that's actually not quite the case...
<whitequark>
1008 is 0.098in x 0.079in...
<cr1901_modern>
mm to in conversion I believe
<cr1901_modern>
wait
<cr1901_modern>
whitequark: I'm sorry, you are correct.
<cr1901_modern>
I will write them down from the wiki article and look for more autoritative sources
<cr1901_modern>
the metric package numbers are exact
<cr1901_modern>
according to the article
<marcus_c>
And 0.098in x 0.079in is exactly 2.5mm x 2mm. I guess some people just like seeing mil numbers better.