<apelete>
can the UBB be used to make a serial output port more easily ?
<larsc>
no
<apelete>
larsc: no ?
<larsc>
well, you can have UART on the UBB, but that's gpio bitbanging based uart
<apelete>
larsc: I don't get it, what do you mean ? what I need is a serial output to debug uboot and the kernel during aerly boot
<apelete>
is that possible using a UBB or not ?
<larsc>
no
<larsc>
(well it is, given you invest enough time to implement it, but not out of the box)
<apelete>
larsc: ok, so txd, rxd and gnd pins accessible under the ben's battery cannot be accessed with a UBB
<larsc>
yes
<apelete>
larsc: thanks a lot. it's a pity though :)
<larsc>
the UBB pins go straigth to the MMC pins of the JZ4740. And since there is no internal pin muxer you can only either use them as GPIOs or MMC.
<hellekin>
viric :P :P
<hellekin>
:)
rz2k has joined #qi-hardware
rz2k has quit [Read error: Connection reset by peer]
LunaVorax has joined #qi-hardware
xiangfu has quit [Ping timeout: 256 seconds]
paroneay` has joined #qi-hardware
uwe__ has joined #qi-hardware
xiangfu has joined #qi-hardware
guanucoluis2 has joined #qi-hardware
paroneayea has quit [*.net *.split]
guanucoluis1 has quit [*.net *.split]
uwe_ has quit [*.net *.split]
paroneay` is now known as paroneayea
paroneayea has quit [Changing host]
paroneayea has joined #qi-hardware
Jay7 has quit [Read error: Connection reset by peer]
Jay7x has joined #qi-hardware
kyak has quit [Ping timeout: 245 seconds]
kyak has joined #qi-hardware
kyak has quit [Changing host]
kyak has joined #qi-hardware
<kristianpaul>
wpwrak: about FPGA Programming for the Masses you pointed latelly, dont you think fpgas may take advantage if the model of running apps on a operating systems change to the app be the operating system, so it can be easilly tied to a hw modelated on a fpga?
<whitequark>
masses can't figure out threads, much less fpgas
<whitequark>
kristianpaul: besides, I think that it makes much more sense to use FPGA as a reconfigurable coprocessor alongside a 'proper' host CPU
<whitequark>
such as parallella with the ARM core powerful enough to run ubuntu and gcc, and the SIMD array. it's the same overall design
mth has joined #qi-hardware
<whitequark>
the article correctly notes that for any particular workload, FPGA is far more power (and cost) efficient
<whitequark>
but what it doesn't note is that for an arbitrary workload, traditional CPU still excel
<kristianpaul>
threads, :)
<larsc>
well, a bit simplified, but still, cpus are good for sequential stuff, fpgas for parallel
<whitequark>
larsc: that's only a part of the story
<kristianpaul>
sure sure, looks a network sw, it have a cpu for the general stuff and ASICs for the custom sw routing fabric
<whitequark>
what will you choose, a real, hardware and fast (way faster than its fpga analogue) ARM core running linux, or a hypothetical ideal-for-linux core on an FPGA?
guanucoluis2 has quit [Ping timeout: 248 seconds]
<whitequark>
and not all parallel workloads can work on an FPGA
<kristianpaul>
larsc: but how to agree in that parallel computing, when at the end talking with the fpga relays on a memory maped sutff not something you could ask your kernel do for you, unless you write a driver ;)
<larsc>
well these days we have stuff like OpenCL to offload tasks for example to the graphics card
<larsc>
the same can be done with reconfigurable fpgas
fire has joined #qi-hardware
<larsc>
the problem though is, you can't really built bitstreams on demand these days
<whitequark>
... yet
xiangfu has quit [Remote host closed the connection]