<zino>
Printers are are electronics and mechanical objects combined to cause the maximum possibility of failure and suffering for the person wanting to print.
<lain>
^
<azonenberg>
And software
<azonenberg>
dont forget the software
<azonenberg>
things like "buy moar ink here" links popping up
* azonenberg
looks at HP
digshadow has quit [Quit: Leaving.]
<lain>
it's because printers are a sin against computing - computers replace dead trees, printers upset the balance.
digshadow has joined ##openfpga
<azonenberg>
Nature abhors a... printer?
<azonenberg>
:p
<lain>
:D
<zino>
It is known.
<rqou>
network/wifi printers are the worst
<jn__>
the firmware running on printers is also a little weird, as far a i've seen it
<rqou>
why can't somebody just make a "stupid mode" print server that just maps USB EPs<->sockets?
<jn__>
rqou: the USB/wifi/network stack in my dead epson printer is so weird
<qu1j0t3>
Because printing is required to be very hard
<lain>
because complexity is the enemy of security
kuldeep has quit [Read error: Connection reset by peer]
kuldeep has joined ##openfpga
<pie__>
cant get loot from secure ones though :C
<pie__>
by the way, how long till internet of smartcards?
Bike has quit [Quit: leaving]
kuldeep has quit [Ping timeout: 255 seconds]
kuldeep has joined ##openfpga
m_t has joined ##openfpga
<eduardo__>
azonenberg: I did a youtube video about inkjet printers (mainly teared one apart). Got 300k views. Title: "inkjet printers are criminal". People seem to be upset :-)
kuldeep has quit [Read error: Connection reset by peer]
kuldeep has joined ##openfpga
kuldeep_ has joined ##openfpga
kuldeep has quit [Read error: Connection reset by peer]
kuldeep_ has quit [Read error: Connection reset by peer]
<Tenacious-Techhu>
Any Mac IceStorm users in the house?
ZipCPU|Laptop_ has joined ##openfpga
ZipCPU|Laptop_ has quit [Remote host closed the connection]
<rqou>
somebody at 33c3 was using macos
<rqou>
afaik it should work just fine
<rqou>
other than potential issues with drivers
pie_ has quit [Ping timeout: 248 seconds]
<Tenacious-Techhu>
33c3?
<Tenacious-Techhu>
rqou, I was wondering if the instructions for using “brew” found on the Apio page could be ignored if you just use the installer straight from FTDI.
<rqou>
i know nothing about brew or mac ftdi driverws
<rqou>
other than i hated using them :P
<Tenacious-Techhu>
I understand and respect what “brew” is trying to do, but I’ve been down that road with macports and fink before, and not enjoyed the headaches required to unistall everything properly.
<Tenacious-Techhu>
I’d rather not install third party software just for the sake of installing third party software. :P
<nats`>
maybe use a VM with a linux
<Tenacious-Techhu>
nats`, not really what I was going for; I suspect they’re asking us to use brew to install something that could be easily downloaded from the manufacturer’s website as an installer...
<Tenacious-Techhu>
In short, the instructions are too “Linux”y to be any good to Mac users in general.
<rqou>
my experience was that every time i chose one of macports/brew/fink/whatever i would find a package that wasn't available
<rqou>
and then it would ask me to switch to one of the other ones
<rqou>
and then i gave up trying to do dev on mac :P
DocScrutinizer05 has quit [Remote host closed the connection]
<rqou>
idk what instructions you are using but iirc you only need the xcode command line tools if you don't care about programming a real board
<Tenacious-Techhu>
Development on Mac is fine, so long as you stick to actual development Apps, and not piddling little projects that don’t know what an Application Bundle is.
<nats`>
that don’t know what an Application Bundle is. <= ...
<nats`>
you can package it if you want
<nats`>
I guess people wil be glad to have help on that
<nats`>
packaging for proprietary OS is always a pain in the ass
<rqou>
hmm iirc somebody from that project showed up at 33c3 but other than that i've never used it
<rqou>
i would say "ask Edmund" but he unfortunately doesn't really use irc
<jn__>
eduardo_: ^
<rqou>
anyways, ftdi driver fuckery is a big reason i stopped using macos
<rqou>
is libftdi the proprietary userspace or the foss userspace?
<rqou>
ah it's the libusb one
<rqou>
Tenacious-Techhu: you can probably build libftdi without brew (using only the xcode tools)
<rqou>
offtopic: do i still need to pay apple to get a kext signing cert?
<Tenacious-Techhu>
rqou, isn’t the whole point of that driver to use FTDI’s chips? Isn’t their driver better by definition in this regard?
<rqou>
every ftdi driver has a different set of bugs :P
<rqou>
there's also like 5 of them
<rqou>
let's see...
<Tenacious-Techhu>
rqou, it depends; do you want your kext to work with Darwin, or to work with Mac OS?
<rqou>
for a real mac os kext
<Tenacious-Techhu>
Probably yes, but that’s a computer security matter sort of thing; you can still give users instructions on how to install it without the cert.
<Tenacious-Techhu>
Signed kexts are for legitimate companies releasing legitimate products, I think.
<Tenacious-Techhu>
So the cost has more to do with Apple spending the time to recognize you as a legitimate source of kexts.
<Tenacious-Techhu>
I have had no problems with the FTDI-supplied driver. I see no reason why that shouldn’t work, but if there’s a good reason it shouldn’t, I wouldn’t mind knowing.
<rqou>
iirc on mac os there are 3 kernel drivers: the apple one, the ftdi one, and the not-really-a-driver raw usb mode (via iokit or whatever)
<rqou>
and iirc the apple one was the buggiest
<rqou>
the ftdi one works great in serial port mode
<Tenacious-Techhu>
If the Arduino project can use the FTDI-supplied driver, I see no reason why this thing can’t.
DocScrutinizer05 has joined ##openfpga
<rqou>
but on the userspace side there's a split between the proprietary userspace and various open-source ones that use raw usb
<Tenacious-Techhu>
Any FTDI driver made by Apple has to be developed with proper documentation and support from FTDI, which they may have felt too lazy to do.
<rqou>
afaik arduino works in serial port mode and doesn't try to do anything fancy
<Tenacious-Techhu>
FTDI, I mean.
<rqou>
so afaik arduino works with either the apple or ftdi proprietary driver
<Tenacious-Techhu>
I see no reason why the FTDI supplied driver shouldn’t be complete; it’s their chip, after all.
<nats`>
if you think manufacturer of think do the best driver for their own chip you're wrong :D
<nats`>
their fucking driver are a mess
<nats`>
and I have less trouble with libusb one
<rqou>
iirc the ftdi driver and the foss driver were just buggy differently :P
<rqou>
anyways, the various fpga programming thingies use various advanced bitbang/mpsse modes of the ftdi chip rather than serial port mode
<rqou>
and afaik this can be done with either the ftdi proprietary userspace talking to the ftdi proprietary kernel driver
<rqou>
or a foss libusb userspace talking to raw iokit or whatever
<rqou>
i don't think apple's ftdi driver works with any of them
<rqou>
although on windows there might have been a foss userspace talking to the proprietary driver
<Tenacious-Techhu>
So it shouldn’t make a difference whether you’re using the Open-Source one or the FTDI-supplied one?
<rqou>
this whole thing is a mess :P
<rqou>
libftdi isn't provided by FTDI
<Tenacious-Techhu>
Bah.
<rqou>
afaik apio wants to use libftdi, which is the foss userspace talking to iokit
<rqou>
so it asks you to unload both the apple and ftdi kexts
<rqou>
ftdi's userspace is named something like libftd2xx
<Tenacious-Techhu>
Would that mean that, while I’m working with Apio, I wouldn’t be able to use other stuff that needed the legitimate FTDI-supplied driver?
<rqou>
that's what it looks like
<rqou>
you can probably make a "codeless kext" or whatever to block the ftdi driver only for the fpga boards
<rqou>
btw this is all much more seamless on linux
<rqou>
the linux kernel usb stack has a "kick out kernel driver" command
<Tenacious-Techhu>
Well, of course it would be; this was a project designed by Linux geeks primarily for Linux geeks.
<Tenacious-Techhu>
Such Linux geeks need to learn proper cross-platform design.
<rqou>
driver/kernel crap is inherently platform-dependant
<jn__>
iceprog uses libftdi, which (on linux) uses libusb, which afaik also works on MacOSX
<Tenacious-Techhu>
Yes, but proper cross-platform design relegates that to cross-platform libraries that handle that platform-specific stuff for the developer.
<rqou>
except you have to unload the serial-port-mode kext on macos
<rqou>
same on windows
<rqou>
Tenacious-Techhu: that's what libftdi tries to be
<Tenacious-Techhu>
No, it doesn’t; instead of being an interface to the existing libraries, it tries to stampede over the existing libraries.
<rqou>
ftdi is partially to blame with their buggy chip with a bajillion different modes
manderbrot has joined ##openfpga
<rqou>
idk if the macos driver even has "d2xx" (non-serial-port mode) support
<rqou>
the linux driver definitely doesn't
<nats`>
Tenacious-Techhu if you want to write a version using real ftdi driver you can
<rqou>
on windows iirc there's a foss userspace to talk to the ftdi proprietary kernel driver
<rqou>
my personal opinion is to stop using ftdi :P
<nats`>
if I could I would
<nats`>
+10
<rqou>
one of my projects is to program a cheap cortex-m0 firmware with all the ftdi features but fewer bugs and stupid driver problems
<rqou>
e.g. by using usb-acm for both bitbang and serial channels
<rqou>
no driver fuckery required
<Tenacious-Techhu>
Maybe so, rqou, but I’m not about to use brew just to do that. :P
<jn__>
rqou: that's where all the ftdi clones come from! ;)
<rqou>
no, i won't be using the ftdi vid/pid
<rqou>
:P
<rqou>
also some cortex m0s are cheaper than the ftdi asic
<Tenacious-Techhu>
rqou, that’s a better argument for FPGA dev-board makers to stop using FTDI than what driver to use. :P
<rqou>
but in conclusion for Tenacious-Techhu: given the current state of software/effort, you're screwed :P
<rqou>
sorry
<Tenacious-Techhu>
How so?
<rqou>
as far as i can tell, there is no convenient way to get the ice40 programming tools to work on macos side-by-side with other ftdi devices
<rqou>
and none of the dependencies are packaged "properly" for macos
<rqou>
lol according to FTDI's own AN134 the proprietary userspace on macos has the exact same problem
<rqou>
it also requires unloading apple's kext
<Tenacious-Techhu>
Ew.
<rqou>
so only on windows do you not need to fuck around with kernel drivers
<rqou>
also apparently on macos installing the ftdi proprietary userspace involves just dumping a dylib into /usr/local/lib
<rqou>
i wonder how well that works with the weird rootless thing?
<rqou>
AN134 also suggests that you can reprogram the usb pid
<rqou>
so the serial port drivers won't claim the device
<rqou>
but then idk if apio or the icestorm tools will detect the new pid
<nats`>
that's what they used at some point to brick fake ftdi
<nats`>
reprogramming them to 0:0
<rqou>
yeah i know that
<rqou>
hilariously enough linux doesn't give a shit if your vid/pid is 0/0
<rqou>
:P
<nats`>
:p
<rqou>
but yeah, even ftdi seems to treat macos as "just a more inconvenient and annoying linux" :P
<jn__>
rqou: well
<jn__>
rqou: they added supprt after the windows FTDI driver bricked clones by setting vid/pid to 0
<jn__>
(they = linux)
<rqou>
afaik you could always use vid=pid=0
<rqou>
just that no kernel driver would load by default
<rqou>
you could always override ftdi_sio's vid/pid to whatever you want
<eduardo_>
During the video she also did a live compile and install . There is not yet a MAC package.
<rqou>
@scanlime uses yosys/icestorm? TIL
<eduardo_>
rqou: yes, there is also an icoBoard heading her direction.
<eduardo_>
her current setup uses an iceStick as a frequency divider. She programmed it with Yosys. Can all be seen in the video.
<rqou>
hmm i don't actually follow @scanlime's work that much
<Tenacious-Techhu>
eduardo_, so far, I’m seeing a nice video on command-line based place & route and synthesis... my questions were more about installation.
<qu1j0t3>
maybe Homebrew formula can be used for Mac packaging
<Tenacious-Techhu>
To me, Homebrew is the problem, not the solution.
<Tenacious-Techhu>
Homebrew doesn’t follow Mac installation conventions.
<Tenacious-Techhu>
Things should be packaged in an Application bundle that can be dragged to the Applications folder for installation, and removed from the Applications folder for uninstallation; things should not follow Unix/Linux expectations on where this or that esoteric file should be installed.
<Tenacious-Techhu>
If additional libraries need to be installed, then a full installer may be necessary.
<eduardo_>
Tenacious-Techhu: I did see the video live two or three weeks ago and made a video out of it. I think she did not specifically explain the installation of Yosys under Mac.
<eduardo_>
Yes, as your describe this is the way it should be done. But noone of us own a Mac or knows how to use a mac or how to do a package.
<eduardo_>
as long as noone steps up with this assets and the will to do it, we are out of luck.
<Tenacious-Techhu>
Bundles are trivially easy; they’re really just fancy folders.
<rqou>
i have a mac
<rqou>
but it's running debian
<rqou>
:P
<Tenacious-Techhu>
You can probably stuff things in a folder and then convert it into a bundle with a handy App; it’s really trivial.
<nats`>
so do it ?
<eduardo_>
ok. I mean macOS
<rqou>
at this point i don't care that much about building a bundle
<rqou>
a bundle doesn't fix the kext stuff
<Tenacious-Techhu>
nats`, in order for me to do it, I would have to install all the nasty Homebrew stuff first, compile it all, and then be at a complete loss as to how to uninstall all the garbage I was required to install along the way to get to that point.
<Tenacious-Techhu>
rqou, no, it doesn’t.
<Tenacious-Techhu>
That is an additional issue that you guys raised successfully that I was not aware of.
<Tenacious-Techhu>
Regardless, Homebrew is not a solution for anything.
<rqou>
in general cli tools don't make too much sense as bundles anyways
<Tenacious-Techhu>
If it’s exclusively command-line stuff that will never see a user interface, it’s fine, because the Unix and Linux devs know what to expect on that front...
<Tenacious-Techhu>
But when it’s something destined for an IDE at some point, a completely different approach is required.
<rqou>
you can probably make apio or the ide thing that uses apio into a bundle
<Tenacious-Techhu>
Right.
<Tenacious-Techhu>
That’s where I was going with that.
<Tenacious-Techhu>
Or maybe an Eclipse thing, or a Netbeans thing, or whatever.
<rqou>
ugh
<rqou>
those are all awful ides
<Tenacious-Techhu>
I don’t assume they are good ideas.
<rqou>
the only reason i use eclipse ever is that building java is even more awful
<Tenacious-Techhu>
Just some sort of cozy IDE App of some kind.
<rqou>
so i use the ide solely to hit the "build" button :P
<Tenacious-Techhu>
Well yes, but that’s why you use your Mac to run Debian.
<pointfree>
Anyway, there's a lot of little command line utilities under ~/.wine/drive_c/Program Files/Cypress/PSoC Creator/3.0/PSoC Creator/bin/
<pointfree>
They run just fine under WINE on Linux.
<pointfree>
It started up with splash screen and IDE ui, but it didn't do much more than that.
<pointfree>
Of particular interest are tools like sjrouter.exe and sjplacer.exe
<pointfree>
Just run some of them with WINE. They will show you the usage.
<pointfree>
I'd like to get these running out of scripts on Linux so we can write/generate Verilog on Linux and do automated RE'ing from Linux with the newfound constraints + Mill's Methods.
<pointfree>
Maybe we can find a MS Windows batch file that ties all these tools together?