<ln2>
I know of the 703N. I really like that device actually. Where did you find it for $18?
<ln2>
One project I am interested in is using a USBAsp with V-USB as a cheap USB GPIO extender for devices like the 703N or MK802. It is much slower than native IO but works. But that adds more cost, two locux can be had for the price of one 703N + slow gpio. At the same time wireless is only $4 to add to the Locux. They are very close.
<rm>
mkay, not $18, from $21 on Aliexpress
<rm>
not sure what's V-USB or USBAsp, but can't you use an MSP430
<rm>
or an arduino
<rm>
as GPIO for MK802
<ln2>
A USBAsp is basically an Atmega8 wired to a USB plug. V-USB is an AVR library that "emulates" USB which means it can interface with USB without an expensive USB converter chip.
<ln2>
So the end result is a $5 pre-built avr board with USB and I think eight usable GPIO pins.
<ln2>
Theoretically you can use that device as a GPIO expander. I haven't found any examples of it being used for that purpose. But I'm about 99% sure you can.
<ln2>
So you are looking at about $26 for a 703N with ~10 GPIO (if you also rewire the LED pins). Of course software GPIO is slow so it depends on your needs. In comparison the Locux has full speed GPIO. Lots of them...
<ln2>
For $12 ($17 with wireless). The competition is very close and pretty much based on the project needs.
<ln2>
In that project they use v-usb with an attiny45 as a USB GPIO extender. So the USBAsp would work for sure. You could probably use their firmware. 8)
<ln2>
He also adds a shift register to add more IO (the attiny45 has only 4 available in that configuration). But that isn't an issue with the ASP.
RITRedbeard_ has joined #arm-netbook
Omni-Max has quit [Read error: Connection reset by peer]
<L84Supper>
someone on the ML mentioned that the i.mx6's are now available through Farnell. Has anyone actually purchased and received any?
<fra79Wii>
I'm using the kernel 3.4.24 from linux-sunxi project
<fra79Wii>
sing the goodix_touch module it load fine in dmesg, but then it doesn't work… and I don't know how to debug it wither...
GeorgeIoak has joined #arm-netbook
<fra79Wii>
hmm..sorry for the million typos I managed to do :P…
<fra79Wii>
does someone now if is worthed to port the drivers gt801_2plus1 from lichee 3.0.8 to the master branches?
<fra79Wii>
now = know…
pcat has quit [Ping timeout: 245 seconds]
<GeorgeIoak>
ssvb: Still not sure why but I never did get Mali loaded correctly. I did go back and have VLC w/ Cedar working and somewhat integrated into a browser too
<GeorgeIoak>
Q: Seems like boot take a while to load the Mali drivers, can you take a look at my .config (for 3.0.57r1) and see what's save to remove if I'm relying on VLC/Cedar
<gzamboni>
i dont know why but the csi only works when i set csi_mode to 0 in the csi1_para section of the fex
<gzamboni>
anyone know what it is this for ?
<ssvb>
GeorgeIoak: maybe we both are missing something trivial, but I have no other ideas about what could be wrong with the Mali drivers on your system
<GeorgeIoak>
ssvb: it's really crazy because I started with a fresh kernel and rootfs and then followed the Mali400 wiki steps but still ended up getting software renderer on the glmark2-es2 demo
<GeorgeIoak>
now i have everything loaded but i don't think they're needed for general 2D or Cedar. i needed to improve boot time so i wanted to remove some drivers if they're not needed
<Turl>
fra79Wii: do you have code for the "2+1" one?
<ssvb>
Turl: If I knew it beforehand, I probably would have written it in a bit different way (more targeting general public instead of the people already familiar with linux-sunxi)
<fra79Wii>
..I mean is not working the touchscreen yet.. I fix the compile errors, and "cat /dev/input/event2" shows stuff when I touch the screen...
<fra79Wii>
I guess putting it in xorg.con might work...
<fra79Wii>
Is not a clean driver.. I have plenty of errors...
<fra79Wii>
..plenty of warning I mean..
<techn_>
fra79Wii: oh.. you propably need to disable multitouch temporaly.. :/
<fra79Wii>
I've disabled it in the fex (I think)… is just I'm using a debian thingy.. I don't know where config stuff… but I have my gentoo build almost ready.. there I'll know where to put stuff...
<fra79Wii>
but I'll submit the patch tomorrow, now is late I have to go (I'm frugally hacking :P)
<techn_>
ssvb: were you @ fosdem? I didn't have time to watch any of those streams :(
<ssvb>
techn_: apparently the 2d accelerator in tegra is quite similar to g2d in a10, and they also have problems with scanout at high resolutions and need to throttle down memory bandwidth usage to avoid rather nasty image corruptions :)
<ssvb>
techn_: yes, I was there
<ssvb>
techn_: but I also hope that they will eventually upload videos because it was obviously impossible to attend multiple talks with overlapping timeslots
<techn_>
ssvb: I have spend last week trying figure out how to handle normal layer pageflipping.. :(
eFfeM has joined #arm-netbook
<techn_>
scaler layer have some internal buffering which hides the problem
<techn_>
but anyway.. good exercise.. I have learnt alot how to debug kernel
<ssvb>
techn_: if the primary layer is anything like the others, fixing page flipping should be just a matter of properly changing the base address for scanout
fra79Wii has quit [Quit: Leaving]
<ssvb>
techn_: and for the other layers, it is possible to use them either unscaled, or with the scaler
<techn_>
libv: did you really say that your experiemental driver 2% faster that binary driver.. and with real driver you'll get 200% better performance? :D
<techn_>
ssvb: It's bit more complex.. If you change page @ wrong time you'll get tearing.. and if you wait for right time you'll get poor fps.. allwinner has worked this around with empty vsync ioctl and vsync is always done during page flip
<ssvb>
techn_: hmm, can we just schedule the page flip on the next vsync irq?
<techn_>
some why vblank time can be set only to 31lines max :(
<ssvb>
techn_: is the irq coming at the wrong time or what?
<techn_>
ssvb: then you'll get 30fps .. application waits for vsync, get's it, flip's, misses 31'th line, draws to wrong page
<techn_>
or other option is to
<ssvb>
techn_: afaik this is normally solved by triple buffering
<techn_>
yes.. thats option too.. but you'll lose another 16MB ram :(
<ssvb>
techn_: what happens if the application does not wait for vsync?
<techn_>
I think then there is no problem.. It just needs to make sure that it draws to correct page
<techn_>
page is always flipped at correct time
<ssvb>
techn_: is this wait happening in the mali blob (framebuffer based variant)?
<techn_>
atleast xbmc waits for vsync.. but it uses scaler layer.. which seems to have that triple buffering automaticly :/
<ssvb>
techn_: or are you generally interested in proper vsync/pageflipping in other applications?
<techn_>
ssvb: I'm using directfb application as reference .. df_kncukles
<ssvb>
techn_: if it's not a mali blob, then we can probably add new ioctls for better vsync/pageflipping and update the affected applications
<Turl>
android would appreciate proper vsync support :)
<techn_>
hopefully I can resolve that by this weekend.. if not triple buffering is required for normal layer
<ssvb>
techn_: it would seem to be rather natural to have something like 1) non-blocking ioctl to schedule page flipping on next vsync 2) ioctl to block until the pending page flip is done (and maybe return the current base address/buffer offset)
<techn_>
ssvb: how well vsync is specified.. on which line it should be emited?
<ssvb>
techn_: don't know, but there should be a short blanking period where nothing is updated on screen between frames
<ssvb>
techn_: maybe this requires some experiments with different settings to get it right