I want to work with a modem interfaced on a serial port on an embedded platform.
Here are some solutions I have rejected so far :
Expect plus a terminal program :
My (cross)build system does not have any package rules for expect, and according to the installation instructions from the expect sources, the configure script needs to be interactive because it does some test with the terminale it is invoked in. Thid does not look like something you want to do when cross compiling.
Python plus pyserial :
I would love to use this, but the size of the whole thing won't fit on my limited flash space.
Chat (from the pppd package):
Well, I may give it a try but it is very, very limited
So I am looking for some sort of lightweight, embeddable expect replacement. I have no knwoledge of lua. Would it be a good candidate for expect like scipting ?
Well, Expect is just Tcl plus extensions to drive other programs via pseudo-terminals and do pattern-matching on the results. If you just want to drive a serial port you can drop the external terminal program and have Tcl drive the serial port directly - see sample code. See also the Tcl Wiki page on cross-compiling.
Related
How could I automate interactions with command line programs that expose a text terminal interface with Perl 6 for testing purposes?
If you want to use Perl 6 to automate execution or testing of console applications, I think you're going to use NativeCall to interact with the expect library. Once expect is installed, man libexpect will show its API documentation, though the way of accessing the documentation (such as the manpage name) may differ per package distribution.
Expect has APIs to launch a program, wait for text to appear on the (emulated) console (to "expect" text), and send text to the console (to emulate typing). The most common use case is to automate programs which require password input. Expect is often scripted--it is an interpreter--but there's no reason not to use it from a higher level programming language.
Edit: I somewhat answered the wrong question. The OP is interested in testing Perl 6 modules with Perl 6. That said, using expect to launch a second Perl 6 interpreter which uses the module is still the strongest, most strict way to test the application. You don't need to know what type of terminal library the module uses, because expect should be compatible with nearly all of them. You can send text to the STDIN pipe of a subprocess, but that's not as strong as the subprocess (console) communication you can get from expect. I don't know if there's a way to hijack whichever terminal library the module uses and communicate with it directly.
If it's just a plain interface, you could just run the program and collect output. The currently-experimental Testo module has is-run routine. You could use that directly, or if experimental status is bothersome, copy the guts of it into your own helper routine.
Take a look at Sparrow6 Task Check Language - Perl6 based DSL to verify text output. I've done a lot terminal apps testing using it.
I want to develop a VGA graphics driver (for Linux(Ubuntu)) with support for the basic primitives such as putpixel, drawline, fillrect and bitblt. I want to do it in protected mode.
I´ve been googling for a week and the following four links are the best I have found:
http://www.brackeen....vga/basics.html
http://www.osdever.n...VGA/vga/vga.htm
http://bos.asmhacker...sing%20bios.htm
Unfortunately, the first one uses a BIOS call so I cannot use it. The second link has lots of information on the VGA registers but no examples showing how to make them work together. The third example is a example to switch in 13h mode but i've tried it and nothing happened. Can you guys give me a hint? Thanks in advance!
--Vincenzo
my code at http://bos.asmhackers.net/docs/vga_without_bios/snippet_5/vga.php
works fine if you are in 32bit mode with full hardware access. Unfortunately I doubt that any Linux variant will let you directly access the VGA ports. I'm not sure how you develop this driver, but if you made sure that you have full access to the VGA ports it should work. In my example code I only switch between mode 0x03 and 0x13, but in the folders above you'll be able to find port values for most other common VGA modes, as well as C code to do the switch if you prefer that.
Christoffer code include files are found BOS operating system source code like text.inc and font8x16.inc
http://bos.asmhackers.net/downloads.php
This is coming many many years later but I think it's still very relevant and if somebody is struggling I hope they can find it useful.
First of all, it is completely possible to configure VGA only using registers without interrupts, as hard as it may be. A useful resource about registers and how to configure them can be found here, but unless you have a ton of time to spare to learn how to properly do all of it, move to the following section.
If you wish to really learn how to do it, I suggest going through with the documentation provided earlier. However, some of it is already done!
Chris Giese did a great job demonstrating exactly how to do this for MS-DOS system, and while you may think that doesn't help you, it really does.
Chris's code can be found here. If you want another useful codes check here as well.
Now, while it only works for MS-DOS it's actually easy to convert to other systems. The code already contains all data needed to configure the registers in many different modes. And that's the part that saves you a ton of time going through documentation.
The code uses functions outportb, inportb, which are MS-DOS functions, to write/read single byte to/from a port. Therefore, you have to redefine these functions to read/write for your own system. Redefinition complexity depends on the system you operate on.
In addition, you will also need to provide means to write to physical memory region between 0xA0000-0xBFFFF which corresponds to standard VGA memory area. Once you have that allocated, you need to also redefine the functions pokeb pokew peekb which will help you output things (text or pixel data) on the screen.
One last note: the code is already defined to work with many different modes including both text and display modes.
So at work, we check computer's specifications, and need to print these in a standard format. I know how to set up a PXE server already, but I was wondering if it were easy to get a program (or write a script) that will check the computer's hardware (processor, memory, hard drive), and print it over the network.
My thoughts are that I can boot a very simple linux os over PXE, and run a script to do the dirty work. However, I'm not sure how to set it up to use a network printer, or which script to use for that matter.
All the computers have the same architecture, (x86), so a single implementation should work for all of them.
I would be inclined to avoid using a printer directly here and use something like scp or netcat to send back the information you discover.
Edit:
There are a number of tools that might help collecting the data itself, depending on what exactly you want to collect. I've found dmidecode to be very useful. Potientally it can tell you the version of the BIOS, memory stick size/speed/locations and quite a lot of very detailed information. It is buggy on some older hardware with broken DMI tables though. lshal, lshw, lspci and lsusb are all fairly common on linux installations and rather useful for these things.
Have a look at GLPI. It's a good open source software used to manage IT tickets, but, it also integrates a IT infrastructure management that could turn our to be useful in your case.
There is a small piece of software to be installed on each remote client (this could be done remotely and silently) and then you can collect a lot of information and match it by IP addresses
We use 'pdsh' to manage our global network. We have a naming convention of hosts that makes the host expression easy to write. So to continue the ls### suggestion to collect the info on a collection of hardware, we would write a command like this:
[root#admin-console ~]# pdsh -R exec -w china-[1-1024] ssh %h lshal > china-lshal-cabinet-01.log
pdsh prefixes the host name to the output lines and as it runs as a concurrent operator the lines will collate. A simple sorting script using the, say "china-[1-1024]:" tag is needed to get them organized. You could also make the pdsh run sequentially by limiting its concurrency but if you are running large configurations you would want the concurrency.
Would it be possible to take the source code from a SNES emulator (or any other game system emulator for that matter) and a game ROM for the system, and somehow create a single self-contained executable that lets you play that particular ROM without needing either the individual rom or the emulator itself to play? Would it be difficult, assuming you've already got the rom and the emulator source code to work with?
It shouldn't be too difficult if you have the emulator source code. You can use a method that is often used to store images in c source files.
Basically, what you need to do is create a char * variable in a header file, and store the contents of the rom file in that variable. You may want to write a script to automate this for you.
Then, you will need to alter the source code so that instead of reading the rom in from a file, it uses the in memory version of the rom, stored in your variable and included from your header file.
It may require a little bit of work if you need to emulate file pointers and such, or you may be lucky and find that the rom loading function just loads the whole file in at once. In this case it would probably be as simple as replacing the file load function with a function to return your pointer.
However, be careful for licensing issues. If the emulator is licensed under the GPL, you may not be legally allowed to store a proprietary file in the executable, so it would be worth checking that, especially before you release / distribute it (if you plan to do so).
Yes, more than possible, been done many times. Google: static binary translation. Graham Toal has a good howto paper on the subject, should show up early in the hits. There may be some code out there I may have left some code out there.
Completely removing the rom may be a bit more work than you think, but not using an emulator, definitely possible. Actually, both requirements are possible and you may be surprised how many of the handheld console games or set top box games are translated and not emulated. Esp platforms like those from Nintendo where there isnt enough processing power to emulate in real time.
You need a good emulator as a reference and/or write your own emulator as a reference. Then you need to write a disassembler, then you have that disassembler generate C code (please dont try to translate directly to another target, I made that mistake once, C is portable and the compilers will take care of a lot of dead code elimination for you). So an instruction of a make believe instruction set might be:
add r0,r0,#2
And that may translate into:
//add r0,r0,#2
r0=r0+2;
do_zflag(r0);
do_nflag(r0);
It looks like the SNES is related to the 6502 which is what Asteroids used, which is the translation I have been working on off and on for a while now as a hobby. The emulator you are using is probably written and tuned for runtime performance and may be difficult at best to use as a reference and to check in lock step with the translated code. The 6502 is nice because compared to say the z80 there really are not that many instructions. As with any variable word length instruction set the disassembler is your first big hurdle. Do not think linearly, think execution order, think like an emulator, you cannot linearly translate instructions from zero to N or N down to zero. You have to follow all the possible execution paths, marking bytes in the rom as being the first byte of an instruction, and not the first byte of an instruction. Some bytes you can decode as data and if you choose mark those, otherwise assume all other bytes are data or fill. Figuring out what to do with this data to get rid of the rom is the problem with getting rid of the rom. Some code addresses data directly others use register indirect meaning at translation time you have no idea where that data is or how much of it there is. Once you have marked all the starting bytes for instructions then it is a trivial task to walk the rom from zero to N disassembling and or translating.
Good luck, enjoy, it is well worth the experience.
I want to examine exactly how my code operates when using other libraries to which I do not have the code for. Whilst I can do this online (i.e. with FileMon, RegMon and TCPView from SysInternals), I was wondering if there was a good offline method that would allow me to run up my code in a virtual machine, shutdown the virtual machine and diff the entire VM image?
Since persistent modifications to the system is either in the filesystem on in the registry, you could have a little program that list all the files on the hard drive and also dump the registry.
Then you can also do it after program operation and do a simple file diff.
If you are using virtualbox, I think that you can do the mounting of the disk image offline (i.e. virtual machine not running). However dumping the registry from offline files may be harder.
See "Mount vdi" on google.
All integration testing surely will use code for which you don't have the source, your framework libraries, database drivers, databases, comms libraries. Some of which may not even be on the same machine your code is. I'm not clear exactly what you would hope to achieve. You make some calls to a queueing system, it does all manner of secret squirrel stuff. You diff before and after, now what can you say? Do you know what data formats there ought to be represent your request?
I see tests as being defined in terms of the published behaviours of the libraries and systems I'm working with. Example for a database: I execute some business actions which are supposed to create Orders. I know the orders I defined, do they appear in the database? In defining my tests I can specify explict expected outcomes in terms of records in a database. I can then even automate the tests - compare an extract from the database with expected results.