<lekernel>
the usual raspberry pi and makerbot nonsense?
<lekernel>
there's even an event titled "OzBerryPi.org", lol
wej has quit [Ping timeout: 248 seconds]
<hellekin>
lekernel: there was a heated discussion on FLISOL mailing-list these days (Latin-American Festival of Installation of Free Software) because people ususally install Ubuntu, and the FSF considers Ubuntu to have derived away from the ideals of free software
<hellekin>
and it's using spyware. The first reaction of the coordinators of the list was to deny, and reject that issue, and tell the people from the FSF to stop trying to divide the community
<hellekin>
after someheated dicussion, they came to acknowledge the issue and proposed to inform all users about this issue, because it's a fundamental issue for software freedom.
<hellekin>
I think the same goes for an event called "hardware freedom day"
<hellekin>
if real hardware freedom don't get involved, it will become like "natural cow milk" in Argentina: inexistent, because by law, they need to add all sorts of nutriments to struggle against mal-nourishment (?)
<wpwrak>
"american scientists report:traces of evilness found in ubuntu" :)
<hellekin>
hardware freedom promoters I mean
wej has joined #qi-hardware
<hellekin>
the milk issue in Argentina avoids fixing the poverty issue by installing an industrial-chemical monopoly over its distribution. Great.
<hellekin>
If you don't want people to hear "free hardware" and think "arduino", you should ponder that lekernel
jekhor has quit [Ping timeout: 272 seconds]
<lindi->
I don't think there is a clear concensus on what free hardware means
<hellekin>
in propaganda terms, it's called "spinning the truth"
<hellekin>
lindi-: the CERN's OHL mailing-list is a great place to discuss it.
<hellekin>
lindi-: what's your take?
<lindi->
hellekin: I'm afraid I don't have the knowledge to say much about it
<lekernel>
arduino isn't that bad, even if it's kinda boring at times. at least, the people behind the project act with some good faith for oshw (and have made some progress in that direction, eg using a free software usb stack instead of a ftdi-chip)
<lindi->
hellekin: I'd much rather communicate as many facts about some piece of hardware as possible and leave it to the user to decide if those are ok at this stage
<lekernel>
and it has brought a lot of non-engineers into electronics
<hellekin>
lindi-: so you already have an opinion :)
<lekernel>
rpi? there isn't the faintest link to oshw. absolutely everything is proprietary, even some software. it resonates in the oshw community only because hackers are cheap bastards.
<wpwrak>
death to ftdi ! now there's a cause i can fully sympathize with
<hellekin>
lekernel: I'm glad you got more flexible about arduino. I remember it wasn't always the case :)
<hellekin>
wpwrak: "D
<lindi->
when I started you couldn't search the arduino schematics without non-free eagle program
<wpwrak>
lekernel: you're still on altium, aren't you ? :)
<lekernel>
well it's not like there's much to see there anyway, any serious EE can design an arduino in a couple hours
<lekernel>
wpwrak, yes, I even have a dedicated windows xp machine for that purpose. my priority is shipping stuff out, not wasting my time with relatively dysfunctional software.
<wpwrak>
for beginners, even trivial details can be an issue. so it's nice if they can find something familiar
<whitequark>
wpwrak: it is one of things you really need just to take with a face value.
<wpwrak>
(arduino design) besides, sometimes it really helps with low-level programming if you know what exactly they did in the circuit
<whitequark>
to quote their homepage: Arduino is an open-source electronics prototyping platform based on flexible, easy-to-use hardware and software. It's intended for artists, designers, hobbyists, and anyone interested in creating interactive objects or environments.
<whitequark>
it is an *ideal* solution for all those groups of people
<whitequark>
sure, it has nothing to do with embedded development. no one claimed it has!
<hellekin>
sorry I didn't want to spark an arduino discussion :]
<wpwrak>
lekernel: naw, kicad ain't dysfunctional. the workflow is pretty smooth these days, at least for simpler boards. haven't done multilayer so far.
<wpwrak>
whitequark: yeah, i think it's a friendly first step for people who otherwise wouldn't think they can do something with such electronics
<lekernel>
that's not what I heard at CERN, where they have tried to make such multilayer boards...
<whitequark>
interestingly, it's exactly the same about Go. some people (a lot, actually) talk about it as a C killer. meh. Pike and Thompson design it, to quote their own words, "we did it because we wanted to solve the type of tasks we commonly have at Google easier"
rz2k has quit []
<whitequark>
that explains *everything* about Go. it is also perfectly engineered for that goal.
Caly__ has joined #qi-hardware
<whitequark>
from quirks of compiler and stdlib to almost nonexistent error handling in the language.
<whitequark>
wpwrak: what's up with ftdi?
jekhor has joined #qi-hardware
<lekernel>
wpwrak, and I already told you I have not used kicad for the video mixer board, because I want to re-use the (validated) footprints when integrating the parts on a M1r4 derivative
<lekernel>
time spent re-doing the footprints in altium + risk of a respin of a 6-layer PCB due to a messed-up footprint = kicad was not the right option
<wpwrak>
lekernel: ah, i see. yes, for kicad you'd have to move the whole design.
Calyp_ has quit [Ping timeout: 252 seconds]
<wpwrak>
lekernel: we should have most of the footprints. many of them unverified, though. but no risk no fun ;-)
<wpwrak>
whitequark: ftdi has extremely incomplete documentation
jekhor has quit [Ping timeout: 245 seconds]
guanucoluis has quit [Read error: Connection reset by peer]
guanucoluis1 has joined #qi-hardware
biot has quit [Ping timeout: 246 seconds]
<Fallenou>
I heard about a Milkymist SoC related work on USB device FPGA core, is it dead?
<Fallenou>
is it using navre with a custom "device" firmware?
biot has joined #qi-hardware
<lekernel>
yes, and iirc some minor mods to the usb core too
<lekernel>
the 'phy' part
<lekernel>
we're also running navre at 72MHz to make it able to answer the host in a timely fashion, too
<Fallenou>
yes I saw that for the host part
<Fallenou>
I mean, the frequency was changed to 75 MHz for the host design as well, wasn't it ?
<Fallenou>
72*
<Fallenou>
who's working/was working on the device part?
<lekernel>
Michael Walle
<lekernel>
yes, it didn't cause issues for the host part (actually it seemed to help with a couple of , so we just use 72
<lekernel>
yes, it didn't cause issues for the host part (actually it seemed to help with a couple of issues), so we just use 72MHz everywhere
<lekernel>
oops
<Fallenou>
ok :)
<whitequark>
72mhz, huh
<whitequark>
12mhz * 6?
<kyak>
i just came up with "extern const volatile unsigned short int test;", which compiles fine :) no point, i just find it funny :)
<whitequark>
>const volatile
megha has joined #qi-hardware
baba has quit [Ping timeout: 272 seconds]
<whitequark>
well, extern const volatile might make any sense... I dunno
<larsc>
a readonly object which might change it's value without you modifing it
MistahDarcy has quit [Ping timeout: 246 seconds]
<kyak>
i think "const" implies that the value is not being changed by anyone
<kyak>
otherwise it should be "ro" or somthing
<larsc>
no, it implies that you are not going to change the value
<whitequark>
yep
<whitequark>
see also const casting
<whitequark>
ie printf won't modify your format string so it's const in printf
<whitequark>
but it's not necessarily const when you pass it to printf
<larsc>
const int *i; int j; i = &j; j = 10; printf("%d\n", i); -> "10"
<whitequark>
(please, for the love of everything good on this planet, do not, ever, write code which uses dynamic format strings.)
<lekernel>
whitequark, yes, 12*6Mhz
<kyak>
larsc: this is not defined in the standard, as far as i concern
<larsc>
speaking of format strings, I think next time I'll just sell my zero days on the blackmarket. nobody at security@kernel.org cared
<larsc>
kyak: what is not defined?
<kyak>
so whenever you modify the const, the result is undefined
<lekernel>
so no asynchronous clock domain transfers
<whitequark>
kyak: volatiles is, generally, not well defined in the standard
<whitequark>
it's basically a message to compiler to "not touch the variable". it does not translate to any particular memory ordering, which is actually a problem.
<kyak>
"The result is implementation-defined if an attempt is made to change a const.", from K&R
<whitequark>
and every compiler has a different meaning of "not touch"
<whitequark>
kyak: "implementation-defined".
<whitequark>
the actual reason for that wording is that on some systems constant values will go to .rodata and generally to read-only memory
<whitequark>
so oif you'll try to change it, the system will freak out.
<kyak>
that's for sure. Because it is not defined by standard
<whitequark>
but you still can cast it *to* const, and change the underlying value
<whitequark>
I guess the compiler won't be able to change two non-consecutive loads into one if it can't prove that this variable doesn't alias anything
<whitequark>
or maybe not, I didn't check the standard
<larsc>
e.g. if a function agrgument is const this tells the caller that the value it passes in won't be changed from within the function
<larsc>
but not the other way around
<larsc>
the function still has to assume that the value way change
<larsc>
may
<larsc>
it's the same as if you add a comment to the function "This function won't change the value of argument X"
<kyak>
well, this makes the whole point of "const" kida. useless?
<larsc>
why?
<kyak>
it should be enforced, otherwise it's not better than a comment as you said
<larsc>
as I said any sane code won't cast the const away
<larsc>
because as you said the result is undefined
guanucoluis1 has quit [Ping timeout: 240 seconds]
<larsc>
e.g. if you have a const declaration the value will be put in a .ro section
<larsc>
and on architectures which support it the .ro section is not writable
<kyak>
ok, this makes sense
<kyak>
in order for "const" to really work properly, the machine must support the read-only memory
<kyak>
still this won't quite work for function arguments
<larsc>
because "a" is in the .ro section
<kyak>
even for architectures that have .ro
<larsc>
no
<larsc>
ups
<kyak>
i understand it's double negative? :)
<larsc>
if you have const pointer parameter this is kind of a contract between the caller and the callee that the callee wont write to the location of the pointer
<larsc>
its part of the language so tools like the compiler can complain if this contract is broken
<kyak>
larsc: does the second example work on amd64?
<larsc>
which second example?
<kyak>
the constTest.c
<larsc>
yes, because a is on the stack
<larsc>
'a'
<kyak>
ah!
<kyak>
yep, it segfaults when it's not on the stack
<larsc>
if you do a objdump you'll see that it is in the .ro.data section
<kyak>
yea, it is.
<kyak>
anyway, what was funny for me is the number of qualifiers i could use.. The "const volatile" just popped in the way
<kyak>
gotta go now
<larsc>
there is even more
<larsc>
restrict const volatile unsigned long long * const test;
kuribas has joined #qi-hardware
<whitequark>
unsigned long long int?..
<larsc>
maybe even that
<whitequark>
whoever thought that integers must be called by names, as opposed to bit widths, must be shot
<whitequark>
i8, i16, i32, and maybe `word`
<whitequark>
oh and unsigned variants. that's all you need.
<whitequark>
also, love.
<larsc>
:)
<kyak>
probably he who thought that integer size is machine-specific is already dead
<larsc>
the length of long and short and int and char are up to the architecture
<larsc>
I think the only restriction is char <= short <= int <= long
<kyak>
it's just short <= int <= long :)
<kyak>
"The intent is that short and long should provide different lengths of integers where practical; int will
<kyak>
32 bits. Each compiler is free to choose appropriate sizes for its own hardware, subject only to the the
<kyak>
restriction that shorts and ints are at least 16 bits, longs are at least 32 bits, and short is no longer
<kyak>
normally be the natural size for a particular machine. short is often 16 bits long, and int either 16 or
<kyak>
than int, which is no longer than long."
<whitequark>
yeah
<whitequark>
and now we have to deal with code which cannot deal with 32-bit chars
<whitequark>
and the whole ILP64 insanity
<larsc>
whitequark: you think 32-bit chars are bad, try 11-bit wide chars ;)
<whitequark>
thank you, Dennis :/
<whitequark>
larsc: hm
<whitequark>
where was that
<larsc>
nowhere I guess, but I think it would be legal for a C compiler to implement it that way
<larsc>
by the standard
<whitequark>
yeah, I don't think the standard requiers byte size to be 8 bit
<whitequark>
or size of any type to be a multiple of 8 bit
<whitequark>
I even think that most of LLVM does not depend on byte size being 8 bit...
<whitequark>
(tbaa parts do, and some intrinsics also)
<whitequark>
this discussion appears on the ML and irc channel with surprising regularity.
<whitequark>
also, trigraphs
<larsc>
are there people who want support for 11 bit bytes in llvm?
<lindi->
larsc: what does that mean?
<lindi->
larsc: do you mean clang here?
<lindi->
larsc: since llvm already does have "i11" type
<whitequark>
lindi-: no, that's not what I'm talking about
<larsc>
I was referring to "21:16 < whitequark> this discussion appears on the ML and irc channel with surprising regularity."
<whitequark>
see, llvm in some places assumes that the unit of addressing is 8-bit-wide
<lindi->
but by "the standard" you mean C standard?
<whitequark>
not in much places, but it does, particularly in stuff which works with pointers and aggregates
<larsc>
lindi-: think the point is that it would be a valid restriction for clang, but it also is in llvm
<whitequark>
"Winning entries are awarded with a category, such as "Worst Abuse of the C preprocessor" or "Most Erratic Behavior", and then announced on the official IOCCC website. "
<whitequark>
I think I can award these to real-world software
<lekernel>
you can have a look at the boost headers if you need inspiration for the former
<lekernel>
eg their "preprocessor for loop" is one of my favorites