Search Results

Search found 4 results on 1 pages for 'tomlogic'.

Page 1/1 | 1 

  • DOS application to allow remote management of files over serial link

    - by tomlogic
    Harken back to the days of DOS. I have an embedded DOS handheld device, and I'm looking for a tool to manage the files stored on it. I picture an application I can launch on the device that opens COM1 up for commands to get a directory listing, send/receive files via x/y/zmodem, move/delete files, and create/move/delete directories. A Windows application can then download a recursive file listing and then manage those files (for example, synchronizing with a local directory). Keep in mind that this is DOS -- 8.3 filenames, 640K of RAM and a 19200bps serial link (yuk!). I'd prefer something with source in case we need to add additional features (for example, the ability to get a checksum of a file for change detection). Now that I've written this description, I realize I'm asking for something like LapLink or pcAnywhere. Norton no longer sells DOS versions of pcAnywhere and LapLink V for DOS seems pricy at $50. Are you aware of any similar apps from those good old days?

    Read the article

  • Designing an API with compile-time option to remove first parameter to most functions and use a glob

    - by tomlogic
    I'm trying to design a portable API in ANSI C89/ISO C90 to access a wireless networking device on a serial interface. The library will have multiple network layers, and various versions need to run on embedded devices as small as an 8-bit micro with 32K of code and 2K of data, on up to embedded devices with a megabyte or more of code and data. In most cases, the target processor will have a single network interface and I'll want to use a single global structure with all state information for that device. I don't want to pass a pointer to that structure through the network layers. In a few cases (e.g., device with more resources that needs to live on two networks) I will interface to multiple devices, each with their own global state, and will need to pass a pointer to that state (or an index to a state array) through the layers. I came up with two possible solutions, but neither one is particularly pretty. Keep in mind that the full driver will potentially be 20,000 lines or more, cover multiple files, and contain hundreds of functions. The first solution requires a macro that discards the first parameter for every function that needs to access the global state: // network.h typedef struct dev_t { int var; long othervar; char name[20]; } dev_t; #ifdef IF_MULTI #define foo_function( x, a, b, c) _foo_function( x, a, b, c) #define bar_function( x) _bar_function( x) #else extern dev_t DEV; #define IFACE (&DEV) #define foo_function( x, a, b, c) _foo_function( a, b, c) #define bar_function( x) _bar_function( ) #endif int bar_function( dev_t *IFACE); int foo_function( dev_t *IFACE, int a, long b, char *c); // network.c #ifndef IF_MULTI dev_t DEV; #endif int bar_function( dev_t *IFACE) { memset( IFACE, 0, sizeof *IFACE); return 0; } int foo_function( dev_t *IFACE, int a, long b, char *c) { bar_function( IFACE); IFACE->var = a; IFACE->othervar = b; strcpy( IFACE->name, c); return 0; } The second solution defines macros to use in the function declarations: // network.h typedef struct dev_t { int var; long othervar; char name[20]; } dev_t; #ifdef IF_MULTI #define DEV_PARAM_ONLY dev_t *IFACE #define DEV_PARAM DEV_PARAM_ONLY, #else extern dev_t DEV; #define IFACE (&DEV) #define DEV_PARAM_ONLY void #define DEV_PARAM #endif int bar_function( DEV_PARAM_ONLY); // I don't like the missing comma between DEV_PARAM and arg2... int foo_function( DEV_PARAM int a, long b, char *c); // network.c #ifndef IF_MULTI dev_t DEV; #endif int bar_function( DEV_PARAM_ONLY) { memset( IFACE, 0, sizeof *IFACE); return 0; } int foo_function( DEV_PARAM int a, long b, char *c) { bar_function( IFACE); IFACE->var = a; IFACE->othervar = b; strcpy( IFACE->name, c); return 0; } The C code to access either method remains the same: // multi.c - example of multiple interfaces #define IF_MULTI #include "network.h" dev_t if0, if1; int main() { foo_function( &if0, -1, 3.1415926, "public"); foo_function( &if1, 42, 3.1415926, "private"); return 0; } // single.c - example of a single interface #include "network.h" int main() { foo_function( 11, 1.0, "network"); return 0; } Is there a cleaner method that I haven't figured out? I lean toward the second since it should be easier to maintain, and it's clearer that there's some macro magic in the parameters to the function. Also, the first method requires prefixing the function names with "_" when I want to use them as function pointers. I really do want to remove the parameter in the "single interface" case to eliminate unnecessary code to push the parameter onto the stack, and to allow the function to access the first "real" parameter in a register instead of loading it from the stack. And, if at all possible, I don't want to have to maintain two separate codebases. Thoughts? Ideas? Examples of something similar in existing code? (Note that using C++ isn't an option, since some of the planned targets don't have a C++ compiler available.)

    Read the article

  • Force screen size when testing embedded DOS app in Windows 7 command window

    - by tomlogic
    I'm doing some embedded DOS development with OpenWatcom (great Windows-hosted compiler for targeting 16-bit DOS applications). The target hardware has a 24x16 character screen (that supposedly emulates CGA to some degree), and I'm trying to get the CMD.EXE window on my Windows 7 machine to stay at a fixed 24x16 without any scroll bars. I've used both the window properties and MODE CON: COLS=24 LINES=16 to get the screen size that I wanted, but as soon as my application uses an INT10 BIOS calls to clear the screen, the mode jumps back to 80x24. Here's what I'm using to clear the screen: void cls(void) { // Clear screen and reset cursor position to (0,0) union REGS regs; regs.w.cx = 0; // Upper left regs.w.dx = 0x1018; // Lower right (of 16x24) regs.h.bh = 7; // Blank lines attribute (white text on black) regs.w.ax = 0x0600; // 06 = scroll up, AL=00 to clear int86( 0x10, &regs, &regs ); } Any ideas? I can still do my testing at 80x24 (or 80x25), but it doesn't entirely behave like the 24x16 mode.

    Read the article

  • Error "initializer element is not constant" when trying to initialize variable with const

    - by tomlogic
    I get an error on line 6 (initialize my_foo to foo_init) of the following program and I'm not sure I understand why. typedef struct foo_t { int a, b, c; } foo_t; const foo_t foo_init = { 1, 2, 3 }; foo_t my_foo = foo_init; int main() { return 0; } Keep in mind this is a simplified version of a larger, multi-file project I'm working on. The goal was to have a single constant in the object file, that multiple files could use to initialize a state structure. Since it's an embedded target with limited resources and the struct isn't that small, I don't want multiple copies of the source. I'd prefer not to use: #define foo_init { 1, 2, 3 } I'm also trying to write portable code, so I need a solution that's valid C89 or C99. Does this have to do with the ORGs in an object file? That initialized variables go into one ORG and are initialized by copying the contents of a second ORG? Maybe I'll just need to change my tactic, and have an initializing function do all of the copies at startup. Unless there are other ideas out there?

    Read the article

1