Raspberry Pi as comprehensive eLua solution ?
Locked
12
12
 
|
Patrick Mc(avery |
Raspberry Pi as comprehensive eLua solution ?
|
Hi Guys
The past few months have been difficult. It looks like daughter is also about to be diagnosed with Autism. The project I have been working on for my Son looked easier as a desktop solution, so I've ignored everything embedded. Now it looks viable as embedded and i am back again. i need to follow along with what is best for my kids and my business, i haven't been able to do anything just for my own interest. I hope to resume the screencast tutorials I started(or barely started)earlier in the year, sorry about the interruption. So enough rambling....I am planning on buying a Raspberry Pi for my son's project and it got me thinking about eLua. This device boots a full Linux desktop(LDXE). I was thinking that if I(or we) could rework a distro so that it ships with eLua, Nuccio's text editor, GCC, OpenOCD and any other useful tools, then it would provide a native build environment for many of the boards the project targets, GCC on arm is not a cross compiler! With a jtag programmer preconfigured via OpenOCD and it could also make for an easy environment to flash lighter weight ARM boards from. If it had SSH and/or NFS installed then it could also be used in tandem with a full power desktop. People could open remote directories for editing in their desktop computers and initiate commands via SSH(like gcc). This device also has 8 GPIO pins and could provide something to play with without the user having to be concerned about flashing at all. I have a couple of concerns. One the board is in short supply. Two, just because it's a Debian/Fedora ARM build environment might not make it suitable for all ARM targets. I don't know how much the various ARMs differ? Any thoughts on this on this project-Patrick _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Olimex will have good(better?) alternatives to Raspberry PI.
See their blog: http://olimex.wordpress.com/ On 5/13/12, Patrick <[hidden email]> wrote: > Hi Guys > > The past few months have been difficult. It looks like daughter is also > about to be diagnosed with Autism. The project I have been working on > for my Son looked easier as a desktop solution, so I've ignored > everything embedded. Now it looks viable as embedded and i am back > again. i need to follow along with what is best for my kids and my > business, i haven't been able to do anything just for my own interest. > > I hope to resume the screencast tutorials I started(or barely > started)earlier in the year, sorry about the interruption. > > > So enough rambling....I am planning on buying a Raspberry Pi for my > son's project and it got me thinking about eLua. > > This device boots a full Linux desktop(LDXE). I was thinking that if > I(or we) could rework a distro so that it ships with eLua, Nuccio's text > editor, GCC, OpenOCD and any other useful tools, then it would provide a > native build environment for many of the boards the project targets, GCC > on arm is not a cross compiler! > > With a jtag programmer preconfigured via OpenOCD and it could also make > for an easy environment to flash lighter weight ARM boards from. > > If it had SSH and/or NFS installed then it could also be used in tandem > with a full power desktop. People could open remote directories for > editing in their desktop computers and initiate commands via SSH(like gcc). > > This device also has 8 GPIO pins and could provide something to play > with without the user having to be concerned about flashing at all. > > I have a couple of concerns. > > One the board is in short supply. > > Two, just because it's a Debian/Fedora ARM build environment might not > make it suitable for all ARM targets. I don't know how much the various > ARMs differ? > > Any thoughts on this on this project-Patrick > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > -- Vasi _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Patrick Mc(avery |
Re: Raspberry Pi as comprehensive eLua solution ?
|
|
This looks very interesting. The fact that cad files are available is a
huge benefit. I wasn't able to find anywhere to buy it yet though? Is there someplace?-Patrick On 12-05-13 06:49 AM, vasi vasi wrote: > Olimex will have good(better?) alternatives to Raspberry PI. > See their blog: http://olimex.wordpress.com/ > > On 5/13/12, Patrick<[hidden email]> wrote: >> Hi Guys >> >> The past few months have been difficult. It looks like daughter is also >> about to be diagnosed with Autism. The project I have been working on >> for my Son looked easier as a desktop solution, so I've ignored >> everything embedded. Now it looks viable as embedded and i am back >> again. i need to follow along with what is best for my kids and my >> business, i haven't been able to do anything just for my own interest. >> >> I hope to resume the screencast tutorials I started(or barely >> started)earlier in the year, sorry about the interruption. >> >> >> So enough rambling....I am planning on buying a Raspberry Pi for my >> son's project and it got me thinking about eLua. >> >> This device boots a full Linux desktop(LDXE). I was thinking that if >> I(or we) could rework a distro so that it ships with eLua, Nuccio's text >> editor, GCC, OpenOCD and any other useful tools, then it would provide a >> native build environment for many of the boards the project targets, GCC >> on arm is not a cross compiler! >> >> With a jtag programmer preconfigured via OpenOCD and it could also make >> for an easy environment to flash lighter weight ARM boards from. >> >> If it had SSH and/or NFS installed then it could also be used in tandem >> with a full power desktop. People could open remote directories for >> editing in their desktop computers and initiate commands via SSH(like gcc). >> >> This device also has 8 GPIO pins and could provide something to play >> with without the user having to be concerned about flashing at all. >> >> I have a couple of concerns. >> >> One the board is in short supply. >> >> Two, just because it's a Debian/Fedora ARM build environment might not >> make it suitable for all ARM targets. I don't know how much the various >> ARMs differ? >> >> Any thoughts on this on this project-Patrick >> _______________________________________________ >> eLua-dev mailing list >> [hidden email] >> https://lists.berlios.de/mailman/listinfo/elua-dev >> > _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Martin Guy |
Re: Raspberry Pi as comprehensive eLua solution ?
|
|
On 13 May 2012 16:40, Patrick <[hidden email]> wrote:
> This looks very interesting. The fact that cad files are available is a huge > benefit. eLua's answer to any board that runs Linux is "run Linux on it and install Lua, since the Linux kernel already has drivers for GPIO pins and everything else. You just access them as special files under /proc or /sys If you want an open hardware solution eLua with CAD files that is also available to buy, why not give us a hand by using Mizar32? M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Thiago Naves |
Re: Raspberry Pi as comprehensive eLua solution ?
|
|
In reply to this post by Patrick Mc(avery
According to their blog, it looks like the didn't even receive the first prototypes yet... The I.mx233 runs at 454 MHz max while the raspberry runs at 700MHz I think...so I don't think it will be better. The imx233 is also the mcu on the chumby hacker board...(this mcu is quite nice btw) Best, >> _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Martin Guy
On Sunday, May 13, 2012 at 11:05, Martin Guy wrote:
To add to this the low level hardware details are NDA only, so it would be difficult to support this platform with eLua on the bare metal. It might be nice to see Lua bindings for the Linux APIs that are available, though.
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Patrick Mc(avery
Hi Patrick,
On Sun, May 13, 2012 at 12:54 AM, Patrick <[hidden email]> wrote: > Hi Guys > > The past few months have been difficult. It looks like daughter is also > about to be diagnosed with Autism. Sorry to hear that :( I wish the best of luck to you and your daughter. > The project I have been working on for my > Son looked easier as a desktop solution, so I've ignored everything > embedded. Now it looks viable as embedded and i am back again. i need to > follow along with what is best for my kids and my business, i haven't been > able to do anything just for my own interest. > > I hope to resume the screencast tutorials I started(or barely > started)earlier in the year, sorry about the interruption. > > > So enough rambling....I am planning on buying a Raspberry Pi for my son's > project and it got me thinking about eLua. I got a Raspberry coming my way too :) > > This device boots a full Linux desktop(LDXE). I was thinking that if I(or > we) could rework a distro so that it ships with eLua, Nuccio's text editor, > GCC, OpenOCD and any other useful tools, then it would provide a native > build environment for many of the boards the project targets, GCC on arm is > not a cross compiler! You can't have a distribution with both eLua and GCC/OpenOCD. GCC needs an OS (like Linux) to run on, eLua is itself a mini-and-extremely-basic-OS (and you certainly won't be able to run GCC on top of eLua :) ). You could probably find a virtualization setup suitable for this task, but where's the fun in that? GCC on ARM is indeed not a cross-compiler, but this isn't an issue at all. Cross compilers make as good of a job as native compilers do. > > With a jtag programmer preconfigured via OpenOCD and it could also make for > an easy environment to flash lighter weight ARM boards from. This would be indeed an interesting project, but again, it would have to run under Linux. While it's probably possible to make OpenOCD run on bare metal, I can't see an advantage to this. > > If it had SSH and/or NFS installed then it could also be used in tandem with > a full power desktop. People could open remote directories for editing in > their desktop computers and initiate commands via SSH(like gcc). > > This device also has 8 GPIO pins and could provide something to play with > without the user having to be concerned about flashing at all. And that's the main problem with this category of devices. They are built around CPUs, not MCUs, so you loose the convenience of using on-chip peripherals (like PWM, UARTs and so on) from the start. Sure, you can add everything you need over USB and other interfaces, but at that point it really doesn't make much sense to use the board as a bare metal platform (working an USB drivers alone is a huge PITA). On a somewhat related topic, don't even get me started on their extremely bizarre NDA policy (I'm really struggling to keep a polite tone right now). I refuse to work with manufacturers who release a CPU/MCU and refuse to make the documentation public, as if you could do anything at all with that chip without documentation (and actually getting the documentation involves a lot of time, effort and maybe even lawyers)). This simply doesn't make any sense at all in my engineerish mind and thus I choose to not have anything to do with it. > > I have a couple of concerns. > > One the board is in short supply. > > Two, just because it's a Debian/Fedora ARM build environment might not make > it suitable for all ARM targets. I don't know how much the various ARMs > differ? You needn't worry about that. Cross compilers are available on all Linux distros that I know of and they are very good at their job. The ARMs can differ quite a bit, but that's for the compiler to worry about (most of the time :) ). All in all, I'd second Martin's oppinion: get a Mizar32 (or other board that supports eLua), you're likely to get a much more pleasant experience as far as eLua is concerned. Best, Bogdan > > Any thoughts on this on this project-Patrick > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Patrick Mc(avery |
Re: Raspberry Pi as comprehensive eLua solution ?
|
|
Hi Bogdan
I am feeling silly about my post now. Of course eLua runs on bare metal and not under an OS, DUH! What I should have said, is "could eLua run under an OS" but having thought this through a little more, this is equally stupid. Why take a complex, feature rich code base and rip out features until your left with what... the ability to control 8 GPIO pins, an LED and maybe a TCP/IP stack? not an intelligent use of time... So would this be sensible... Assuming that these boards(Olimex/BeagleBoard/Raspberry PI etc) have C libraries for their limited peripherals, would it be sensible to write Lua bindings for them? It could be a totally different code base but retain the same API, a sort of eLua-Lite. Here is a bit of my workflow and logic(if it's okay to call it that!). Using WebBuilder and CuteCom, I've written some simple blink like programs. I am sure WebBuilder can do much more then this and it's just my limited time that's the issue..... I sometimes download other people's .BIN files. When I do, I have to copy them to a USB key, go downstairs, Boot up a Windoze 2000 machine and use the piece-o-sh*t, proprietary Luminary program to flash my board. I have a JTAG pod on it's way and I hope to set up a cross compiler soon but so far in the limited time I have been able to spend on the project flashing has been an issue and adding C code to a project looks like it will take some time. I was thinking that if eLua-Lite was as easy as installing a deb package or downloading from a repository, then someone could have an LED blinking in under a minute as eLua-Lite is already running on the target. Other features such as a cross compiler could be included as well. Someone could play with the eLua like features and then start flashing a real target via JTAG right from the first board and then pretty soon just dump eLua-Lite and use the real thing. The only benefit I see here is a lower barrier to entry but I think that is still worth something. More logical? or should I get back to my crack pipe? :) On 12-05-14 05:11 AM, Bogdan Marinescu wrote: > Hi Patrick, > > On Sun, May 13, 2012 at 12:54 AM, Patrick > <[hidden email]> wrote: >> Hi Guys >> >> The past few months have been difficult. It looks like daughter is also >> about to be diagnosed with Autism. > Sorry to hear that :( I wish the best of luck to you and your daughter. > >> The project I have been working on for my >> Son looked easier as a desktop solution, so I've ignored everything >> embedded. Now it looks viable as embedded and i am back again. i need to >> follow along with what is best for my kids and my business, i haven't been >> able to do anything just for my own interest. >> >> I hope to resume the screencast tutorials I started(or barely >> started)earlier in the year, sorry about the interruption. >> >> >> So enough rambling....I am planning on buying a Raspberry Pi for my son's >> project and it got me thinking about eLua. > I got a Raspberry coming my way too :) > >> This device boots a full Linux desktop(LDXE). I was thinking that if I(or >> we) could rework a distro so that it ships with eLua, Nuccio's text editor, >> GCC, OpenOCD and any other useful tools, then it would provide a native >> build environment for many of the boards the project targets, GCC on arm is >> not a cross compiler! > You can't have a distribution with both eLua and GCC/OpenOCD. GCC > needs an OS (like Linux) to run on, eLua is itself a > mini-and-extremely-basic-OS (and you certainly won't be able to run > GCC on top of eLua :) ). You could probably find a virtualization > setup suitable for this task, but where's the fun in that? GCC on ARM > is indeed not a cross-compiler, but this isn't an issue at all. Cross > compilers make as good of a job as native compilers do. > >> With a jtag programmer preconfigured via OpenOCD and it could also make for >> an easy environment to flash lighter weight ARM boards from. > This would be indeed an interesting project, but again, it would have > to run under Linux. While it's probably possible to make OpenOCD run > on bare metal, I can't see an advantage to this. > >> If it had SSH and/or NFS installed then it could also be used in tandem with >> a full power desktop. People could open remote directories for editing in >> their desktop computers and initiate commands via SSH(like gcc). >> >> This device also has 8 GPIO pins and could provide something to play with >> without the user having to be concerned about flashing at all. > And that's the main problem with this category of devices. They are > built around CPUs, not MCUs, so you loose the convenience of using > on-chip peripherals (like PWM, UARTs and so on) from the start. Sure, > you can add everything you need over USB and other interfaces, but at > that point it really doesn't make much sense to use the board as a > bare metal platform (working an USB drivers alone is a huge PITA). On > a somewhat related topic, don't even get me started on their extremely > bizarre NDA policy (I'm really struggling to keep a polite tone right > now). I refuse to work with manufacturers who release a CPU/MCU and > refuse to make the documentation public, as if you could do anything > at all with that chip without documentation (and actually getting the > documentation involves a lot of time, effort and maybe even lawyers)). > This simply doesn't make any sense at all in my engineerish mind and > thus I choose to not have anything to do with it. > >> I have a couple of concerns. >> >> One the board is in short supply. >> >> Two, just because it's a Debian/Fedora ARM build environment might not make >> it suitable for all ARM targets. I don't know how much the various ARMs >> differ? > You needn't worry about that. Cross compilers are available on all > Linux distros that I know of and they are very good at their job. The > ARMs can differ quite a bit, but that's for the compiler to worry > about (most of the time :) ). > All in all, I'd second Martin's oppinion: get a Mizar32 (or other > board that supports eLua), you're likely to get a much more pleasant > experience as far as eLua is concerned. > > Best, > Bogdan > >> Any thoughts on this on this project-Patrick >> _______________________________________________ >> eLua-dev mailing list >> [hidden email] >> https://lists.berlios.de/mailman/listinfo/elua-dev > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Martin Guy |
Re: Raspberry Pi as comprehensive eLua solution ?
|
|
On 16 May 2012 15:06, Patrick <[hidden email]> wrote:
> What I should have said, is "could eLua run under an OS" Yes. Implement a new system target "Linux" that implements as many of the platform functions as it can using system calls, device files and standard libraries. The interesting part is how you name that as a board or platform or cpu or something else in the build system, as it should be cpu-independent. Why you would want to do that, instead of adding a gpio.*() C library etc to standard Lua to also have LFS, luasocket and the rest of the Luarocks libraries available, is another question... M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Patrick Mc(avery |
Re: Raspberry Pi as comprehensive eLua solution ?
|
|
On 12-05-16 09:48 AM, Martin Guy wrote:
> On 16 May 2012 15:06, Patrick<[hidden email]> wrote: >> What I should have said, is "could eLua run under an OS" > Yes. Implement a new system target "Linux" that implements as many of > the platform functions as it can using system calls, device files and > standard libraries. The interesting part is how you name that as a > board or platform or cpu or something else in the build system, as it > should be cpu-independent. > Why you would want to do that, instead of adding a gpio.*() C > library etc to standard Lua to also have LFS, luasocket and the rest > of the Luarocks libraries available, is another question... > My time is not my own and as my business and family needs change, eLua is coming in and out of focus. I am working on a project for my Son who has Autism. I have to complete it but all the technical details are worked out. It's a talking keyboard that works as an assistive speech device. It's a QWERTY keyboard but there are news key symbols on top, there is a key for the "SH" sound for instance. Anyhow, I want to make a portable version of it. It's basically a desktop application, it uses gstreamer. Using one of these Linux capable boards will make it portable. Having some GPIO lines could be fun too. I could also make some iterative games with just 8 lines and an led screen. I wanted to use eLua for some firmware hacking on the scientific instruments I have here for my work but they are all based on 16 bit CPUs and the few that are microcontroller based are not 32 bit. My Son's project is too heavy for a microcontroller, unless someone knows of an audio library that could be embedded on an eLua supported target? My work and family needs are not a good match for eLua right now but I would like to help with the project if there is anything that meshes. Thanks BTW I am desperately short of time and unlikely to be of much help but I would be willing to buy some Mizar gear, stock it here and ship it to your customers. You could then replace my purchases that I shipped out. I don't ship everyday and can't make special trips to my UPS store for this but if the end user can tolerate a 3-4 day wait time before shipment, I could do this. Probably much faster then waiting for postal service from Italy or paying for trans-Atlantic courier service though... _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Patrick Mc(avery |
Re: Raspberry Pi as comprehensive eLua solution ?
|
|
In reply to this post by Martin Guy
On 12-05-16 09:48 AM, Martin Guy wrote:
> On 16 May 2012 15:06, Patrick<[hidden email]> wrote: >> What I should have said, is "could eLua run under an OS" > Yes. Implement a new system target "Linux" that implements as many of > the platform functions as it can using system calls, device files and > standard libraries. The interesting part is how you name that as a > board or platform or cpu or something else in the build system, as it > should be cpu-independent. > Why you would want to do that, instead of adding a gpio.*() C > library etc to standard Lua to also have LFS, luasocket and the rest > of the Luarocks libraries available, is another question... > > M > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > in the last long post..... yes, there would be easier ways to get this done by adding onto Lua and it's libraries. Maybe that is still the thing to do. However if this could be structured to have the maximum benefit for the real eLua project that would be better. I am not sure how many libraries could be reused between the two but that would probably make for a more seamless transition between two even if it was not the easiest path. _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Patrick Mc(avery
Hi Patrick,
Hi Bogdan The Beagles (BeagleBoard and BeagleBone) actually have substantial peripherals, including PWM, QEPs, I2C, SPI, and (on the BeagleBoard) a DSP. TI has a new bare metal solution, StarterWare, for select MCUs, including the AM3358 used on the BeagleBone, so the 'Bone could make an excellent eLua board. I have an 'Bone (from ESC West, thanks, TI), but unfortunately no time...yet. Standarized, eLua-compatible libraries for Lua on Linux (or uCLinux) on boards with good peripherals is an interesting idea, except most boards that run Linux have limited peripherals.... I totally know about lack of time; I have a wife & two young kids, and they do need a lot of care & feeding...and with what time I have left I'm currently working on stuff (brushless servo motion control) closer to my day job. I don't want to get too off topic, but if you need low power audio, check out audio oriented DSP's, such as ADI's Blackfin, TI's C5x, and probably others. I know TI has a low cost C5535 dev kit, the Blackfin has a lot of open source (hardware & software) support, there probably are free codecs available, etc... Programming will be more difficult (C/C++), but power consumption should be much lower than a RPi. Some models have enough memory to run eLua (or have external memory interfaces). Good luck & don't feel guilty, --Tony
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Patrick Mc(avery
On Wednesday, May 16, 2012 at 9:06, Patrick wrote:
Sure. A module could be installable as a regular lua rock (package).
It is possible to use openocd though it could be easier and I think our instructions need updating. Also, my personal solution for flashing when all-else-fails under anything but windows is a VM in virtual box which generally has worked well, though is an annoying crutch it's a bit better than firing up old hardware especially with shared drive access.
The luminary board should also have a built-in ftdi-based jtag interface, which is what the windows flash tool uses.
Sure.
Sure. We do actually have a sort of "simulator" build that runs on x86. But it's really rudimentary and doesn't really talk to hardware at all. If I recall it might even be somewhat sandboxed because it still uses newlib. I think building a lua HAL on top of Lua that matches eLua's API would make a nice platform for testing and perhaps building projects, and adds another platform that code written for eLua could work on.
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Patrick Mc(avery
Hi,
On Wed, May 16, 2012 at 4:06 PM, Patrick <[hidden email]> wrote: > Hi Bogdan > > I am feeling silly about my post now. Of course eLua runs on bare metal and > not under an OS, DUH! > > What I should have said, is "could eLua run under an OS" but having thought > this through a little more, this is equally stupid. Why take a complex, > feature rich code base and rip out features until your left with what... the > ability to control 8 GPIO pins, an LED and maybe a TCP/IP stack? not an > intelligent use of time... This is exactly my problem too. Especially when it comes to networking, when Linux has a full stack which is light years better than what eLua can do at the moment. > > So would this be sensible... > > Assuming that these boards(Olimex/BeagleBoard/Raspberry PI etc) have C > libraries for their limited peripherals, would it be sensible to write Lua > bindings for them? It does, yes. Except you won't be writing bindings for them directly, you'd write bindings for whatever driver the kernel uses for them. Fortunately, the kernel driver base is very good, although the way they choose to expose some I/O functionality (for example via files in /dev) can sometimes feel unnatural (at least to me). > > It could be a totally different code base but retain the same API, a sort of > eLua-Lite. You won't be able to retain the same API, unfortunately. For example, everything that has to do with interrupts will go away instantly, since that is handled by the kernel. Many other functions in various libraries will have to change too. > > Here is a bit of my workflow and logic(if it's okay to call it that!). > > Using WebBuilder and CuteCom, I've written some simple blink like programs. > I am sure WebBuilder can do much more then this and it's just my limited > time that's the issue..... > > I sometimes download other people's .BIN files. When I do, I have to copy > them to a USB key, go downstairs, Boot up a Windoze 2000 machine and use the > piece-o-sh*t, proprietary Luminary program to flash my board. Yes, I know how that feels ... There are ways to flash even those boards from Linux though, you just have to dig on the net a bit (I don't have a link right now, otherwise I would've given it to you). > > I have a JTAG pod on it's way and I hope to set up a cross compiler soon but > so far in the limited time I have been able to spend on the project flashing > has been an issue and adding C code to a project looks like it will take > some time. Why would you need to setup a cross compiler yourself? Just use CodeSourcery's (now Mentor Graphics) lite edition cross compiler packages and you can cross an item from your TODO list. > > I was thinking that if eLua-Lite was as easy as installing a deb package or > downloading from a repository, then someone could have an LED blinking in > under a minute as eLua-Lite is already running on the target. Other features > such as a cross compiler could be included as well. What you say makes a lot of sense, but mainly in the form of standard Lua C modules used with stock Lua. There's really no need to use eLua for this stuff as far as I can see. BTW, this would be a very nice project. The Raspberry Pi was designed (amongst other things) to be a Python development machine, but I have a very strong feeling that it would be much better used as a Lua development machine. I'd start this project myself if I had the time ... > > Someone could play with the eLua like features and then start flashing a > real target via JTAG right from the first board and then pretty soon just > dump eLua-Lite and use the real thing. Sadly, I can't see this happening, as we can't provide a fully compatible API (as explained). > > The only benefit I see here is a lower barrier to entry but I think that is > still worth something. > > More logical? or should I get back to my crack pipe? :) I believed I covered the "logical" part. As for your crack pipe ... you know what they say, sharing is good for your soul :D Best, Bogdan > > > > > > > > > > > On 12-05-14 05:11 AM, Bogdan Marinescu wrote: >> >> Hi Patrick, >> >> On Sun, May 13, 2012 at 12:54 AM, Patrick >> <[hidden email]> wrote: >>> >>> Hi Guys >>> >>> The past few months have been difficult. It looks like daughter is also >>> about to be diagnosed with Autism. >> >> Sorry to hear that :( I wish the best of luck to you and your daughter. >> >>> The project I have been working on for my >>> Son looked easier as a desktop solution, so I've ignored everything >>> embedded. Now it looks viable as embedded and i am back again. i need to >>> follow along with what is best for my kids and my business, i haven't >>> been >>> able to do anything just for my own interest. >>> >>> I hope to resume the screencast tutorials I started(or barely >>> started)earlier in the year, sorry about the interruption. >>> >>> >>> So enough rambling....I am planning on buying a Raspberry Pi for my son's >>> project and it got me thinking about eLua. >> >> I got a Raspberry coming my way too :) >> >>> This device boots a full Linux desktop(LDXE). I was thinking that if I(or >>> we) could rework a distro so that it ships with eLua, Nuccio's text >>> editor, >>> GCC, OpenOCD and any other useful tools, then it would provide a native >>> build environment for many of the boards the project targets, GCC on arm >>> is >>> not a cross compiler! >> >> You can't have a distribution with both eLua and GCC/OpenOCD. GCC >> needs an OS (like Linux) to run on, eLua is itself a >> mini-and-extremely-basic-OS (and you certainly won't be able to run >> GCC on top of eLua :) ). You could probably find a virtualization >> setup suitable for this task, but where's the fun in that? GCC on ARM >> is indeed not a cross-compiler, but this isn't an issue at all. Cross >> compilers make as good of a job as native compilers do. >> >>> With a jtag programmer preconfigured via OpenOCD and it could also make >>> for >>> an easy environment to flash lighter weight ARM boards from. >> >> This would be indeed an interesting project, but again, it would have >> to run under Linux. While it's probably possible to make OpenOCD run >> on bare metal, I can't see an advantage to this. >> >>> If it had SSH and/or NFS installed then it could also be used in tandem >>> with >>> a full power desktop. People could open remote directories for editing in >>> their desktop computers and initiate commands via SSH(like gcc). >>> >>> This device also has 8 GPIO pins and could provide something to play with >>> without the user having to be concerned about flashing at all. >> >> And that's the main problem with this category of devices. They are >> built around CPUs, not MCUs, so you loose the convenience of using >> on-chip peripherals (like PWM, UARTs and so on) from the start. Sure, >> you can add everything you need over USB and other interfaces, but at >> that point it really doesn't make much sense to use the board as a >> bare metal platform (working an USB drivers alone is a huge PITA). On >> a somewhat related topic, don't even get me started on their extremely >> bizarre NDA policy (I'm really struggling to keep a polite tone right >> now). I refuse to work with manufacturers who release a CPU/MCU and >> refuse to make the documentation public, as if you could do anything >> at all with that chip without documentation (and actually getting the >> documentation involves a lot of time, effort and maybe even lawyers)). >> This simply doesn't make any sense at all in my engineerish mind and >> thus I choose to not have anything to do with it. >> >>> I have a couple of concerns. >>> >>> One the board is in short supply. >>> >>> Two, just because it's a Debian/Fedora ARM build environment might not >>> make >>> it suitable for all ARM targets. I don't know how much the various ARMs >>> differ? >> >> You needn't worry about that. Cross compilers are available on all >> Linux distros that I know of and they are very good at their job. The >> ARMs can differ quite a bit, but that's for the compiler to worry >> about (most of the time :) ). >> All in all, I'd second Martin's oppinion: get a Mizar32 (or other >> board that supports eLua), you're likely to get a much more pleasant >> experience as far as eLua is concerned. >> >> Best, >> Bogdan >> >>> Any thoughts on this on this project-Patrick >>> _______________________________________________ >>> eLua-dev mailing list >>> [hidden email] >>> https://lists.berlios.de/mailman/listinfo/elua-dev >> >> _______________________________________________ >> eLua-dev mailing list >> [hidden email] >> https://lists.berlios.de/mailman/listinfo/elua-dev >> > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Tony-12
On Wed, May 16, 2012 at 8:20 PM, Tony <[hidden email]> wrote:
> Hi Patrick, > >> Hi Bogdan >> >> I am feeling silly about my post now. Of course eLua runs on bare metal >> and not under an OS, DUH! >> >> What I should have said, is "could eLua run under an OS" but having >> thought this through a little more, this is equally stupid. Why take a >> complex, feature rich code base and rip out features until your left with >> what... the ability to control 8 GPIO pins, an LED and maybe a TCP/IP stack? >> not an intelligent use of time... >> >> So would this be sensible... >> >> Assuming that these boards(Olimex/BeagleBoard/Raspberry PI etc) have C >> libraries for their limited peripherals, would it be sensible to write Lua >> bindings for them? > > > The Beagles (BeagleBoard and BeagleBone) actually have substantial > peripherals, including PWM, QEPs, I2C, SPI, and (on the BeagleBoard) a DSP. Thanks, I didn't know that. I knew they had some peripherals, but not that many. > > TI has a new bare metal solution, StarterWare, for select MCUs, including > the AM3358 used on the BeagleBone, so the 'Bone could make an excellent eLua > board. I have an 'Bone (from ESC West, thanks, TI), but unfortunately no > time...yet. This is indeed a very interesting target, You know, I wonder if ... *scracthes head* Best, Bogdan > > Standarized, eLua-compatible libraries for Lua on Linux (or uCLinux) on > boards with good peripherals is an interesting idea, except most boards that > run Linux have limited peripherals.... > > I totally know about lack of time; I have a wife & two young kids, and they > do need a lot of care & feeding...and with what time I have left I'm > currently working on stuff (brushless servo motion control) closer to my day > job. > > I don't want to get too off topic, but if you need low power audio, check > out audio oriented DSP's, such as ADI's Blackfin, TI's C5x, and probably > others. I know TI has a low cost C5535 dev kit, the Blackfin has a lot of > open source (hardware & software) support, there probably are free codecs > available, etc... Programming will be more difficult (C/C++), but power > consumption should be much lower than a RPi. Some models have enough memory > to run eLua (or have external memory interfaces). > > Good luck & don't feel guilty, > --Tony >> >> >> It could be a totally different code base but retain the same API, a sort >> of eLua-Lite. >> >> Here is a bit of my workflow and logic(if it's okay to call it that!). >> >> Using WebBuilder and CuteCom, I've written some simple blink like >> programs. I am sure WebBuilder can do much more then this and it's just my >> limited time that's the issue..... >> >> I sometimes download other people's .BIN files. When I do, I have to copy >> them to a USB key, go downstairs, Boot up a Windoze 2000 machine and use the >> piece-o-sh*t, proprietary Luminary program to flash my board. >> >> I have a JTAG pod on it's way and I hope to set up a cross compiler soon >> but so far in the limited time I have been able to spend on the project >> flashing has been an issue and adding C code to a project looks like it will >> take some time. >> >> I was thinking that if eLua-Lite was as easy as installing a deb package >> or downloading from a repository, then someone could have an LED blinking in >> under a minute as eLua-Lite is already running on the target. Other features >> such as a cross compiler could be included as well. >> >> Someone could play with the eLua like features and then start flashing a >> real target via JTAG right from the first board and then pretty soon just >> dump eLua-Lite and use the real thing. >> >> The only benefit I see here is a lower barrier to entry but I think that >> is still worth something. >> >> More logical? or should I get back to my crack pipe? :) >> >> >> >> >> >> >> >> >> >> >> On 12-05-14 05:11 AM, Bogdan Marinescu wrote: >>> >>> Hi Patrick, >>> >>> On Sun, May 13, 2012 at 12:54 AM, Patrick >>> <[hidden email]> wrote: >>>> >>>> Hi Guys >>>> >>>> The past few months have been difficult. It looks like daughter is also >>>> about to be diagnosed with Autism. >>> >>> Sorry to hear that :( I wish the best of luck to you and your daughter. >>> >>>> The project I have been working on for my >>>> Son looked easier as a desktop solution, so I've ignored everything >>>> embedded. Now it looks viable as embedded and i am back again. i need to >>>> follow along with what is best for my kids and my business, i haven't >>>> been >>>> able to do anything just for my own interest. >>>> >>>> I hope to resume the screencast tutorials I started(or barely >>>> started)earlier in the year, sorry about the interruption. >>>> >>>> >>>> So enough rambling....I am planning on buying a Raspberry Pi for my >>>> son's >>>> project and it got me thinking about eLua. >>> >>> I got a Raspberry coming my way too :) >>> >>>> This device boots a full Linux desktop(LDXE). I was thinking that if >>>> I(or >>>> we) could rework a distro so that it ships with eLua, Nuccio's text >>>> editor, >>>> GCC, OpenOCD and any other useful tools, then it would provide a native >>>> build environment for many of the boards the project targets, GCC on arm >>>> is >>>> not a cross compiler! >>> >>> You can't have a distribution with both eLua and GCC/OpenOCD. GCC >>> needs an OS (like Linux) to run on, eLua is itself a >>> mini-and-extremely-basic-OS (and you certainly won't be able to run >>> GCC on top of eLua :) ). You could probably find a virtualization >>> setup suitable for this task, but where's the fun in that? GCC on ARM >>> is indeed not a cross-compiler, but this isn't an issue at all. Cross >>> compilers make as good of a job as native compilers do. >>> >>>> With a jtag programmer preconfigured via OpenOCD and it could also make >>>> for >>>> an easy environment to flash lighter weight ARM boards from. >>> >>> This would be indeed an interesting project, but again, it would have >>> to run under Linux. While it's probably possible to make OpenOCD run >>> on bare metal, I can't see an advantage to this. >>> >>>> If it had SSH and/or NFS installed then it could also be used in tandem >>>> with >>>> a full power desktop. People could open remote directories for editing >>>> in >>>> their desktop computers and initiate commands via SSH(like gcc). >>>> >>>> This device also has 8 GPIO pins and could provide something to play >>>> with >>>> without the user having to be concerned about flashing at all. >>> >>> And that's the main problem with this category of devices. They are >>> built around CPUs, not MCUs, so you loose the convenience of using >>> on-chip peripherals (like PWM, UARTs and so on) from the start. Sure, >>> you can add everything you need over USB and other interfaces, but at >>> that point it really doesn't make much sense to use the board as a >>> bare metal platform (working an USB drivers alone is a huge PITA). On >>> a somewhat related topic, don't even get me started on their extremely >>> bizarre NDA policy (I'm really struggling to keep a polite tone right >>> now). I refuse to work with manufacturers who release a CPU/MCU and >>> refuse to make the documentation public, as if you could do anything >>> at all with that chip without documentation (and actually getting the >>> documentation involves a lot of time, effort and maybe even lawyers)). >>> This simply doesn't make any sense at all in my engineerish mind and >>> thus I choose to not have anything to do with it. >>> >>>> I have a couple of concerns. >>>> >>>> One the board is in short supply. >>>> >>>> Two, just because it's a Debian/Fedora ARM build environment might not >>>> make >>>> it suitable for all ARM targets. I don't know how much the various ARMs >>>> differ? >>> >>> You needn't worry about that. Cross compilers are available on all >>> Linux distros that I know of and they are very good at their job. The >>> ARMs can differ quite a bit, but that's for the compiler to worry >>> about (most of the time :) ). >>> All in all, I'd second Martin's oppinion: get a Mizar32 (or other >>> board that supports eLua), you're likely to get a much more pleasant >>> experience as far as eLua is concerned. >>> >>> Best, >>> Bogdan >>> >>>> Any thoughts on this on this project-Patrick >>>> _______________________________________________ >>>> eLua-dev mailing list >>>> [hidden email] >>>> https://lists.berlios.de/mailman/listinfo/elua-dev >>> >>> _______________________________________________ >>> eLua-dev mailing list >>> [hidden email] >>> https://lists.berlios.de/mailman/listinfo/elua-dev >>> >> >> _______________________________________________ >> eLua-dev mailing list >> [hidden email] >> https://lists.berlios.de/mailman/listinfo/elua-dev > > > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Patrick Mc(avery
On Wed, May 16, 2012 at 5:09 PM, Patrick <[hidden email]> wrote:
> On 12-05-16 09:48 AM, Martin Guy wrote: >> >> On 16 May 2012 15:06, Patrick<[hidden email]> wrote: >>> >>> What I should have said, is "could eLua run under an OS" >> >> Yes. Implement a new system target "Linux" that implements as many of >> the platform functions as it can using system calls, device files and >> standard libraries. The interesting part is how you name that as a >> board or platform or cpu or something else in the build system, as it >> should be cpu-independent. >> Why you would want to do that, instead of adding a gpio.*() C >> library etc to standard Lua to also have LFS, luasocket and the rest >> of the Luarocks libraries available, is another question... >> > Hi Martin > > My time is not my own and as my business and family needs change, eLua is > coming in and out of focus. > > I am working on a project for my Son who has Autism. I have to complete it > but all the technical details are worked out. It's a talking keyboard that > works as an assistive speech device. It's a QWERTY keyboard but there are > news key symbols on top, there is a key for the "SH" sound for instance. > > Anyhow, I want to make a portable version of it. It's basically a desktop > application, it uses gstreamer. > > Using one of these Linux capable boards will make it portable. > > Having some GPIO lines could be fun too. I could also make some iterative > games with just 8 lines and an led screen. > > I wanted to use eLua for some firmware hacking on the scientific instruments > I have here for my work but they are all based on 16 bit CPUs and the few > that are microcontroller based are not 32 bit. > > My Son's project is too heavy for a microcontroller, unless someone knows of > an audio library that could be embedded on an eLua supported target? It depends on what you need to do on the audio side. Playing stuff? Audio processing? Mixing? Filters? If you need to simply play stuff, you have a range of options; for example, letting the MCU do all the playing or using a small, relatively cheap, easy to use MP3 decoder IC for your playback. if you need audio processing, you still might be able to do that (with a M4 core for example), but you might end up needing to use a DSP. It all depends on your requirements. Best, Bogdan > > My work and family needs are not a good match for eLua right now but I would > like to help with the project if there is anything that meshes. > > Thanks > > BTW I am desperately short of time and unlikely to be of much help but I > would be willing to buy some Mizar gear, stock it here and ship it to your > customers. You could then replace my purchases that I shipped out. I don't > ship everyday and can't make special trips to my UPS store for this but if > the end user can tolerate a 3-4 day wait time before shipment, I could do > this. > > Probably much faster then waiting for postal service from Italy or paying > for trans-Atlantic courier service though... > > > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Patrick Mc(avery |
Re: Raspberry Pi as comprehensive eLua solution ?
|
|
It depends on what you need to do on the audio side. Playing stuff?
Audio processing? Mixing? Filters? If you need to simply play stuff, you have a range of options; for example, letting the MCU do all the playing or using a small, relatively cheap, easy to use MP3 decoder IC for your playback. if you need audio processing, you still might be able to do that (with a M4 core for example), but you might end up needing to use a DSP. It all depends on your requirements. Best, Bogdan Sorry to everyone, this is barely on topic or not at all........ Hi Bogdan I was following up on Tony's helpful suggestion about Blackfin/TI but having an IC that could solve this would be even more flexible. So the needs are fairly modest and I hate using gstreamer for this. I need to be able to play back a 40 second audio file but I have to be able to seek and pause and latency is very important. I haven't finished the work, but believe it or not, the 40 second file will have taken about 3 straight days of work to produce. I have recorded my own speech and I am dividing it into it's smallest building blocks, phonemes. The phonemes are split throughout the file and I need to be able to precisely seek to them. Using a bunch of drawings I hope to teach my Son how to talk by giving him visual aids on how to pronounce words: Imagine a picture of a phone and I prompt him like this: This is how we spell phone but this is how to say it fōn The program need to be able to seek to the "f" sound, play it, seek to the "ō" sound play it and then see to the "n" sound and play it as he types these keys, yes "ō" will have it's own key. My theory is that languages such as English, that have poor correspondence between spelling and actual pronunciation are complicating the recovery of people suffering from Autism. My Son is 6 now and is reading fairly well but still has very limited speech. He can't learn the language by listening alone and our writing system is seriously screwed. if we were in Romania, I wouldn't need to attempt this project: http://www.unilang.org/wiki/index.php/Romanian_orthography The same is largely true with Portuguese and Italian and several other languages. Thanks for your hints on this and feedback on my nutty R PI idea. _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Then, come to Romania. Here is much more interactivity between people
and children. You have where to let children play safe and they can do wonders. In a place at countryside, with lot of people, children, animals and birds, with lot of activity and play time, with joys and surprises, events and an wonderful natural environment I bet your child can recover in no time. I wish him all the best. On 5/17/12, Patrick <[hidden email]> wrote: > It depends on what you need to do on the audio side. Playing stuff? > Audio processing? Mixing? Filters? If you need to simply play stuff, you > have a range of options; for example, letting the MCU do all the playing > or using a small, relatively cheap, easy to use MP3 decoder IC for your > playback. if you need audio processing, you still might be able to do > that (with a M4 core for example), but you might end up needing to use a > DSP. It all depends on your requirements. Best, Bogdan > > > Sorry to everyone, this is barely on topic or not at all........ > > > Hi Bogdan > > I was following up on Tony's helpful suggestion about Blackfin/TI but > having an IC that could solve this would be even more flexible. > > So the needs are fairly modest and I hate using gstreamer for this. > > I need to be able to play back a 40 second audio file but I have to be > able to seek and pause and latency is very important. > > I haven't finished the work, but believe it or not, the 40 second file > will have taken about 3 straight days of work to produce. I have > recorded my own speech and I am dividing it into it's smallest building > blocks, phonemes. The phonemes are split throughout the file and I need > to be able to precisely seek to them. > > Using a bunch of drawings I hope to teach my Son how to talk by giving > him visual aids on how to pronounce words: > Imagine a picture of a phone and I prompt him like this: > > This is how we spell > phone > but this is how to say it > fōn > > The program need to be able to seek to the "f" sound, play it, seek to > the "ō" sound play it and then see to the "n" sound and play it as he > types these keys, yes "ō" will have it's own key. > > My theory is that languages such as English, that have poor > correspondence between spelling and actual pronunciation are > complicating the recovery of people suffering from Autism. My Son is 6 > now and is reading fairly well but still has very limited speech. He > can't learn the language by listening alone and our writing system is > seriously screwed. > > if we were in Romania, I wouldn't need to attempt this project: > > http://www.unilang.org/wiki/index.php/Romanian_orthography > > The same is largely true with Portuguese and Italian and several other > languages. > > Thanks for your hints on this and feedback on my nutty R PI idea. > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev -- Vasi _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
http://www.youtube.com/watch?v=1Yn_t3Gi1Bg
On 5/17/12, vasi vasi <[hidden email]> wrote: > Then, come to Romania. Here is much more interactivity between people > and children. You have where to let children play safe and they can do > wonders. In a place at countryside, with lot of people, children, > animals and birds, with lot of activity and play time, with joys and > surprises, events and an wonderful natural environment I bet your > child can recover in no time. > I wish him all the best. > > On 5/17/12, Patrick <[hidden email]> wrote: >> It depends on what you need to do on the audio side. Playing stuff? >> Audio processing? Mixing? Filters? If you need to simply play stuff, you >> have a range of options; for example, letting the MCU do all the playing >> or using a small, relatively cheap, easy to use MP3 decoder IC for your >> playback. if you need audio processing, you still might be able to do >> that (with a M4 core for example), but you might end up needing to use a >> DSP. It all depends on your requirements. Best, Bogdan >> >> >> Sorry to everyone, this is barely on topic or not at all........ >> >> >> Hi Bogdan >> >> I was following up on Tony's helpful suggestion about Blackfin/TI but >> having an IC that could solve this would be even more flexible. >> >> So the needs are fairly modest and I hate using gstreamer for this. >> >> I need to be able to play back a 40 second audio file but I have to be >> able to seek and pause and latency is very important. >> >> I haven't finished the work, but believe it or not, the 40 second file >> will have taken about 3 straight days of work to produce. I have >> recorded my own speech and I am dividing it into it's smallest building >> blocks, phonemes. The phonemes are split throughout the file and I need >> to be able to precisely seek to them. >> >> Using a bunch of drawings I hope to teach my Son how to talk by giving >> him visual aids on how to pronounce words: >> Imagine a picture of a phone and I prompt him like this: >> >> This is how we spell >> phone >> but this is how to say it >> fōn >> >> The program need to be able to seek to the "f" sound, play it, seek to >> the "ō" sound play it and then see to the "n" sound and play it as he >> types these keys, yes "ō" will have it's own key. >> >> My theory is that languages such as English, that have poor >> correspondence between spelling and actual pronunciation are >> complicating the recovery of people suffering from Autism. My Son is 6 >> now and is reading fairly well but still has very limited speech. He >> can't learn the language by listening alone and our writing system is >> seriously screwed. >> >> if we were in Romania, I wouldn't need to attempt this project: >> >> http://www.unilang.org/wiki/index.php/Romanian_orthography >> >> The same is largely true with Portuguese and Italian and several other >> languages. >> >> Thanks for your hints on this and feedback on my nutty R PI idea. >> _______________________________________________ >> eLua-dev mailing list >> [hidden email] >> https://lists.berlios.de/mailman/listinfo/elua-dev > > > -- > Vasi > -- Vasi _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Hi,
While I do appreciate the movie link, let's try to keep in on-topic, please. I've switched to off-list discussions with Patrick, you could do the same if you want to help him/convince him to make a trip here :) Best, Bogdan On Thu, May 17, 2012 at 3:58 PM, vasi vasi <[hidden email]> wrote: > http://www.youtube.com/watch?v=1Yn_t3Gi1Bg > > On 5/17/12, vasi vasi <[hidden email]> wrote: >> Then, come to Romania. Here is much more interactivity between people >> and children. You have where to let children play safe and they can do >> wonders. In a place at countryside, with lot of people, children, >> animals and birds, with lot of activity and play time, with joys and >> surprises, events and an wonderful natural environment I bet your >> child can recover in no time. >> I wish him all the best. >> >> On 5/17/12, Patrick <[hidden email]> wrote: >>> It depends on what you need to do on the audio side. Playing stuff? >>> Audio processing? Mixing? Filters? If you need to simply play stuff, you >>> have a range of options; for example, letting the MCU do all the playing >>> or using a small, relatively cheap, easy to use MP3 decoder IC for your >>> playback. if you need audio processing, you still might be able to do >>> that (with a M4 core for example), but you might end up needing to use a >>> DSP. It all depends on your requirements. Best, Bogdan >>> >>> >>> Sorry to everyone, this is barely on topic or not at all........ >>> >>> >>> Hi Bogdan >>> >>> I was following up on Tony's helpful suggestion about Blackfin/TI but >>> having an IC that could solve this would be even more flexible. >>> >>> So the needs are fairly modest and I hate using gstreamer for this. >>> >>> I need to be able to play back a 40 second audio file but I have to be >>> able to seek and pause and latency is very important. >>> >>> I haven't finished the work, but believe it or not, the 40 second file >>> will have taken about 3 straight days of work to produce. I have >>> recorded my own speech and I am dividing it into it's smallest building >>> blocks, phonemes. The phonemes are split throughout the file and I need >>> to be able to precisely seek to them. >>> >>> Using a bunch of drawings I hope to teach my Son how to talk by giving >>> him visual aids on how to pronounce words: >>> Imagine a picture of a phone and I prompt him like this: >>> >>> This is how we spell >>> phone >>> but this is how to say it >>> fōn >>> >>> The program need to be able to seek to the "f" sound, play it, seek to >>> the "ō" sound play it and then see to the "n" sound and play it as he >>> types these keys, yes "ō" will have it's own key. >>> >>> My theory is that languages such as English, that have poor >>> correspondence between spelling and actual pronunciation are >>> complicating the recovery of people suffering from Autism. My Son is 6 >>> now and is reading fairly well but still has very limited speech. He >>> can't learn the language by listening alone and our writing system is >>> seriously screwed. >>> >>> if we were in Romania, I wouldn't need to attempt this project: >>> >>> http://www.unilang.org/wiki/index.php/Romanian_orthography >>> >>> The same is largely true with Portuguese and Italian and several other >>> languages. >>> >>> Thanks for your hints on this and feedback on my nutty R PI idea. >>> _______________________________________________ >>> eLua-dev mailing list >>> [hidden email] >>> https://lists.berlios.de/mailman/listinfo/elua-dev >> >> >> -- >> Vasi >> > > > -- > Vasi > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |