About MT7688 & MT7681

I get a news from some website. It said MTK will public MT7688 which has embedded 256MB(or 256Mb?) memory, power consume will be cut to 40% about later 2014.

It will be expansive to embed memory on the chip…This will become an magic chip for hobbyist, just pray for the price lower, lower, lower…

Anyway, this will not effect current VoCore, if I use it to make a smaller VoCore but cost much more than raspberrypi+wifi, that is useless. And new chip will always have tons of bug, at least two years for the stable, I do not want to be the little white rat. 😀

VoCore: SPI or not?

The three days I am working on SPI. It is a little hard to route, but I added SPI interface to the pins finally.

vocore.spi

 

The upper shows the SPI pins export map. The advantage of this version is all GPIOs(it is real, all 28 GPIOs have exported), and SPI interface is exported too.

The disadvantage is GPIO14, GPIO15 are too near each other, if you solder a connector to GPIO15, it might cover some of GPIO14.

I have tried many ways to make the two GPIOs to be together peacefully, but looks like there is no prefect solution.

If you have any good idea about this, please leave a comment. 🙂

VoCore: GPIO Test

GPIO works, not that hard. 🙂

GPIO is map to linux file system.
It is here: /sys/class/gpio
in this folder, there are three files/folders:

root@OpenWrt:/sys/class/gpio# ls
export     gpiochip0  unexport

export: this is used to export GPIO interface, so we are able to use it by command/code directly.
unexport: unexport the exported GPIO interface.
gpiochip0: not sure about that, should be a map for gpio control driver.

Export one GPIO, for example, GPIO0, it is at top-right of VoCore.

vocore.gpio.1

echo 0 > export

Now, interesting, a new folder named gpio0 appears:

root@OpenWrt:/sys/class/gpio# ls
export     gpio0      gpiochip0  unexport

So we have succeeded map gpio0 to the file system.
Go into that folder, we will see:

root@OpenWrt:/sys/devices/10000000.palmbus/10000600.gpio/gpio/gpio0# ls
active_low  device      direction   edge        subsystem   uevent      value

active_low: looks like a notify. 🙂
device: it is a link, device -> ../../../10000600.gpio
direction: in/out, depend on this.
edge: do not know… 🙂
subsystem: a link again, subsystem -> ../../../../../class/gpio
uevent: emm, I am too lazy to search it. 😀
value: this is input/output/current value of GPIO.

If we want to use GPIO0 control a LED, we must make its direction out.

echo out > direction

Now, use a simple script to make the LED flash:

while [ 1 ]
do
echo 1 > value
sleep 1
echo 0 > value
sleep 1
done

Looks like everything works fine. Video here:
Youtube: http://youtu.be/aOTZYtB8U3w
Youku: http://v.youku.com/v_show/id_XNzE5Nzc2MzI4.html

Just one problem, the WLAN_LED should remain bright when it boots into Linux as the old version, weird, it just come to dark when wifi is ready. I think there must be something wrong with dts, I changed it. 😀

VoCore Weird Problem: Can Not Write To Flash

I replace the old 2.2mm tall SPI flash and put a new 1.0mm tall SPI flash to VoCore, but then I find I can not update u-boot or firmware.
There are the command:

wget http://vonger.cn/upload/uboot.img
mtd write uboot.img u-boot

Looks like it works smoothly, no error reported.
But after I reboot VoCore, it is still the old version…
I thought that must be my mistake, I uploaded the wrong version of the uboot, so I just do the wget/mtd again.
Unfortunately, it is still the old version and even worse, the UART outputs some random code sometimes.

That really scared me 🙂 I was thinking: is that caused by the hot summer? Outside is over 35℃, VoCore is about 68~70℃. But somebody had tested, RT5350 could work normally even over 90℃,  so we can exclude this possibility.

The second guess is about software. I tried the same thing and compared it with another VoCore, that one works well.

So I confirm that is hardware problem, especially on the SPI flash part. At that time, I remember there is a pin named WP(write protect) on the SPI flash. That pin must be driven to high(3.3V) or the SPI flash will not be able to write(randomly).

Then I put some paste on the pins and solder the 8 pins again, make sure every pin is well connected, then plug VoCore to power, everything is back to normal. 😀

Tall one & Short one

IMG_20140529_152224

Right side is a normal one, easy to buy from market. The left one which will be used to the release version of VoCore is very very rare. I am lucky, find them in a store. Its mark is 1240, means its production time is about 2012.10(almost 18months ago).

I have checked a lot of datasheet, finally get that. 😀

VoCore: Ethernet Test 3

This is its power consume:
5V input, AP+STA mode, ethernet port 0 is on, length is about 3m.

PC is off/no data transfer, power consume(200mA~220mA):
vocore.ethernet.off

PC is on, download at full speed(240mA~260mA):
vocore.ethernet.on

The power consume for ethernet is just fair. 🙂

VoCore: Ethernet Test 2

Haha, it works now.
Just unplug it from my router, and connect it to my windows PC(really hate mac removed ethernet interface XD).
Data transfer this way:
My House Router (wifi)-> VoCore (ethernet)-> My PC.

VoCore alloced 192.168.61.190 for my win pc.
vocore.ipconfig

Now I am sending this blog through the VoCore 🙂 The tests move so smoothly.
Later will watch a movie or do something using heavy network load. And put my phone near it as an interfering signal(that is real, once my phone ring, my HDMI monitor just go black and do not work at all! It is about 20cm from the HDMI cable) to check if there is any problem for high frequent data transfer. I have confidence for that, due to the wire is very short(about 300~400mil) and every data pair length is just same(<10mil, but impedance about 80ohm). vocore.ethernet

VoCore: Ethernet Test

Connect dock to ethernet.

IMG_20140527_111233
IMG_20140527_111307

Looks like there is nothing wrong in hardware part.
LuCI detected the ethernet port0.

vocore.pluged

There is something wrong in the software part, I can not connect to the ip which alloced by my house router. VoCore’s AP+STA is still working, but ethernet not. I find the VoCore sta mac and the ethernet mac in my HyFi router DHCP client list.
192.168.1.103 is wwan(sta mode).
192.168.1.102 is the ethernet.
vocore.dhcp

This is ifconfig result.

root@OpenWrt:~# ifconfig
br-lan    Link encap:Ethernet  HWaddr 02:0C:43:30:50:C8
          inet addr:192.168.61.1  Bcast:192.168.61.255  Mask:255.255.255.0
          inet6 addr: fd50:771b:79c7::1/60 Scope:Global
          inet6 addr: fe80::c:43ff:fe30:50c8/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1401 errors:0 dropped:0 overruns:0 frame:0
          TX packets:589 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:119829 (117.0 KiB)  TX bytes:117226 (114.4 KiB)

eth0      Link encap:Ethernet  HWaddr 02:0C:43:30:50:C8
          inet6 addr: fe80::c:43ff:fe30:50c8/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4711 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5456 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2652097 (2.5 MiB)  TX bytes:839633 (819.9 KiB)
          Interrupt:5

eth0.1    Link encap:Ethernet  HWaddr 02:0C:43:30:50:C8
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4708 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4998 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2567133 (2.4 MiB)  TX bytes:622033 (607.4 KiB)

eth0.2    Link encap:Ethernet  HWaddr 02:0C:43:30:50:C8
          inet6 addr: fe80::c:43ff:fe30:50c8/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:453 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:176542 (172.4 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:163 errors:0 dropped:0 overruns:0 frame:0
          TX packets:163 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:13566 (13.2 KiB)  TX bytes:13566 (13.2 KiB)

wlan0     Link encap:Ethernet  HWaddr 00:0C:43:30:50:C8
          inet addr:192.168.1.103  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:43ff:fe30:50c8/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1948 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1338 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:279153 (272.6 KiB)  TX bytes:332484 (324.6 KiB)

wlan0-1   Link encap:Ethernet  HWaddr 00:0C:43:30:50:C9
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:5483 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5848 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:665360 (649.7 KiB)  TX bytes:2902243 (2.7 MiB)

Looks like eth0 is following br-lan 192.168.61.1(same mac), so eth0 can not assigned to 192.168.1.102 auto. The two routers are fighting 😀
If I force eth0 ip to 192.168.1.102, what will happen? I will check later.

For now, the main hardware functions: Ethernet/Wifi/USB/GPIO, have passed two.