project ideas/ feedback
Locked
|
Hi Everyone
I have quite a few scientific instruments here. Almost all all of them use Motorola's 68000 series or 6800 CPUs and a couple have old Intel based microcontrollers(I forgot the models). Being only 8 bit and 16 bit I have not attempted to load an eLua image right into an instrument but I had another idea. I was thinking about using a another microcontroller as an eprom emulator. If I had another eLua based controller perhaps I could use the GPIO lines to respond to read requests from the 16/8 bit 68K/6800 CPUs. If I could figure out a suitable instruction to send when I wanted everything to hold then I could step instruments through instructions very slowly. This might be a great tool servicing them and might allow them to be used for unintended purposes. Another thing I was thinking about was hijacking the instruments more directly. Do you think if I asserted the Motorola's CPU halt that I could then tap the inactive I/O lines with an Elua microcontroller. This would give me access to prefabricated circuits for just about everything. I could create some nice demos for PWM, LCD control etc... Just some nutty ideas-Patrick _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Hi,
Maybe you can load a firmware on the instrument CPU that receives and interpret commands. With that you can make eLua send this commands (or anything else) I believe this is a reasonable approach, but of course you can do some hardware hack for fun =) =) Cheers, --Pedro Bittencourt On Wed, Sep 1, 2010 at 9:27 AM, Patrick <[hidden email]> wrote: Hi Everyone _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Patrick-11
> Hi Everyone
> > I have quite a few scientific instruments here. Almost all all of them use > Motorola's 68000 series or 6800 CPUs and a couple have old Intel based > microcontrollers(I forgot the models). > > Being only 8 bit and 16 bit I have not attempted to load an eLua image right > into an instrument but I had another idea. I was thinking about using a > another microcontroller as an eprom emulator. If I had another eLua based > controller perhaps I could use the GPIO lines to respond to read requests > from the 16/8 bit 68K/6800 CPUs. If I could figure out a suitable > instruction to send when I wanted everything to hold then I could step > instruments through instructions very slowly. This might be a great tool > servicing them and might allow them to be used for unintended purposes. I'm not familiar with the external bus on the 68k, but there are basically two versions of such buses: 1. synchronous - the bus has a WAIT signal that can be asserted by the memory subsystem (or other peripherlas) to indicate to the CPU that it is holding the bus, and it should only read data from the bus after WAIT is deasserted 2. asynchronous - in this case the bus cycle time is well known; this is generally the case when accessing external memories (RAMs of Flash) If you can relate to 1 above, your approach should work. For 2, however, it's highly unlikely that you'll be able to generate a fast enough bus cycle from eLua to fool the CPU. It'd be hard even from ASM code, I imagine. eLua aside, have you though about fiddling with the clock? A clock generator is something very easy to build these days, and it should allow you to run the CPU as slow as you want. > Another thing I was thinking about was hijacking the instruments more > directly. Do you think if I asserted the Motorola's CPU halt that I could > then tap the inactive I/O lines with an Elua microcontroller. This would > give me access to prefabricated circuits for just about everything. I could > create some nice demos for PWM, LCD control etc... Sure, if you keep the CPU in RESET you should be able to pretend it's not there (at least on the general purpose I/O lines) and do whatever you want with the rest of the circuit. But then you'll have to physically connect things to the PCB, which might be easy or a damn nightmare :) Best, Bogdan _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Thanks Pedro, Thanks Bogdan
I have been working hard on putting together an eLua/Lua screencast series. I have several pieces put together now: -ffmpeg/mencoder for video -Audacity for sound -Capture card for live video -.srt files/mencoder for subtitles -Geany text editor for integrated text editor and shell The subtitle fonts are too large right now but after this is corrected I should be able to seamlessly record my voice, computer screen, demo board and other hardware and offer subtitles after post production too. I have an instrument here called a refractive index detector. I think I will tap the I/O lines and create a demo video. This instrument has PWM for heating, analogue signals for light and temperature, and a solenoid that diverts flow for solvent flowing through it. This might be a good way to show people a bit about eLua and learn myself. I might also hijack another instrument called a fraction collector that is a little robot. I move very slowly :( I might not have anything to show for a couple of months. Thanks again-Patrick On 09/01/2010 09:11 AM, Bogdan Marinescu wrote: >> Hi Everyone >> >> I have quite a few scientific instruments here. Almost all all of them use >> Motorola's 68000 series or 6800 CPUs and a couple have old Intel based >> microcontrollers(I forgot the models). >> >> Being only 8 bit and 16 bit I have not attempted to load an eLua image right >> into an instrument but I had another idea. I was thinking about using a >> another microcontroller as an eprom emulator. If I had another eLua based >> controller perhaps I could use the GPIO lines to respond to read requests >> from the 16/8 bit 68K/6800 CPUs. If I could figure out a suitable >> instruction to send when I wanted everything to hold then I could step >> instruments through instructions very slowly. This might be a great tool >> servicing them and might allow them to be used for unintended purposes. > > I'm not familiar with the external bus on the 68k, but there are > basically two versions of such buses: > > 1. synchronous - the bus has a WAIT signal that can be asserted by the > memory subsystem (or other peripherlas) to indicate to the CPU that it > is holding the bus, and it should only read data from the bus after > WAIT is deasserted > 2. asynchronous - in this case the bus cycle time is well known; this > is generally the case when accessing external memories (RAMs of Flash) > > If you can relate to 1 above, your approach should work. For 2, > however, it's highly unlikely that you'll be able to generate a fast > enough bus cycle from eLua to fool the CPU. It'd be hard even from ASM > code, I imagine. > eLua aside, have you though about fiddling with the clock? A clock > generator is something very easy to build these days, and it should > allow you to run the CPU as slow as you want. > >> Another thing I was thinking about was hijacking the instruments more >> directly. Do you think if I asserted the Motorola's CPU halt that I could >> then tap the inactive I/O lines with an Elua microcontroller. This would >> give me access to prefabricated circuits for just about everything. I could >> create some nice demos for PWM, LCD control etc... > > Sure, if you keep the CPU in RESET you should be able to pretend it's > not there (at least on the general purpose I/O lines) and do whatever > you want with the rest of the circuit. But then you'll have to > physically connect things to the PCB, which might be easy or a damn > nightmare :) > > Best, > Bogdan > _______________________________________________ > 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 |
|
|
On Thu, Sep 2, 2010 at 5:46 AM, Patrick
<[hidden email]> wrote: > Thanks Pedro, Thanks Bogdan > > I have been working hard on putting together an eLua/Lua screencast series. > I have several pieces put together now: > > -ffmpeg/mencoder for video > -Audacity for sound > -Capture card for live video > -.srt files/mencoder for subtitles > -Geany text editor for integrated text editor and shell > > The subtitle fonts are too large right now but after this is corrected I > should be able to seamlessly record my voice, computer screen, demo board > and other hardware and offer subtitles after post production too. > > I have an instrument here called a refractive index detector. I think I will > tap the I/O lines and create a demo video. This instrument has PWM for > heating, analogue signals for light and temperature, and a solenoid that > diverts flow for solvent flowing through it. This might be a good way to > show people a bit about eLua and learn myself. I might also hijack another > instrument called a fraction collector that is a little robot. These are excellent news, thank you. I'm looking to build a similar setup myself, but it will probably take a while, since I basically don't know anything about audio/viodeo production, even at the basic level. Good luck with your setup! Best, Bogdan > On 09/01/2010 09:11 AM, Bogdan Marinescu wrote: >>> >>> Hi Everyone >>> >>> I have quite a few scientific instruments here. Almost all all of them >>> use >>> Motorola's 68000 series or 6800 CPUs and a couple have old Intel based >>> microcontrollers(I forgot the models). >>> >>> Being only 8 bit and 16 bit I have not attempted to load an eLua image >>> right >>> into an instrument but I had another idea. I was thinking about using a >>> another microcontroller as an eprom emulator. If I had another eLua based >>> controller perhaps I could use the GPIO lines to respond to read requests >>> from the 16/8 bit 68K/6800 CPUs. If I could figure out a suitable >>> instruction to send when I wanted everything to hold then I could step >>> instruments through instructions very slowly. This might be a great tool >>> servicing them and might allow them to be used for unintended purposes. >> >> I'm not familiar with the external bus on the 68k, but there are >> basically two versions of such buses: >> >> 1. synchronous - the bus has a WAIT signal that can be asserted by the >> memory subsystem (or other peripherlas) to indicate to the CPU that it >> is holding the bus, and it should only read data from the bus after >> WAIT is deasserted >> 2. asynchronous - in this case the bus cycle time is well known; this >> is generally the case when accessing external memories (RAMs of Flash) >> >> If you can relate to 1 above, your approach should work. For 2, >> however, it's highly unlikely that you'll be able to generate a fast >> enough bus cycle from eLua to fool the CPU. It'd be hard even from ASM >> code, I imagine. >> eLua aside, have you though about fiddling with the clock? A clock >> generator is something very easy to build these days, and it should >> allow you to run the CPU as slow as you want. >> >>> Another thing I was thinking about was hijacking the instruments more >>> directly. Do you think if I asserted the Motorola's CPU halt that I could >>> then tap the inactive I/O lines with an Elua microcontroller. This would >>> give me access to prefabricated circuits for just about everything. I >>> could >>> create some nice demos for PWM, LCD control etc... >> >> Sure, if you keep the CPU in RESET you should be able to pretend it's >> not there (at least on the general purpose I/O lines) and do whatever >> you want with the rest of the circuit. But then you'll have to >> physically connect things to the PCB, which might be easy or a damn >> nightmare :) >> >> Best, >> Bogdan >> _______________________________________________ >> 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-11
If you're on Linux, you might also want to take a look at PiTiVi
(http://www.pitivi.org/) for doing simple non-linear editing. Last I had checked it didn't support many of the advanced features one might find in high-end suites, but the infrastructure appears to be there. I've found it to be fairly well designed and robust, with the exception that the gstreamer output codec options still feel like a gui enumeration of all the raw options each codec provides. Depending on where you want to post the your screencasts/videos you may not even need to burn in subtitles since YouTube and some of the other sites now have native support for them. If you need help with stuff related to video & encoding, feel free to send along any questions. I may not have the answer, but I have fiddled quite a bit with ffmpeg/mencoder and various derivatives/frontends. :-) On Wed, Sep 1, 2010 at 9:46 PM, Patrick <[hidden email]> wrote: > Thanks Pedro, Thanks Bogdan > > I have been working hard on putting together an eLua/Lua screencast series. > I have several pieces put together now: > > -ffmpeg/mencoder for video > -Audacity for sound > -Capture card for live video > -.srt files/mencoder for subtitles > -Geany text editor for integrated text editor and shell > > The subtitle fonts are too large right now but after this is corrected I > should be able to seamlessly record my voice, computer screen, demo board > and other hardware and offer subtitles after post production too. > > I have an instrument here called a refractive index detector. I think I will > tap the I/O lines and create a demo video. This instrument has PWM for > heating, analogue signals for light and temperature, and a solenoid that > diverts flow for solvent flowing through it. This might be a good way to > show people a bit about eLua and learn myself. I might also hijack another > instrument called a fraction collector that is a little robot. > > I move very slowly :( I might not have anything to show for a couple of > months. > > Thanks again-Patrick > > > > On 09/01/2010 09:11 AM, Bogdan Marinescu wrote: >>> >>> Hi Everyone >>> >>> I have quite a few scientific instruments here. Almost all all of them >>> use >>> Motorola's 68000 series or 6800 CPUs and a couple have old Intel based >>> microcontrollers(I forgot the models). >>> >>> Being only 8 bit and 16 bit I have not attempted to load an eLua image >>> right >>> into an instrument but I had another idea. I was thinking about using a >>> another microcontroller as an eprom emulator. If I had another eLua based >>> controller perhaps I could use the GPIO lines to respond to read requests >>> from the 16/8 bit 68K/6800 CPUs. If I could figure out a suitable >>> instruction to send when I wanted everything to hold then I could step >>> instruments through instructions very slowly. This might be a great tool >>> servicing them and might allow them to be used for unintended purposes. >> >> I'm not familiar with the external bus on the 68k, but there are >> basically two versions of such buses: >> >> 1. synchronous - the bus has a WAIT signal that can be asserted by the >> memory subsystem (or other peripherlas) to indicate to the CPU that it >> is holding the bus, and it should only read data from the bus after >> WAIT is deasserted >> 2. asynchronous - in this case the bus cycle time is well known; this >> is generally the case when accessing external memories (RAMs of Flash) >> >> If you can relate to 1 above, your approach should work. For 2, >> however, it's highly unlikely that you'll be able to generate a fast >> enough bus cycle from eLua to fool the CPU. It'd be hard even from ASM >> code, I imagine. >> eLua aside, have you though about fiddling with the clock? A clock >> generator is something very easy to build these days, and it should >> allow you to run the CPU as slow as you want. >> >>> Another thing I was thinking about was hijacking the instruments more >>> directly. Do you think if I asserted the Motorola's CPU halt that I could >>> then tap the inactive I/O lines with an Elua microcontroller. This would >>> give me access to prefabricated circuits for just about everything. I >>> could >>> create some nice demos for PWM, LCD control etc... >> >> Sure, if you keep the CPU in RESET you should be able to pretend it's >> not there (at least on the general purpose I/O lines) and do whatever >> you want with the rest of the circuit. But then you'll have to >> physically connect things to the PCB, which might be easy or a damn >> nightmare :) >> >> Best, >> Bogdan >> _______________________________________________ >> 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 > -- James Snyder Biomedical Engineering Northwestern University [hidden email] PGP: http://fanplastic.org/key.txt Phone: (847) 448-0386 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On 09/02/2010 10:37 AM, James Snyder wrote:
> If you're on Linux, you might also want to take a look at PiTiVi > (http://www.pitivi.org/) for doing simple non-linear editing. Last I > had checked it didn't support many of the advanced features one might > find in high-end suites, but the infrastructure appears to be there. > I've found it to be fairly well designed and robust, with the > exception that the gstreamer output codec options still feel like a > gui enumeration of all the raw options each codec provides. > > Depending on where you want to post the your screencasts/videos you > may not even need to burn in subtitles since YouTube and some of the > other sites now have native support for them. > > If you need help with stuff related to video& encoding, feel free to > send along any questions. I may not have the answer, but I have > fiddled quite a bit with ffmpeg/mencoder and various > derivatives/frontends. :-) > Thanks very much for the tips James =) I have also used Avidemux and been quite happy with it. The subtitle plan is to create a text transcript on the page with the true purpose of boosting page rank with crawlable text. Another possible advantage is for me to talk about things I don't understand yet! I live just North of Toronto, Canada. Here we have a large immigrant population(my town is 65% "visible minority", whatever that means now). With immigrate in-laws and friends I have trained myself to not use slang and some people have said that my English is easy to understand. If non-native English speaking eLua users wanted to me to do a screencast for them I could convert a text document to subtitles and just read along without a clue of what I am talking about =) I started a screencast series but I am not happy with it and want to totally redo it but if you want to hear my voice please visit: www.cakeandfile.com/001intro.avi Thanks again-Patrick _______________________________________________ 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 |