View Single Post
Posts: 110 | Thanked: 362 times | Joined on May 2014
#1
N900 is a great Phone. But i miss some features: better battery, faster browser, less lag.
Better battery is kind of easy. (Yes your device gets more bulky.)
The main reason for the others is i guess lag of ram and bad io.
So if my device gets more bulky by battery, maybe i can fix the other issues too.

First Why not use usb?
sd seems to be the better bus cause it offers lower latency, it can operate at 3.3V and maybe 1.8V, doesnt consume as much power no need for 5V and is supported as an tested addon in N900 and maemo.

So my idea was to get a ram based sd card. to get the most of the sdio bus.

For that i got an bbb, which is kind of the older brother of n900 cpu wise, very familiar.
It has kind of a dual cortex m0 coprocessor running at 200 Mhz. (awesome).
So you can use it as a logic analyser currently able to capture at 100Mhz (my guess is 200 is possible if ti hasnt messed this up too)
to a 380mb of ram. That would be a nice swap space or a nice little nand read only expansion.

So i started my RamOnSD project, to explore what is possible and maybe later use a beagle core to actually expand the n900.
It basicly bitbangs sdio / emulates an sdcard. My initial goal was to get it at 50Mhz 4 lines,
which would give you a 15-18mb random(!) read write card.

I failed, but i blame ti
the current status is i can send at 35mhz (13mbs) zeros via 4bit sdbus.
zeroes are easy cause crc is zero too.
But i know know that i wont reach 50 Mhz mainly because i got an too high latency.
I measured 4 clocks from fast pru output to pru fast input.
But the real problem is pinmuxing..
pinmuxing is a mess on bbb. (Many new technologies: device tree, with many bugs, you are beta tester in this field)
A ti selling point of the prus is bitbanging. But you cant switch the pins from the pru (Bug??),
which leads to nondeterministic latency by going through the a8. You need 3 pins to implement a 1 pin tristate,
the ti easy solution with 2 pins didnt work for me.
For sd you need 5 bidirectonal lines, 1 is the cmd line which needs to be exactly switched in 2 sdbuscyles from input<->output
you cant do that without additional hardware, which adds another 2-4 cycles latency.
At 50Mhz sdbus speed you got 4 cpu cycles per sdbusclock..
You can use the second pru to help. But my guess it would be really hard to bitbang at 50 Mhz.
(the most max value i read in the docs is 25mhz)
I bought additional hardware 1euro bus driver and im now able to send zeros at 35Mhz, 13 mbs.
To send something else you need to fetch it to pru first and then clock it out. Which most likely slows it down more.
So it is a ton of work in minefield. You can read a few problems at beaglelogics status updates how he switched from bbb to ti remoteproc,
just to get some nice features of the pru, which are currently not available on bbb disto. (xin/xout, iloop ..)
(So in my opinion ti failed to push upstream.)

A Picture of my set setup.
http://www.pic-upload.de/view-290104...25053.jpg.html

A samsung/sandisk card can give you already 5 mbs random read.

So second idea: connect a som/soc through sd io, reduce the apps on n900 to basic stuff put this in a ramdisk and do other ram intense thinks (like a browser) on soc/som.

using an fpga for 50 mhz would be too easy more costly and i guess to power hungry.
 

The Following 11 Users Say Thank You to pythoneye2 For This Useful Post: