We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Kiosk provider seeking an 8051 assembly language developer to patch firmware to: * Add two i2c commands: 1-turn on 2-turn off Notes: 1. Device has pre-existing soft power control. 2. Device has pre-existing operational I2C interface. 3. Current firmware is available only as ROM image. 4. We -possibly- have some C source code for the 8051-based controller, but it is not configured for the product, nor includes past manufacturer provided customizations. It is probably mostly useful as a reference tool. Deliverable Requirements 1. ROM image: a. With new I2C on/off command functionality. b. Upon boot, the device must start in the existing on state. c. All existing functionality must still be operational. d. Provided in the same ROM-able Intel hex format the original firmware image was supplied in. 2. New functionality in deliverable #1 must pass 100 I2C command off/on test cycles. 3. Assembly language listing for deliverable #1, with descriptive comments documenting changes. 4. Deliverables must be provided within 6 business days from when both parties agree to commencement of work. Available Resources We can provide for the duration of the work: * One controller board for development/testing. -and- * One end-product module which uses the controller board. Work Quotation Please e-mail: * Your all-in fixed price for the work. * Relevant qualifications. * The option of partial payment mid-way through project requires two strong references. Otherwise, payment is upon receipt of the required deliverables.
Has enough experience with patching 8051 binary images to provide a solid quote.
in the olden days when a compile took measurable time, I did quite a bit of "patching 8051 binary image" when debugging BUT, and here's the crux, I could see from source and link map how and where.
"patching 8051 binary image" with nothing but a "8051 binary image" as a reference is one of those "I will know how long it takes when I'm done"
Erik
PS not interested, too busy with other work, otherwise it would be fun, but no way I would do it with up front pricing.
PPS what processor, maybe it is just plain impossible
But patching a binary wouldn't be done by disassembling all of the binary and document.
It would just be locating the parts of the binary that was related to the patch, and then either patch in-place if the patch was smaller than the original code, or jump to free space and there place the patch before returning back to the old code again.