Re: some first impressions
Because somehow this email arrived to may inbox three months later,^^;, it is a good time to write a reminder. 1) eToys: It would be very nice to have support for Analog Input in eToys. For a month or so, Etoys has a support for Analog Input, in a sense that it can basically do what amixer does. Etoys has been supporting audio input and various ways to analyze it. For example, if you launch Etoys, go to the treasure box, bring Object Catalog out, go to Multimedia category, and bring up SpectrumAnalyzer. By talkin, whistling, etc. you can see what it does. It has different kinds of display, etc. However, the current SpectrumAnalyzer was written more or less for a demo, and not really up to the real use. As I summarized at: http://dev.laptop.org/ticket/4586 Combined with the underlying facility for analog input in Etoys, kids could write their own programs by using the input data to analyze it and play with it. Also, we could show the same data in different representations, such as time domain and frequency domain, at the same time side by side, so that a wave can be viewed in various ways. I asked Arjun while ago if he would have time to try to enhance SpectrumAnalyzer in Etoys. He said after polishing up Measure for these deadlines, he wants to give it a shot (I still think he is the ideal person). However, if others on the list have ideas and time and desire, please think about enhancing SpectrumAnalyzer (or write a better one). Thank you! -- Yoshiki inline: spectrumanalyzer.png___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: some first impressions
Hello all, Thank you for your emails. 1) eToys: It would be very nice to have support for Analog Input in eToys. You could use my code - See http://dev.laptop.org/git?p=projects/measure;a=blob_plain;f=audioGrab.py;hb=HEAD (getting samples) and http://dev.laptop.org/git?p=projects/measure;a=blob_plain;f=buttons.py;hb=HEAD (toggling between AC/DC modes and controlling bias voltage etc.) Or I could easily provide you with a class that you could use. I could make functions in that class that could simply return to you the required values. For example there could be a function that you could call to return avg voltage or rms voltage, select between ac/dc modes, set bias_on, set bias_off. Let me know if I can help in any way. I have opened the following ticket . See here - http://dev.laptop.org/ticket/2800 I have not assigned the ticket to any one nor set a time line for it as of now. Please feel free to set those. 2) Output Analog/Digital: The USB is an interesting idea as I had discussed with Mitch. I could simply make a board using a USB to parallel kind of a chip. I will be getting down to doing something similar shortly. Anybody would suggest to explore audio out for a similar purpose ? 3) Other ideas for sensor input : Mitch and Wad had suggested regarding exploring some basic medical applications using the Analog Input port. For example maybe be able to measure pulse rate ... I am quite excited about these ideas and plan to think about things to do on these lines too. Any initial suggestions ? regards, Arjun On 8/11/07, Mitch Bradley [EMAIL PROTECTED] wrote: Hal Murray wrote: - some parallel port (or similar) should be made available, for children to play with in physics. I remember playing with a PC parallel port with some simple software to turn leds on and off. When you are a kid, being able to send commands to projects you create is great (think about modern legos, but using simpler stuff like leds, motors, etc) : it translate the virtual part ie the software you create on the computer to the real world where you make leds blinks in sequence, or a motor move. ... There are USB connectors. ... USB to printer port adapters are also available. I've never played with one. Prices are under $40. There are also things like this with 24 GPIO lines. USBIO24R http://www.elexol.com/ US distributor: http://www.orteches.com/ $75 ... There is also the microphone input and audio output for A/D and D/A. I think the XO hardware supports a DC coupled mode. We should work on a collection of hacks to demonstrate how they work and a list of which ones are known to work. OLCP just had a summer intern, Arjun Sarwal, who developed some low-cost gadgets to plug into the mic port - temperature sensor, intrusion detector, etc. He plans to document them and set up a framework for documenting other similar hacks. We also talked about an OLPC digital gadget prototyping dongle with a USB-equipped microcontroller like those available from, for example, Atmel. Those chips cost a dollar or two and Arjun can get all the other parts really inexpensively in India where he lives. -- Arjun Sarwal One Laptop Per Child [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: some first impressions
Arjun, I composed an email that got longer with ideas, and sj must be rubbing off on me because i stopped just short of clicking Send, and actually made a wiki page. What I have no idea of how to do is actually to link back from a wiki page to an email discussion for context. Regardless, you might find it amusing to sometime look at this wiki page for some silly ideas that were inspired by your query for ideas, some of which have analog components: http://wiki.laptop.org/go/Wildlife Highlights: *Mimic, Parrot Activity, Tag Team Wildlife Research* *Open Source Mindstorm* *Brain Machine Interface* *Batchat* *Whalechat/Dolphin Dongle* *Xo scuba* *Xo snorkel* *Earth, Wind, Fire, Water* *XOEWS - XO Early Warning System* *Generation XO* *Lunchbox generator* *g1g1 solar* On Aug 15, 2007 5:00 AM, Arjun Sarwal [EMAIL PROTECTED] wrote: Hello all, Thank you for your emails. 1) eToys: It would be very nice to have support for Analog Input in eToys. You could use my code - See http://dev.laptop.org/git?p=projects/measure;a=blob_plain;f=audioGrab.py;hb=HEAD (getting samples) and http://dev.laptop.org/git?p=projects/measure;a=blob_plain;f=buttons.py;hb=HEAD (toggling between AC/DC modes and controlling bias voltage etc.) Or I could easily provide you with a class that you could use. I could make functions in that class that could simply return to you the required values. For example there could be a function that you could call to return avg voltage or rms voltage, select between ac/dc modes, set bias_on, set bias_off. Let me know if I can help in any way. I have opened the following ticket . See here - http://dev.laptop.org/ticket/2800 I have not assigned the ticket to any one nor set a time line for it as of now. Please feel free to set those. 2) Output Analog/Digital: The USB is an interesting idea as I had discussed with Mitch. I could simply make a board using a USB to parallel kind of a chip. I will be getting down to doing something similar shortly. Anybody would suggest to explore audio out for a similar purpose ? 3) Other ideas for sensor input : Mitch and Wad had suggested regarding exploring some basic medical applications using the Analog Input port. For example maybe be able to measure pulse rate ... I am quite excited about these ideas and plan to think about things to do on these lines too. Any initial suggestions ? regards, Arjun On 8/11/07, Mitch Bradley [EMAIL PROTECTED] wrote: Hal Murray wrote: - some parallel port (or similar) should be made available, for children to play with in physics. I remember playing with a PC parallel port with some simple software to turn leds on and off. When you are a kid, being able to send commands to projects you create is great (think about modern legos, but using simpler stuff like leds, motors, etc) : it translate the virtual part ie the software you create on the computer to the real world where you make leds blinks in sequence, or a motor move. ... There are USB connectors. ... USB to printer port adapters are also available. I've never played with one. Prices are under $40. There are also things like this with 24 GPIO lines. USBIO24R http://www.elexol.com/ US distributor: http://www.orteches.com/ $75 ... There is also the microphone input and audio output for A/D and D/A. I think the XO hardware supports a DC coupled mode. We should work on a collection of hacks to demonstrate how they work and a list of which ones are known to work. OLCP just had a summer intern, Arjun Sarwal, who developed some low-cost gadgets to plug into the mic port - temperature sensor, intrusion detector, etc. He plans to document them and set up a framework for documenting other similar hacks. We also talked about an OLPC digital gadget prototyping dongle with a USB-equipped microcontroller like those available from, for example, Atmel. Those chips cost a dollar or two and Arjun can get all the other parts really inexpensively in India where he lives. -- Arjun Sarwal One Laptop Per Child [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Todd Kelsey Good Green Fun: http://www.cftw.com/xoroids/ Willy Wonka Wonderful! - http://wiki.laptop.org/go/Image:StartOfMP.jpg Love Poem for people of Middle East: http://welcome.cftw.com Tour of laptop | http://wiki.laptop.org/go/608-demo-notes About Me/CFTW | http://docs.google.com/Doc?docid=dhbxftbn_35f5b46bhl=en;http://docs.google.com/Doc?docid=dhbxftbn_35f5b46bhl=en Loving the World | http://docs.google.com/Doc?id=dhbxftbn_36cx4kj7 Fascinating for me to sit here and realize the interplay and influence that music can have -- it is a part of my life, yet I haven't continued as I could, partly out of thinking there are more
Re: some first impressions
The SD is not really intended as removable media. The USB slots are. SD is intended primarily as a way to augment the internal flash over the life of the system. It is in an inconvenient location (there weren't many other options). We were/are most concerned about keeping water out... - Jim On Fri, 2007-08-17 at 22:32 -0700, Hal Murray wrote: I've tried one SD card made by a local company. It's a bit thinker than the genuine panasonic one. So this results in that it can only be ejected out a bit and I have to use my finger nail to grab it out. (probably same situation as you) Usually there's a groove at the tail of an SD card top side. However, the access on XO SD slot is only on the bottom side... :( I tried a handy SD card in my system. I have a B2 case with a B3 board. There are a rubber flaps covering the entrance hole. The flaps are pointed in, so inserting the card bends the flaps open but extracting the card tries to close the flaps. If they stick (and they do) then closing the flaps makes them stick even more. I think the basic problem is that the flaps stick harder than the internal spring pushes. You can feel them if you poke the card in partway and then pull it out. My SD card has a grove on the edge of the card. It's about the right size for a fingernail. The XO case has a slight indentation for your finger. Unfortunately, it's on the bottom rather than the top so I can't get at the grove in the card. Mumble. Better have a pair of tweezers handy if you expect to use the SD slot. -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: some first impressions
Hello, On 8/18/07, Yuan Chao [EMAIL PROTECTED] wrote: I've tried one SD card made by a local company. It's a bit thinker than the genuine panasonic one. So this results in that it can only be ejected out a bit and I have to use my finger nail to grab it out. (probably same situation as you) Usually there's a groove at the tail of an SD card top side. However, the access on XO SD slot is only on the bottom side... :( Currently I have a 4 Gb SD (plain SD, no SDHC) and after comparing it to another SD, yes it's thicker Jim said the SD port was not for removable media use - I fully understand since I put the SD in to have storage space to try to set up stuff, and anyway USB keys are more practical But then the current slot is not fulfilling either goals. It's hard to use, and still open for the water to get it. Maybe the plastic could be shut tight? Tried FBReader on XO. It needs some fine tuning for XO's special resolution and works well. It may not be a bad idea that FBReader can be merged into XO as the current Read activity is mainly for PDF. The browser can be used as offline reader but still too heavy and not optimized for book reading. I am preparing an opie-reader for people to try, along with some sample ebooks of mine. IMHO it's far better than fbreader. Though they are currently working on the search result display. They tried to parsed the xml in their engine for better performance in stead of the whole LAMP but not complete yet. You can try the above link. There was an interesting article on slashdot this week about offline wikipedia. It currently is 2.9 Gb, I am sure with better compression it could be made to fit on a 2 Gb USB stick. But that would only be usefull for englsh speaking countries. It's best to work on ebook reading than on the wikipedia IMHO. The picture book looks best to me when rotated in 90 deg. It's just need some optimization on the page layout (remove menu frame) and some javascript for hotkey to flip pages. Or maybe FBReader serves better here? I am currently evaluating different tools (back at home with full net access and wifi !) As soon as I will have found a good setup, I will let you know Guylhem ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: some first impressions
On 8/18/07, Guylhem Aznar [EMAIL PROTECTED] wrote: Jim said the SD port was not for removable media use - I fully But then the current slot is not fulfilling either goals. It's hard to use, and still open for the water to get it. Maybe the plastic could There are lots of holes on the panel. I'm not sure if the holes for speakers and mic are water proof? Also the USB connectors are exposed when bunny ears are open for normal use. If we only consider the ears sealed case, then one way would be to move the SD slot under one of them? Tried FBReader on XO. It needs some fine tuning for XO's special I am preparing an opie-reader for people to try, along with some sample ebooks of mine. IMHO it's far better than fbreader. That's of great news. I forgot to mentioned that I've made an RPM package for latest version of FBReader. If you'd like you can access from here: http://hep1.phys.ntu.edu.tw/~john/olpc/fbreader-0.8.6a-1.fc7.i386.rpm http://hep1.phys.ntu.edu.tw/~john/olpc/fbreader-0.8.6a-1.fc7.src.rpm Though they are currently working on the search result display. They There was an interesting article on slashdot this week about offline wikipedia. It currently is 2.9 Gb, I am sure with better compression it could be made to fit on a 2 Gb USB stick. But that would only be usefull for englsh speaking countries. I've read that article too. However, it's only of title search and one still needs php, perl... installed to use it. The target for ksana group is to provide a single program with search engine and web server and they can do full-text search now. The performance would be a key issue for XO. I recall that for their english wiki indexed db is around 2.2GB level. It also works with other locales as you can see from their website. Though it's not an open source program yet, I heard that it would be released as open source soon. As soon as I will have found a good setup, I will let you know Thank you. Looking forward to hear more from you. :) -- Best regards, Yuan Chao ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: some first impressions
Yuan Chao wrote: On 8/18/07, Guylhem Aznar [EMAIL PROTECTED] wrote: Jim said the SD port was not for removable media use - I fully But then the current slot is not fulfilling either goals. It's hard to use, and still open for the water to get it. Maybe the plastic could There are lots of holes on the panel. I'm not sure if the holes for speakers and mic are water proof? Also the USB connectors are exposed when bunny ears are open for normal use. If we only consider the ears sealed case, then one way would be to move the SD slot under one of them? The PCB layout is highly constrained. The issue of where to put the SD card was studied at great length. Any further suggestions about it are not particularly welcome. The mechanical design is very nearly frozen solid at this stage. Sorry to be blunt, but this issue has been beaten to death, and then some. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: some first impressions
I've tried one SD card made by a local company. It's a bit thinker than the genuine panasonic one. So this results in that it can only be ejected out a bit and I have to use my finger nail to grab it out. (probably same situation as you) Usually there's a groove at the tail of an SD card top side. However, the access on XO SD slot is only on the bottom side... :( I tried a handy SD card in my system. I have a B2 case with a B3 board. There are a rubber flaps covering the entrance hole. The flaps are pointed in, so inserting the card bends the flaps open but extracting the card tries to close the flaps. If they stick (and they do) then closing the flaps makes them stick even more. I think the basic problem is that the flaps stick harder than the internal spring pushes. You can feel them if you poke the card in partway and then pull it out. My SD card has a grove on the edge of the card. It's about the right size for a fingernail. The XO case has a slight indentation for your finger. Unfortunately, it's on the bottom rather than the top so I can't get at the grove in the card. Mumble. Better have a pair of tweezers handy if you expect to use the SD slot. -- These are my opinions, not necessarily my employer's. I hate spam. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: some first impressions
Arjun, 1) eToys: It would be very nice to have support for Analog Input in eToys. You could use my code - See http://dev.laptop.org/git?p=projects/measure;a=blob_plain;f=audioGrab.py;hb=HEAD (getting samples) and http://dev.laptop.org/git?p=projects/measure;a=blob_plain;f=buttons.py;hb=HEAD (toggling between AC/DC modes and controlling bias voltage etc.) Or I could easily provide you with a class that you could use. I could make functions in that class that could simply return to you the required values. For example there could be a function that you could call to return avg voltage or rms voltage, select between ac/dc modes, set bias_on, set bias_off. Let me know if I can help in any way. Thank you. As I wrote on http://dev.laptop.org/ticket/2800, what we would like to have is C functions. Then, I can wrap them as Squeak primitives. Probably I can just rip these functions from amixer, but if you can tell me which, that would be good! -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: some first impressions
Yoshiki Ohshima wrote: Arjun, 1) eToys: It would be very nice to have support for Analog Input in eToys. You could use my code - See http://dev.laptop.org/git?p=projects/measure;a=blob_plain;f=audioGrab.py;hb=HEAD (getting samples) and http://dev.laptop.org/git?p=projects/measure;a=blob_plain;f=buttons.py;hb=HEAD (toggling between AC/DC modes and controlling bias voltage etc.) Or I could easily provide you with a class that you could use. I could make functions in that class that could simply return to you the required values. For example there could be a function that you could call to return avg voltage or rms voltage, select between ac/dc modes, set bias_on, set bias_off. Let me know if I can help in any way. Thank you. As I wrote on http://dev.laptop.org/ticket/2800, what we would like to have is C functions. Then, I can wrap them as Squeak primitives. Probably I can just rip these functions from amixer, but if you can tell me which, that would be good! This is the relevant excerpt from the reference cited above. The correspondence between this and C code should be obvious (os.system() - system()), and it also implicitly answers the second question too. def ac_dc(self, data=None): if(self.Acdc==ac): self.Acdc=dc self.button1.set_label(Measure AC) os.system(amixer set 'Analog Input' unmute) os.system(amixer set 'Mic' 20%, 0% unmute captur) os.system(amixer set 'Capture' 0%, 0% unmute captur) os.system(amixer set 'Mic Boost (+20dB)' mute) else: self.Acdc=ac self.button1.set_label(Measure DC) os.system(amixer set 'Analog Input' mute) os.system(amixer set 'Mic' 20%, 100% unmute captur) os.system(amixer set 'Capture' 100%, 100% unmute captur) os.system(amixer set 'Mic Boost (+20dB)' unmute) def bias(self, data=None): if(self.Bias==bias_on): self.Bias=bias_off self.button2.set_label(Set bias on ) os.system(amixer set 'V_REFOUT Enable' mute) else: self.Bias=bias_on self.button2.set_label(Set Bias off) os.system(amixer set 'V_REFOUT Enable' unmute) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: some first impressions
Mitch, Thank you. As I wrote on http://dev.laptop.org/ticket/2800, what we would like to have is C functions. Then, I can wrap them as Squeak primitives. Probably I can just rip these functions from amixer, but if you can tell me which, that would be good! This is the relevant excerpt from the reference cited above. The correspondence between this and C code should be obvious (os.system() - system()), and it also implicitly answers the second question too. Yes, I know. But calling system() is not quite nice in various ways. I'd rather would like to have a minimal C-code that can be a part of the Squeak VM. -- Yoshiki def ac_dc(self, data=None): if(self.Acdc==ac): self.Acdc=dc self.button1.set_label(Measure AC) os.system(amixer set 'Analog Input' unmute) os.system(amixer set 'Mic' 20%, 0% unmute captur) os.system(amixer set 'Capture' 0%, 0% unmute captur) os.system(amixer set 'Mic Boost (+20dB)' mute) else: self.Acdc=ac self.button1.set_label(Measure DC) os.system(amixer set 'Analog Input' mute) os.system(amixer set 'Mic' 20%, 100% unmute captur) os.system(amixer set 'Capture' 100%, 100% unmute captur) os.system(amixer set 'Mic Boost (+20dB)' unmute) def bias(self, data=None): if(self.Bias==bias_on): self.Bias=bias_off self.button2.set_label(Set bias on ) os.system(amixer set 'V_REFOUT Enable' mute) else: self.Bias=bias_on self.button2.set_label(Set Bias off) os.system(amixer set 'V_REFOUT Enable' unmute) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: some first impressions
It might be nice if there were a driver to access the GPIO, but I didn't see one in a quick scan of the kernel source. It turns out that there is a GPIO driver - the source is in char/drivers/cs5535_gpio.c - and it is available as a kernel module: modprobe cs5535_gpio However, nobody that I asked knows how to use it (it doesn't appear in /dev/ after you modprobe it, and the correspondence between write() calls to that driver and specific operations on the GPIO register block isn't clear). And in any case, accessing this behind alsamixer's back is not a good idea, because then alsamixer will be confused about the state. All in all, I think it's better to call alsamixer to do the work, so the state remains consistent between applications. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: some first impressions
It turns out that there is a GPIO driver - the source is in char/drivers/cs5535_gpio.c - and it is available as a kernel module: And in any case, accessing this behind alsamixer's back is not a good idea, because then alsamixer will be confused about the state. Hmm, ok. We sure don't want to give the Squeak VM more permission that it should have, and as you said, bypassing alsamixer wouldn't be good either. For now, we can try it with calls to system(), assuming the other environment variables for the etoys command invocation is sane. I haven't seen anyone comment yet on how this is interacting with the rainbow-iz-ation of activities - seems to me that audio mixer calls (and anything else that pokes at the kernel) are something that probably ought not be accessible to just any old activity... are they? --e ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: some first impressions
Mitch, There are ALSA controls defined for the analog input features. So we already have driver support. - Jim On Thu, 2007-08-16 at 09:24 -1000, Mitch Bradley wrote: Yoshiki Ohshima wrote: Mitch, Thank you. As I wrote on http://dev.laptop.org/ticket/2800, what we would like to have is C functions. Then, I can wrap them as Squeak primitives. Probably I can just rip these functions from amixer, but if you can tell me which, that would be good! This is the relevant excerpt from the reference cited above. The correspondence between this and C code should be obvious (os.system() - system()), and it also implicitly answers the second question too. Yes, I know. But calling system() is not quite nice in various ways. I'd rather would like to have a minimal C-code that can be a part of the Squeak VM. The controls in question reside in registers that cannot be accessed directly from userland programs The mechanisms for accessing those registers are rather dependent on the programming environment and its facilities for interacting with the OS. The AC/DC control is the 0x02 bit in the Cs5536 GPIO register.The GPIO output value register is a 32-bit register at location 0x1000 in I/O space. Conceptually, the operation you would have to perform is either: outl(0x02, 0x1000); // AC mode or outl(0x02 16, 0x1000); // DC mode The catch is that you can't do I/O space accesses from userland, unless a) You use iopl() to grant the process extra permissions b) You use ioperm() to grant access to specific I/O registers (which doesn't work in this case because the register number is too high) c) You access the I/O space via write() to /dev/port - which requires extra permissions to open. Which of these approaches is appropriate for your environement, I cannot guess. It might be nice if there were a driver to access the GPIO, but I didn't see one in a quick scan of the kernel source. The bias control is the 0x04 bit of codec register 0x76. Accessing codec registers requires a complicated dance involving some protected (in the sense that they are not trivially accessible from userland) registers in the AC97 hardware block. As far as I know, the only extant C code for twiddling those registers is the alsamixer code, which I presume that you can read as easily as we can. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: some first impressions
Apparently there is an alternative to calling amixer - you can use ALSA lib. http://www.alsa-project.org/main/index.php/ALSA_Library_API Jim Gettys wrote: Mitch, There are ALSA controls defined for the analog input features. So we already have driver support. - Jim On Thu, 2007-08-16 at 09:24 -1000, Mitch Bradley wrote: Yoshiki Ohshima wrote: Mitch, Thank you. As I wrote on http://dev.laptop.org/ticket/2800, what we would like to have is C functions. Then, I can wrap them as Squeak primitives. Probably I can just rip these functions from amixer, but if you can tell me which, that would be good! This is the relevant excerpt from the reference cited above. The correspondence between this and C code should be obvious (os.system() - system()), and it also implicitly answers the second question too. Yes, I know. But calling system() is not quite nice in various ways. I'd rather would like to have a minimal C-code that can be a part of the Squeak VM. The controls in question reside in registers that cannot be accessed directly from userland programs The mechanisms for accessing those registers are rather dependent on the programming environment and its facilities for interacting with the OS. The AC/DC control is the 0x02 bit in the Cs5536 GPIO register.The GPIO output value register is a 32-bit register at location 0x1000 in I/O space. Conceptually, the operation you would have to perform is either: outl(0x02, 0x1000); // AC mode or outl(0x02 16, 0x1000); // DC mode The catch is that you can't do I/O space accesses from userland, unless a) You use iopl() to grant the process extra permissions b) You use ioperm() to grant access to specific I/O registers (which doesn't work in this case because the register number is too high) c) You access the I/O space via write() to /dev/port - which requires extra permissions to open. Which of these approaches is appropriate for your environement, I cannot guess. It might be nice if there were a driver to access the GPIO, but I didn't see one in a quick scan of the kernel source. The bias control is the 0x04 bit of codec register 0x76. Accessing codec registers requires a complicated dance involving some protected (in the sense that they are not trivially accessible from userland) registers in the AC97 hardware block. As far as I know, the only extant C code for twiddling those registers is the alsamixer code, which I presume that you can read as easily as we can. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: some first impressions
Hello, OLCP just had a summer intern, Arjun Sarwal, who developed some low-cost gadgets to plug into the mic port - temperature sensor, intrusion detector, etc. He plans to document them and set up a framework for documenting other similar hacks. Ohh, that is cool. We would be happy to modify Etoys so that World Stethoscope in it supports this. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: some first impressions
On 8/11/07, Jameson Chema Quinn [EMAIL PROTECTED] wrote: I've archived this discussion on robotics/LED output, with some points of my own, on the wiki at http://wiki.laptop.org/go/Electrical_output. Thanks a lot for the summary on the wiki. A quick suggestion : if there is a serial port in the XO (according to the boot message, there is one) maybe it could also be used. rx/tx/gnd/vcc already allow a lot of fun stuff and experimentation. By the way, if there are other beginners out there, who are a bit lost in the wiki, http://wiki.laptop.org/go/Getting_started_programming is a great page to get started. There is too much information to read everything in one day, but so far I have found the following documents very interesting: (I'm new to python, but I know a little javascript) http://wiki.laptop.org/go/Understanding_sugar_code http://www.pygtk.org/dist/pygtk2-tut.pdf http://www.ibm.com/developerworks/linux/library/l-sugar-olpc/index.html http://downloads.egenix.com/python/LSM2005-Developing-Unicode-aware-applications-in-Python.pdf http://wiki.laptop.org/go/DCON This page however looks incomplete : turning the backlight back is impossible with the current instructions: -bash-3.2# cat /sys/class/backlight/dcon-bl/power 0 -bash-3.2# echo 1 /sys/class/backlight/dcon-bl/power -bash-3.2# cat /sys/class/backlight/dcon-bl/power 0 I guess I will have to look for more information since the sugar gui does it just fine. Regarding the underlying gnu/linux system, to explore how it all works together, my preferred method actually is ssh and console mode. To do that, type alt+m to get a terminal, then passwd root and passwd olpc to setup passwords for remote access. This also let you use the console on ctrl-alt-F1 (magnifier) or with chvt 1 Currently I am exploring a little more the fedora distribution, the hardware support, and I am doing some benchmarking, especially for power management stuff. Last night I found that closing the screen turns off networking, while keeping the mesh network (as specified), but does that until the battery is fully depleted. Wow. I wonder if a graceful suspend when there is say only 50% of battery power left wouldn't be nicer to the users. Else, kids who come to the same conclusion may prefer to fully turn off the laptop to have some power left to read books/play games/whatever in the bus after school etc. There should be a good equilibrium between the user own interest (having some power left) and the community interest (keeping the mesh network up) Also I noticed SHM support has been compiled in, but /dev/shm in not used. Is it by design? I couldn't find references on the wiki. /var /tmp and similar files could certainly live there to save some nand write cycles. Did that on the zaurus : you simply keep a tarball of a clean /var in / (say /.var.tar) which you untar as soon as the shm has been mounted. Before the shm is mounted, you keep a skeleton /dev/shm/var so that /var symlink is not broken and application which may depend on the existance of the directories won't be confused. Guylhem ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
