Considering that I see giant >50 inch vertical LCDs screens used as advertisement boards in bus stops and every 100m along street. Same places that previously had rolling advertisement lightboxes swapping between printed ads every couple of minutes. So i would say there are quite a few places where ads are already past the point and the cost analysis isn't E-ink vs printed poster or rollup lightbox, it's E-ink vs >50 inch LCDs.
Browsed aliba and price difference between those rollup lightboxes vs similar size outdoor LCD advertisements wasn't that big ~$200-$400 for lighbox and maybe $400-1000. Wouldn't be surprised if advertisement companies can also ask more money for ads on digital screens compared to printed ones. Payoff period might be shorter than you think. But it would be nice to hear from someone in business who knows more accurate numbers.
As for refresh ugliness in case of advertisements it might be considered a feature even without fancy effects -> blinking attracts attention. And once you unavoidably turn your head to take a look at what's blinking in the corner of your eye the add has already changed. As long as it isn't too frequent maybe once every 3-5 minutes it will probably be considered acceptable. The giant LCDs with annoying videos area already sufficiently big eyesore.
I always thought the same when seeing that XKCD comic, but turns out it was the opposite. PS3 hack (2010) came 3 years after the XKCD comic(2007), they even used it as one of slides during 27C3 presentation. https://media.ccc.de/v/27c3-4087-en-console_hacking_2010#t=2...
From what I understand there was no change of base within the solution code. Author just used the base conversion function to prepare some test inputs.
"The input array must contain a string representations of the numbers. The programmer can use whatever representation they see fit"
Allowing arbitrary string based representation of numbers also means that whole task becomes a bit silly. Why stop at base 15, when you could use what I call the "FizzBuzz" number system.
In fizzbuzz number system the divisibility by 3 and 5 is encoded in first symbols of number. Something like 1="1", 3="F", 5="B", 10="B2", 30="FB2", 1000="B200". Digits represent rest of the number you get after dividing it by 3 and 5 if possible.
From what I understand the timer registers should be on APB(1) bus which operates at fixed 26MHz clock. That should be much closer to the scale of fast timer clocks compared to cpu_relax() and main CPU clock running somewhere in the range of 0.5-1GHz and potentially doing some dynamic frequency scaling for power saving purpose.
The silliest part of this mess is that 26Mhz clock for APB1 bus is derived from the same source as 13Mhz, 6.5Mhz 3.25Mhz, 1Mhz clocks usable by fast timers.
The related part of doc has one more note "This request requires up to three timer clock cycles. If the selected timer is working at slow clock, the request could take longer."
From the way doc is formatted it's not fully clear what "this request" refers to.
It might explain where 3-5 attempts come from, and that it might not be pulled completely out of thin air. But the part about taking up to but sometimes more clock cycles makes it impossible to have a "proper" solution without guesswork or further clarifications from vendor.
"working at slow clock" part, might explain why some other implementations had different code path for 32.768 KHz clocks. According to docs there are two available clock sources "Fast clock" and "32768 Hz" which could mean that "slow clock" refers to specific hardware functionality is not just a vague phrase.
As for portability concerns, this is already low level hardware specific register access. If Marvell releases new SOC not only there is no assurance that will require same timing, it might was well have different set of registers which require completely different read and setup procedure not just different timing.
One thing that slightly confuses me - the old implementation had 100 cycles of "cpu_relax()" which is unrelated to specific timer clock, but neither is reading of TMR_CVWR register. Since 3-5 of cycles of that worked better than 100 cycles of cpu_relex, it clearly takes more time unless cpu_relax part got completely optimized out. At least I didn't find any references mentioning that timer clock affects read time of TMR_CVWR.
It sounds like this is an old CPU(?), so no need to worry about the future here.
> I didn't find any references mentioning that timer clock affects read time of TMR_CVWR.
Reading the register might be related to the timer's internal clock, as it would have to wait for the timer's bus to respond. This is essentially implied if Marvell recommend re-reading this register, or if their reference implementation did so. My main complaint is it's all guesswork, because Marvell's docs aren't that good.
The Chumby hardware I’m thinking of is from 2010 or so. So if that’s it, it would certainly be old. And it would explain a possible relation with the OLPC having a similar chip.
For C# and Java sure. Those are relatively easy to decompile and the decompilers are quite reliable. With exception of features like generator functions and lambdas most of the languages map 1:1 from source to bytecode, type information is mostly maintained.
Reasonably designed embedded device like that should be using a watchdog timer which automatically restarts it if code gets stuck (it's a basic hardware level feature available in almost all microcontrollers), and any crash should also cause a reboot.
Considering the nature of product there is no interactive interface, it doesn't perform any critical operation like motor or heater control which couldn't be easily interrupted and resumed a fraction of second later after the reboot. In case of memory leak or some kind of memory allocator error it would also be safe to reboot. User wouldn't even notice if this happened.
So even if something goes wrong, chance of it being uncrecoverable seems low. It would need to be either some kind of persistent storage bug causing it to get stuck in a bootloop (in which case battery change wouldn't help either), or high level logic error preventing normal functioning while keeping the main loop running without crash or getting stuck (writing code in higher level programming language wouldn't prevent a logic error).
It needs ~60℃ . Immediately after pulling it out of the hot water it might little bit too hot and sticky, but after cooling a little bit it will become less sticky and cool enough to safely touch with hands.
Based on this https://www.youtube.com/watch?v=O4FUZcF_IC4 video LeapRader seems to use similar technology in the sense that they both are based on grid of points with offsets. Although at least by eye the timing/anchor dots don't seem to match the exact scheme described in TipToi reverse engineering repo. Also didn't see any obvious Sonix chips in LeapReader, at least in the teardown pictures I saw.
Looking at the Sonix website (the company providing camera+decoder chip solution used by TipToi) https://www.sonix.com.tw/category-en-956 they seem to have at least 6 generations of the code with varying amount of encoded bits.
they seem to describe slightly different variations of data encoding. Searching for Anoto (company that made one of the first patents) leads to a bunch more products using this technology.
List of 400+ patents https://patents.google.com/patent/US6548768B1/en#citedBy citing the Anoto 1999/2003 patent also gives a list of companies working on related products or technology. There are even some from LeapFrog but those seem to mostly cover practical application and UI aspects of a product using the optical position/code detection system.
Overall feels like Anoto is focusing more on a system which decodes the points into X/Y coordinates and covers whole page with contiguous pattern, but Sonix more on having codes which give specific ID although they also one version which gives XY position similar to Anoto. That might be partially a workaround to make the encoding schemes different enough not to infringe each others patents.
That doesn't really give a good answer to your question, but If I had to guess Leapfrog is probably buying their technology somewhere else possibly from Anoto.
There is also one similar product using Grolier name, which seems to use tech from Sonix just like TipToi so potentially compatible, at least the codes not necessarily the book format.
Browsed aliba and price difference between those rollup lightboxes vs similar size outdoor LCD advertisements wasn't that big ~$200-$400 for lighbox and maybe $400-1000. Wouldn't be surprised if advertisement companies can also ask more money for ads on digital screens compared to printed ones. Payoff period might be shorter than you think. But it would be nice to hear from someone in business who knows more accurate numbers.
As for refresh ugliness in case of advertisements it might be considered a feature even without fancy effects -> blinking attracts attention. And once you unavoidably turn your head to take a look at what's blinking in the corner of your eye the add has already changed. As long as it isn't too frequent maybe once every 3-5 minutes it will probably be considered acceptable. The giant LCDs with annoying videos area already sufficiently big eyesore.
reply