<DocScrutinizer05>
duh, that been easy. So now the problem turned into "where from you get the protection circuit and tiny plastic parts, and how to mount them to the cell?"
<DocScrutinizer05>
but when the above info didn't give some chinese copycat some ideas, then I dunno
<DocScrutinizer05>
somebody less lazy or more greedy than me start
<DocScrutinizer05>
might start a kickstarted project on it
<Wizzup>
maybe they want you to buy an other half battery
<useretail>
i guess they will anounce new phone very soon
<DocScrutinizer05>
they just announced new tablet, without phone
<DocScrutinizer05>
and when they announce new phone soon and again orphan first phone and their early adopters and most faithful fan community, then I don't see a future for them
<DocScrutinizer05>
they rather should announce "finally feature-complete firmware for Jolla-the-first"
<useretail>
no doubt they will - look how much they raised on kickstarter (or whatever it was)
<DocScrutinizer05>
they will what exactly?
<useretail>
announce new phone
<DocScrutinizer05>
hmm, why should they?
<DocScrutinizer05>
the pledges they raised were for tablet
<useretail>
yes, but i'm sure they are making some profit of these pledges, so that i.e. would allow them hire new staff etc
<useretail>
and by the time they will ship devices, manufacturing costs will go down
rZr has quit [Ping timeout: 250 seconds]
PeperPots_ has quit [Ping timeout: 272 seconds]
PeperPots_ has joined #neo900
* DocScrutinizer05
still ponders seling a 2000 Jolla batteries
<DocScrutinizer05>
but actually meh! too much work, too little to earn
<Oksana>
Do you need a licence to manufacture the batteries? Do you need to have the batteries certified? :-)
<DocScrutinizer05>
no
<DocScrutinizer05>
but you need a rather experienced logistics department to just ship them critters
<DocScrutinizer05>
shipping of LiIon is not exactly simple
<DocScrutinizer05>
getting a 2k protection circuits built is no big thing, and prolly costs ~2 bucks per mini PCB. But who will mount them to the cell, who will produce those tiny silly plastic parts needed
<DocScrutinizer05>
wpwrak: about "wall thickness" of plastic parts: that "hat" over battery protection circuit has a wall thickness of 0.16mm
<DocScrutinizer05>
(battery of Jolla that is)
<DocScrutinizer05>
yeah I know that is a tad thin for milling
Kabouik has joined #neo900
<wpwrak>
is that part milled/cast ? or just cut from a sheet ? you can make sheets pretty thin
<DocScrutinizer05>
the thin walls in that poor snapshot
<DocScrutinizer05>
the distance between the two walls is ~5mm
<wpwrak>
hmm, impressive
<wpwrak>
let's not do that ;-)
<DocScrutinizer05>
I'd not know _how_ to do that ;-)
<wpwrak>
my guess would be: strong molds and lots and lots of pressure ;-)
<DocScrutinizer05>
definitely
<DocScrutinizer05>
and good precisely defined plastic quality
<wpwrak>
oh, when you've reached that level, i'm sure you have plenty of choices. i mean, you've just spent the equivalent of the cost of a new luxury sports car on your molds. what's ten bucks more or less for the kilo of plastic ?
<DocScrutinizer05>
yep
<DocScrutinizer05>
absolutely
<DocScrutinizer05>
anyway that lil 0.01ct part pretty much voids the idea of building jolla spare batteries
<DocScrutinizer05>
I however could think of SAMSUNG already selling the complete battery built to order regarding plastic wrapper printing ("jolla"), and all the plastic and prorttective circuit is standard
<DocScrutinizer05>
or the plastic wrapper is actually what been made by that mysterious NLT electric co.
<DocScrutinizer05>
actually watch that video, at bottom of page
<DocScrutinizer05>
looks amazingly similar to jolla battery
<DocScrutinizer05>
*exactly* the parts I've seen in jolla battery, Up to the dimensions of cutout in PCB center, and PCB contacts: https://www.youtube.com/watch?v=Tu-tLDRhaaI
norly has quit [Quit: Leaving.]
norly has joined #neo900
<DocScrutinizer05>
the only thing that differs is the transparent wrapper (jolla: black with printing "jolla" etc) and the extra label (jolla: wrapper already has printing)
<DocScrutinizer05>
http://jolla.com/stella/ honestly now? That's prolly not the way to make a phone a success story
ds2 has joined #neo900
<wpwrak>
probably an installer for malware that will cripple the droid, forcing the user to switch to sailfish ;-)
<Oksana>
They attempt to use popularity of Angry Birds to make their User-Interface (gestures and such) popular and well-known, so that Android's Angry-Bird-addicted users would consider Sailfish devices familiar. Smooth sailing between Android-with-Stella and Sailfish-with-Android-apps.
<DocScrutinizer05>
lol, TV just tells me that car FM tuned to 94.30MHz kills GPS ;-P
rZr has joined #neo900
wicket64 has quit [Remote host closed the connection]
mvaenskae has quit [Ping timeout: 244 seconds]
rZr has quit [Ping timeout: 272 seconds]
Oxyd76 has quit [Ping timeout: 250 seconds]
che1 has joined #neo900
che1 has quit [Ping timeout: 245 seconds]
che1 has joined #neo900
Oxyd76 has joined #neo900
Oxyd76 has quit [Ping timeout: 250 seconds]
Oxyd76 has joined #neo900
jonwil has quit [Read error: Connection reset by peer]
che1 has quit [Ping timeout: 272 seconds]
Openbot has joined #neo900
<Openbot>
Docscrutinizer05 how ^^^^^^^
Openbot has quit [Client Quit]
<DocScrutinizer05>
how? prolly like:
<DocScrutinizer05>
~1575.42 /(94.30 + 10.7)
<infobot>
15.004
<DocScrutinizer05>
I honestly wonder why *bot always leaves the channel after asking whatever
<DocScrutinizer05>
pretty annoying
<DocScrutinizer05>
~(94.30 + 10.7)*15
<infobot>
1575
Kabouik has joined #neo900
<DocScrutinizer05>
I guess it needs some AFC to actually tune the 15th harmonic to the GPS frequency
<Openbot>
Docscrutinizer05 heard you are ill i mean coughing and sneezing .... Auaak
<Openbot>
Me too
<Openbot>
same pinch :D
arcean has joined #neo900
<Openbot>
After to nights of partying i am barely alive :p culprit been the 800gm block of icecream that i consumed and repeted hot coffe in winter :D :(
Openbot has quit [Read error: Connection reset by peer]
jonwil has quit [Remote host closed the connection]
infobot has quit [Ping timeout: 252 seconds]
bencoh has quit [Remote host closed the connection]
infobot has joined #neo900
mvaenskae has joined #neo900
bencoh has joined #neo900
FIQ has quit [Excess Flood]
FIQ has joined #neo900
FIQ is now known as Guest97800
Guest97800 has joined #neo900
Guest97800 has quit [Changing host]
Guest97800 is now known as FIQ
che1 has joined #neo900
b1101 has joined #neo900
MonkeyofDoom has quit [Ping timeout: 258 seconds]
b1101 has quit [Quit: b1101]
che1 has quit [Ping timeout: 250 seconds]
sixwheeledbeast has quit [Ping timeout: 258 seconds]
sixwheeledbeast has joined #neo900
<wpwrak>
DocScrutinizer05: (background) i don't get it. what's the connection between DESfire and FM killing GPS ?
<wpwrak>
(and i wish they would stop creating NFC/RFID bastards. it's not as if there weren't already countless protocols, variants and dialects in that area.)
Kabouik has quit [Ping timeout: 240 seconds]
GoGi_ has quit [Ping timeout: 258 seconds]
b1101 has joined #neo900
GoGi has joined #neo900
b1101 has quit [Quit: b1101]
Oxyd76 has quit [Remote host closed the connection]
<wpwrak>
(some) mifare uses framing that is different from what iso14443-3 specifies. so a standards-compliant transceiver can't interoperate with that.
<wpwrak>
that is, as long as it's standards-compliant. there are ways around that, not all of them nice
che1 has quit [Ping timeout: 258 seconds]
<DocScrutinizer05>
well, yes. Mifare is Mifare. But that's why I posted the link. To me it seems Mifare is a de facto standard on its own
<DocScrutinizer05>
alas owned by NXP aiui
<DocScrutinizer05>
but it's you who became our RFID/NFC expert recently :-)
<DocScrutinizer05>
6 months ago I hardly knew what GDC means by "NFC ROM"
<DocScrutinizer05>
now I at least know we want more than just ROM
<wpwrak>
or becoming :) still many more standards to consult ...
<wpwrak>
the equivalent of dumb RFID tags ?
<DocScrutinizer05>
yup, aiui
<DocScrutinizer05>
wpwrak: one mandatory capability / requirement for NFC chip in Neo900: detect field and trigger IRQ even when chip is in very low power mode
<wpwrak>
i have this as "also low power consumption when waiting for the device to enter the field of an NFC or RFID reader."
<DocScrutinizer05>
exactly :-)
<DocScrutinizer05>
low power = less than maybe 10mW
sparetire_ has joined #neo900
<wpwrak>
the greediest critter i've found so far would draw 50 uA @ 2.7-5.5 V in that state
arcean has quit [Quit: Konversation terminated!]
<DocScrutinizer05>
that's absolutely fine then
<DocScrutinizer05>
this plus a sufficiently versatile host interface, and we are good to handle all nasty Mifare and whatnot cases
arcean has joined #neo900
<wpwrak>
there's much more to it. e.g., (some) mifare encrypts some of the framing bits. that may be covered by the algorithm that's been cracked some time ago. other bastardizations may have their own quirks.
<DocScrutinizer05>
sufficiently versatile here means: control over OTA data on symbol level, incl all framing (aka "layer1" or "access to PHY"), plus sufficient bandwidth and low jitter/delay
<wpwrak>
of course, you only find that stuff when you read a number of specs and/or standards that refer to the same technology, because some will just skip over the delicate bits, or hide them in subtle wording
<DocScrutinizer05>
:nod:
<DocScrutinizer05>
that's why my original approach been: ask somebody who already is expert on that whole subject and get a recommendation for a chip
paulk-collins has joined #neo900
<DocScrutinizer05>
I picked Harald Welte for such expert
<wpwrak>
that would have been the pn532, right ? but i'm not sure if gives you such low-level access in all cases
<DocScrutinizer05>
prolly it doesn't, but it may fulfill our needs on a higher level
<wpwrak>
it does have a pn512 emulation mode that may be more flexible, but uses a weird interface (uart at 9600 bps), so i'm not yet sure whether that would be a key to some lower-level access
<DocScrutinizer05>
when high level interface has all we ever need, then why bother with low level stuff?
<wpwrak>
what is all we ever need ?
<DocScrutinizer05>
precisely all that Harald would want in a device he wants to use and hack on
<wpwrak>
so harald provides our specification
<wpwrak>
good to know :) so far, i tried to get that out of you. now i know what that wasn't very successful ;-)
<DocScrutinizer05>
I asked him: "when you could pick a NFC chip in your phone, so you could do all you want with it. Which chip would that be?"
<wpwrak>
and the answer was pn532 ?
<DocScrutinizer05>
either PN532 or PN544, I can't recall off top of my head
<DocScrutinizer05>
I posted his answer several times now, internally
<wpwrak>
nothing in my #neo900-internal logs ...
<wpwrak>
... let's see if there's anything in the mailing list archive ...
<DocScrutinizer05>
there is, for sure
<DocScrutinizer05>
search for laf0rge
<DocScrutinizer05>
~seen laf0rge
<infobot>
i haven't seen 'laf0rge', DocScrutinizer05
<DocScrutinizer05>
-NickServ- Last seen : Nov 30 00:27:02 2014 (2 days, 21:08:44 ago)
<wpwrak>
no matches in my neo900-internal log (for any case)
<wpwrak>
i find this for "harald", though: Sep 13 22:44:05 <DocScrutinizer05> Harald recommended PN532 iirc (been almost a year since I chatted with him about which chip to get)
<DocScrutinizer05>
check your mail!
<DocScrutinizer05>
I never quoted the whole convo on IRC
<DocScrutinizer05>
iirc
<wpwrak>
did you send something ?
<DocScrutinizer05>
not today
<wpwrak>
sigh
<wpwrak>
maybe you mean nik's mail entitled "[Neo900-devel] Fwd: NFC" ?
<wpwrak>
apparently based on "Betreff: Aw: NFC"
<DocScrutinizer05>
exactly
<wpwrak>
the former 2014-10-22, the latter 2013-11-10
<DocScrutinizer05>
>> [2013-11-09 20:53:47] <DocScrutinizer05> wenn du dir das wueschen koenntest,
<DocScrutinizer05>
>> was fuer NFC hardware wuerdest du dir in nem phone wuenschen?
<wpwrak>
so you want PN532 ?
<DocScrutinizer05>
I only quote Harald
<DocScrutinizer05>
it's you who selects the chip
<wpwrak>
oh :)
<DocScrutinizer05>
you got more expertise than me, definitely. On this topic
<DocScrutinizer05>
I just define some requirements
<wpwrak>
so far, i've been preparing a comparison of: PN512, PN532, PN544, and TRF7970A, addressing capabilities, interfaces, design integration aspects.
<wpwrak>
main focus so far on TRF7970A because it's the only one for which i found proper documentation. that is, before i discovered the PN512 yesterday. that one also has good documentation.
<wpwrak>
both are "dumb". PN532 and PN544 are "smart" (internal MCU). with only partial documentation. P532 has a lot more findable documentation than PN544.
<DocScrutinizer05>
you got the complete quote of convo between Harald and me, in this mail. Plus I shared with you all documents I've found and read since then
<wpwrak>
yes, i have have 19 references in the bibliography so far :)
<DocScrutinizer05>
yeah, all those "smart" NFC chips seem to have a "hardmac" firmware that's nasty in several regards
<wpwrak>
yes, limiting what you can do, uncertain outlook then it comes to updates/fixes, and - the cherry on top - they may create licensing obligations by implementing things we'd rather not have
<freemangordon>
so, the idea is to have FRID tag?
<freemangordon>
*RFID
<DocScrutinizer05>
I think a "stupid" chip better meets our requirements than a smart one, if it's really a completely stupid/dumb chip that allows full control of PHY
<wpwrak>
freemangordon: most chips implement RFID (various roles), NFC (various roles), proximity, and assorted other lower-layer protocols
<freemangordon>
maybe. but you can't really use anything beyond RFID in case the chip is cerified
<wpwrak>
NFC peer-to-peer should still work, i think
<freemangordon>
ye
<freemangordon>
ueah even
<freemangordon>
dammit
<freemangordon>
but what is the point?
<freemangordon>
I mean...
<wpwrak>
and we could have card emulation if we have access to an SE, e.g., in the SIM/UICC
<freemangordon>
SWP? IIRC PN512 does not support it
<wpwrak>
dunno what peer-to-peer is really used for
<freemangordon>
or you mean host emulation?
<DocScrutinizer05>
freemangordon: I have a certain feeling that you got sth wrong about what we wanna do
<wpwrak>
SWP is only natively supported by PN544 and similar chips
<freemangordon>
most probably
<freemangordon>
I was under impression you want mobile payments supported. Seems I got it wrong
<freemangordon>
well, NFC payments
<wpwrak>
the rest has to find its own solution for SWP if SWP is desired. PN532, being "smart" but SWP-less maybe have a problem in that area
nox- has joined #neo900
<freemangordon>
and stuff like MiFare etc
<DocScrutinizer05>
NFC is a radio. We want a radio that's as much controlled by APE CPU as possible. And we have harsh requirements regarding what has to be possible and what we maybe don't care about, in such amount of control
<wpwrak>
i think we'll only want to "support" very very few actual specific use cases. i.e., just something that lets us test that the circuit works at all.
<freemangordon>
DocScrutinizer05: see, I am not arguing(unusual, yeah? :) ) My concern is that if you put a piece of HW noone will really use, you're just wasting time
<DocScrutinizer05>
freemangordon: why will nobody use it?
<wpwrak>
others can then build on top of it, enjoying all the flexibility we don't use ourselves :)
<freemangordon>
thus my question what real-life use cases you have on your mind
<DocScrutinizer05>
wpwrak: no, we want to support as many usecases as possible
<DocScrutinizer05>
ooh, maybe your definition of "support" is different to mine
<wpwrak>
yeah :)
<wpwrak>
"allow"
<DocScrutinizer05>
yep
<freemangordon>
because building such stack is not a trivial job, leaving the legal stuff aside
<DocScrutinizer05>
mine is "allow"
<DocScrutinizer05>
or enable
<wpwrak>
well, there's some NFC stuff in the mainline kernel
<DocScrutinizer05>
freemangordon: neither of which is *our* problem
<wpwrak>
we're like intel: we make the hardware, let others do the "app store" or whatever ;-)
<freemangordon>
well, but you should have some real-life use cases in mind, ain't?
<DocScrutinizer05>
our only legal issues are with chips that come with "hardmac" firmware that defines (and limits) what the chip can do
<DocScrutinizer05>
freemangordon: what are the "reall life usecases" for SDR?
<freemangordon>
no idea TBH :)
<freemangordon>
a co league of mine uses some USB dongle, I shoudl ask him what for :)
arcean_ has joined #neo900
<freemangordon>
anyway, I am going afk
<freemangordon>
night guys
<DocScrutinizer05>
you're arguing like "this WLAN chip cannot do AP, it's not providing a firmware that can do it. Don't you want to allow AP mode?" I answer: "we are using a chip here where CPU implements AP mode"
arcean has quit [Ping timeout: 258 seconds]
<DocScrutinizer05>
NFC is no always-on technology like WLAN, it's rather a always-standby technology, with very rare and short activation periods. The dumber the chip, the more control the CPU has over it to implement in software what otherwise gets forcefed down our throat by chip manuf's closed blob chip firmware
<DocScrutinizer05>
only 2 things the chip must allow: wake on field detect (from ultralow power state), and full access to PHY
<DocScrutinizer05>
everything else can get implemented in CPU software
norly has joined #neo900
<DocScrutinizer05>
APE CPU
<DocScrutinizer05>
and yes, we want mobile payments supported. But not necessarily autonomous mode without APE CPU powered up
<wpwrak>
the trf7970a seems to do pretty much all of that. there are a few open questions about modulation, which seem to disagree between specifications, but that may just be yet another switch in terminology
<DocScrutinizer05>
wpwrak: most likely
<wpwrak>
interfacing to DM3730 could be challenging, though. but you'll have to wait for the details until i'm done :)
arcean_ is now known as arcean
<Oksana>
Good morning! For use-case of mobile payments: will SWP wire need to go like SIMcard - CPU - DM3730 - NFCchip, since NFC chip is "dumb" and does not do anything by himself?
<DocScrutinizer05>
prolly yes
<DocScrutinizer05>
SWP is a requirement. SWP without battery not
<DocScrutinizer05>
most chips not even support a SWP "wire"
<DocScrutinizer05>
so the CPU will have to do the job of the MCU in NFC chip, talk to SE via SWP wire and convert that SWP data to commands or even raw data to the NFC chip
<wpwrak>
SWP is also a treat. the ETSI standard specifies parameters that don't really seem to exist. e.g., output voltages on a pin that's current-operated (leeching power from the other side)
<DocScrutinizer05>
hehe
<DocScrutinizer05>
ooh, maybe they do Power-Over-SWP ?
<DocScrutinizer05>
similar to ECI?
<ds2>
SWP?
<ds2>
same as dallas/maxim onewire or?
<DocScrutinizer05>
Single wire Prototcol
<DocScrutinizer05>
bidir communication between SIM and NFC chip via one wire
<wpwrak>
ETSI TS 102 613
<ds2>
let me search for that...SWP didn't turn up useful stuff
<Oksana>
TI recommends using MSP430F2370 microcontroller to control the "dumb" NFC chip, and there are flasher and firmware available for it, though I do not see the licence of the firmware. http://www.ti.com/lit/zip/tidc053
<DocScrutinizer05>
luckily we won't need a MSP430, we got an OMAP3 ;-)
<wpwrak>
i wouldn't use an MSP430. uncertain toolchain support and in any case a "strange" architecture. (ti recommend it for everything, of course)
<Oksana>
For everything?.. Alright, just reminding that it is not necessary to put all calculations onto one CPU. There is firmware code available from TI; what is its license, and can it be used to improve the Linux driver for trf7970a? It "currently only supports the two SPI modes", not the parallel mode (whatever it means).
<wpwrak>
Oksana: i'd agree that there would be a quite a number of things there an MCU would be useful for. things the OMAP is really bad at. but i would use an ARM.
<DocScrutinizer05>
sorry, that MCU won't happen for NFC. Don't see that based on a "OMAP is really bad for". Such statement needs more elaboration on *why* OMAP allegedly is _bad_ for a particular task, so bad that a MCU is better on it
<wpwrak>
yes, you'll find all the details in my report
<DocScrutinizer05>
a dedicated MCU adds extreme overhead in design, to make it cooperate with main CPU, allow its programming etc
paulk-collins has quit [Quit: Quitte]
<DocScrutinizer05>
you think discussing your conclusions beforehand isn't worth it?
<wpwrak>
i don't think it would be advisable. you'll just fight every single detail i bring up and we'll lose sight of the big picture.
<DocScrutinizer05>
aha
<wpwrak>
so i want to have it in a reasonably finished state before you have a go at it
<DocScrutinizer05>
and you hope you convince me when you come with the big one?
<wpwrak>
i hope so, yes :)
<DocScrutinizer05>
:-S
<DocScrutinizer05>
seems not really in line with the open communication we promised even to our customers, not to mention team-internal
<wpwrak>
but i need to think these cases through in detail. sometimes, you hit an unexpected brick wall only after the second consecutive work-around.
<ds2>
DocScrutinizer05: overhead as in SW or HW?
<DocScrutinizer05>
HW of course. SW will be a PITA that I happily offload to Werner
<ds2>
given all the low pin count MCUs around, what kind of overhead are you referring to?
<DocScrutinizer05>
low pincount, great. That usually means "apply 20V to Vpp pin to reflash the program storage"
<wpwrak>
no PICs, please ;-)
<ds2>
the ones I have seen don't do that
<DocScrutinizer05>
MCU's never are made to work as a coprocessor
<ds2>
ARMs and 430's
<DocScrutinizer05>
you need more APE CPU GPIOs to control and operate the MCU than the MCU provides to the system in return
<ds2>
*nod*
<ds2>
i suppose... i2c bootloader on MCU and... ;)
<DocScrutinizer05>
haha. start with reset
<DocScrutinizer05>
or no, start with power even
<Oksana>
1) connection between CPU and MCU to be able to flash MCU 2) SWP wire like SIMcard-MCU-NFCchip 3) MCU could draw power from the same source as dumb NFC chip
<DocScrutinizer05>
and which MCU has a I2C bootloader in ROM?
<DocScrutinizer05>
sorry, I'm not going to discuss this stuff right now with non-EE, when I don't even see why we would need - not to say benefit - from such cruft at all
che1 has joined #neo900
<ds2>
parasitic power from the NFC of course :D
* DocScrutinizer05
frowns
<ds2>
<-- EE
<DocScrutinizer05>
this again turns into something that makes me feel like wasting my time
trx has quit [Ping timeout: 252 seconds]
<DocScrutinizer05>
I won't comment on the whole thing anymore before somebody told me what is the magic a MCU can do and OMAP cannot
freemangordon_ has quit [Ping timeout: 252 seconds]
sixwheeledbeast has quit [Ping timeout: 252 seconds]
freemangordon_ has joined #neo900
<ds2>
heeheheh
<ds2>
it is really too bad the OMAPs don't have an on die PRU
<DocScrutinizer05>
huh? PRU?
<Oksana>
Ok, ok, MCU is too much trouble, too many pins-wires, and does not bring any tangible benefit. Except for NFC being able to work when the telephone is switched off (if MCU + NFC chip + SIM card use power supplied by NFC antenna)
<ds2>
the OMAP cousins like the AM335x series have something called a PRU (Programmable Realtime Unit); it is 2 MCUs on the same die as the ARM
trx has joined #neo900
trx has quit [Changing host]
trx has joined #neo900
<ds2>
design for running odd ball protocols
<DocScrutinizer05>
meh, a CPU at 1000MHz can bitbang up to the MHz range. Probably it could even send FM broadcast signals via a GPIO, in stereo. Wait RPi does exactly that
<ds2>
timing on the A8 is not exactly deterministic - caches, DDR refresh, IRQs, etc
<ds2>
the PRU is designed to be timing deterministic
<DocScrutinizer05>
and NFC transaction takes max 1s. You could even stop the linux scheduler for that time and have the complete CPU only do bitbang
<ds2>
IIRC the Pi does not use the A8 for that
<ds2>
but like you said... enough. personally like having programmable aux processors but this project's SoC is decided already so all that is moot
<bencoh>
they bitbang fm on RPi ? fun
<DocScrutinizer05>
so I've been told
<DocScrutinizer05>
maybe they (ab)use a certain hw interface for it, like UART or DVI or whatever