IRC channel logs
2023-10-12.log
back to list of logs
<oriansj>I am starting to think, no one wants anyone doing low level programming with e-ink screens <matrix_bridge><Christoph> Using e-ink screens to do the programming or writing low level programs for e-ink screens? Or both? <oriansj>writing a low level program for an e-ink screen to enable functionality with a very low power CPU <janneke>ACTION would love a e-ink screen on their laptop <oriansj>well the 230ms screen latency however is far from ideal for anything other than reading. <oriansj>not to mention the Power up delay (3mS per rail) and Power down delay (6mS per rail) <oriansj>but the ability to make an ebook reader with an 18month battery life or able to be powered by a $5 solar panel is very attractive. <euleritian>It would also be very interesting for displaying maps while hiking! <oriansj>euleritian: potentially as one can definitely fit all of the world's topographic maps on a microSD card. It just might be a question of the power consumption of the GPS chip and if it could be switched off and on to determine one's position on desire and reduce power consumption when exact location isnt needed <oriansj>although looking at handheld GPS systems for hikers, models that support displaying maps tend to support color as I am guessing it is easier to properly interpret in bad weather. <oriansj>toss in an altimeter and compass; and it'll definitely outlast the 25hour Life span you see with a pair of AA batteries in most available products currently on the market. But I am guessing that might indicate GPS units draw a great deal of power <euleritian>But even without GPS i think it would bebuseful. <oriansj>indeed; and it looks like a 25ish second power-on to location data <oriansj>so hard toggle switch and an LED that turns on when the GPS location data is available and a different color when it is turning on <oriansj>or maybe push button which only powers the GPS long enough to get current location and then turns the unit off <oriansj>and thus far in my testing I have 3months on a single battery charge (with plenty of charge remaining) with my Inkplate6 but having to use Arduino studio or micropython is far from ideal <notgull>oriansj: no one wants to write Forth <oriansj>notgull: generally true; but writing in assembly can be quite enjoyable <notgull>I suppose so, but I imagine that the e-ink CPU doesn't use x86 <oriansj>notgull: well e-ink displays are independent of the CPU used but in the case of the inkplate6, it is definitely an ESP32 processor and its assembly is quite reasonable <oriansj>so it is entirely possible for someone to make a low power x86 (or AMD64 or RISC-V or PowerPC) system with the exact same e-ink screen <oriansj>to make them extremely energy efficient, they need only have an EEPROM and a TPL5111 and a little bit of clever programming <oriansj>as EEPROMs only have 1K-100K programming cycles, you make sure the first word of EEPROM is a pointer to another place where you store the actual state. Whenever the area of memory where you store the state starts to fail, you change the pointer to a new location. <oriansj>but if storage temperatures get up to 55 degrees C, it'll need to be refreshed every 12.5 years. <muurkha>oriansj: probably most Flash will hold information for over 100 years <matrix_bridge><Christoph> Why do you start to think that no one wants anyone doing low level programming with e-inks? <muurkha>it's typically rated for 10 or 20 year retention with one bit error per 10**8 or something like that <muurkha>but that's over the entire temperature range, and charge leakage is exponential with temperature <oriansj>Christoph: lack of good information in regards to low level programming of e-ink displays; the closest I found was arduino libraries written in C <muurkha>if you hold it at 20 degrees you should expect degradation about 32 times slower, if we assume the usual Arrhenius rule of thumb of 2x per 10 degrees (?), which would be 320 to 640 years <muurkha>even after that time, though, the retention might be good enough with more aggressive ECC <muurkha>the n24c02 datasheet you linked specifies storage at below 150 degrees <muurkha>"Industrial and Automotive Grade 1 Temperature Range" <oriansj>muurkha: well we dont have good long term data on EEPROMs, the technology is only started to exist in 1971 <muurkha>but I think it's only rated for operation up to 125 degrees <muurkha>oriansj: it's true, there might be degradation mechanisms that don't decline exponentially with temperature and so become dominant at low temperatures <oriansj>muurkha: well as I only expect the device to operate in within 10C of local climate conditions, I don't expect that to be an issue. <muurkha>cosmic rays being the classic one, though radioactivity from chip packaging materials is also something to consider (how much C-14 is in that epoxy?) <muurkha>my thoughts on e-ink are that memory LCDs are a lot lower power and also a lot faster <muurkha>a Swindle-sized e-ink screen seems to be about 100mW at typical refresh rates of one or two refreshes per minute, while this 400x240 memory LCD I have here is 100 microwatts, 1000 times lower. it's smaller, but only 10x smaller, so that's still 100x lower power per area <muurkha>probably you mean 3ms, not 3 millisiemens <muurkha>I think the e-ink company doesn't want to reveal information about their screens, but that doesn't mean *no one* wants the low-level programming <muurkha>I don't think you can make a low power i386 or amd64 or PowerPC system unless you fab you own CPUs. Z80 might be an option if you can get hold of the S1 MP3 chips or whatever TI calculators used, but it seems like a lot of pain for no gain <oriansj>or the e-cache parity error on UltraSPARC-II which was caused by radioactive boron being used in the making of the ICs themselves <muurkha>people who like smol things might like it <oriansj>muurkha: well, long term we will probably want to start making our own CPUs and GPUs as it'll be great fun <muurkha>oriansj: we must put the means of production in the hands of the workers <oriansj>and yeah, e-ink companies definitely are the primary to blame party for hiding details about how their products work. <muurkha>or, as the Whole Earth Catalog slogan puts it, obtain "access to tools" <muurkha>have you looked at the Skywater PDK any? <oriansj>muurkha: hard to justify having a fab to the wife process but the bootstrapping community paying for fab access seems reasonable <muurkha>I still haven't done anything with this iCE40UP5K FPGA devboard I have here <oriansj>and yes the skywater PDK is more than enough to manufacture x200 level systems but we will need better as things go further. <oriansj>well they certainly could be done in a low circuit count <muurkha>ultimately we need computer fabrication not bottlenecked by giant fabs <oriansj>to a degree yes and to another degree no <muurkha>it's a central point of failure, a place where backdoors can be inserted <oriansj>for trusted bootstrapping, absolutely being able to print a CPU at home would enable trusted systems <muurkha>well, it would help. a baby you print at home can still be born with HIV <oriansj>but I cant imagine doing sub-65nm lithography for under $10K <muurkha>when I make yogurt, the bacteria make lots of things smaller than 65nm, and they don't cost anywhere close to US$10K, so clearly it's possible <oriansj>muurkha: fair enough, I just haven't mastered bacteria based CPU manufacturing techniques <muurkha>that's why TSMC is still in business! <muurkha>this flaring-out keyboard seems awesome, I wonder how that works mechanically <oriansj>well, that would just be a future cost reduction for nanoscale assembly and in the short term, it is acceptable to assume some collective costs and investments. <oriansj>there are full schematics and diagrams available if you are interested (as it is a 30+ year old design, all patents should be expired by now) <muurkha>another thing to keep in mind is that significantly lower density is available if you can go 3D and plumb coolant channels through the device <muurkha>a planar gibibyte is 65536 by 131072 bits; if that has to fit in 100 mm x 200 mm the bit needs to be 1.5 microns on a side or less <muurkha>in 3D it can be 2048 x 2048 x 2048; in 100 mm that's 50 microns on a side, big enough to see with the naked eye <muurkha>a minimal viable computer for self-hosted development is probably 4KiB and 4000 transistors or equivalent <muurkha>32 x 32 x 32 bits of RAM and 16 x 16 x 16 transistor-equivalents <muurkha>that's enough RAM to run 6502 BASIC or FORTH without a ROM, and enough transistor-equivalents for a PDP-8 or 6502 <muurkha>you could 3-D print a mechanical version, but it won't run fast unless it's a lot smaller than that <muurkha>and PLA probably won't make for a reliable machine; you'd have to print in something that creeps and fatigues less. going from mechanical to electronic gives you an instant 30x speed boost at a given scale, usually more <muurkha>7 cents a transistor seems like it should be manageable even with monster-6502-style discrete transistors split onto multiple different boards <muurkha>aha, yes, it has an estimate at the end: US$243.50 for a CPU made from 10,000 transistors (2N7002, which is cheaper) each with two resistors <muurkha>or US$142.75 using standardized 3-LUTs, or US$22.21 for 1000 gates split evenly between AND and NOT <muurkha>which I rounded up to "probably(...) under US$50" <oriansj>yeah, a monster-6502 style RISC-V would probably be sufficient to be a trusted boot processor and with the great work being done by stikonas, ekaitz and janneke on the RISC-V port; in the nearish future it'll be a "done" option <muurkha>I wonder how small you could get Minimax that way <oriansj>well with MesCC, you'll want 4GB of RAM; but that will be enough to build tcc, gcc and Linux <oriansj>which would be the largest fab problem but the cpu definitely could be quite simple <muurkha>you might be able to use untrusted RAM if you encrypt it <muurkha>Minimax won't run Linux; it doesn't have an MMU. Neither does SeRV <muurkha>(also Minimax doesn't have interrupts yet, but that will probably be fixed) <muurkha>I think PicoRV32 and VexRiscV can run Linux <muurkha>about 10x the size of Minimax or my 10k transistor estimates above <stikonas>oriansj: so far we only did riscv64 port of mes and tcc <stikonas>(and even that still needs finishing some final bugs) <muurkha>a riscv64 port of either of those on its own would be impressive <notgull>Wait, is there any progress on any kind of device that can fabricate chips on even a small business level? <muurkha>notgull: sure, e-beam lithography and FIB milling can fabricate one-off microelectronics <muurkha>but the fabrication process I most recently linked above is PCB pick-and-place, which has been accessible even to hobbyists for 50 years <muurkha>it's just that it's a lot more accessible now <muurkha>it was normal practice in the 60s and 70s to build CPUs that way <notgull>How are electronics like that made nowadays? <muurkha>they're integrated as a small part of a much larger chip <muurkha>but now a 74HC164 costs 9¢ and a 74HC14 costs 8¢ <muurkha>and power consumption of diddly squat compared to actual TTL from 50 years ago which cost US$1 <muurkha>so a computer that cost as much as a house built that way at the time ought to go for under US$500 now <oriansj>muurkha: sounds like I am missing out on some serious legacy fun <oriansj>I wonder if one could find the board designs for a VAX and make a tiny one for themselves