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.
Sometimes, a debate isn't nonsense, even if the debate is started by a troll.
Issues when reverse-engineering binaries are still issues. So it is still just as relevant to make sure that the correct version of the source code and the requirements specifications are never, ever, lost, as long as there are any economic interest in a product, or any need to be able to supply bug fixes.
Just because a processor can read op-codes like a native, it is so easy for people to think that it is easy to take a binary and recreate source code in a way that is meaningful to maintain. Just that the optimization steps used by compilers (and sometimes, like for 8051, linkers) can wreak havoc on any structure of the original source code. And the op-code sequences can represent lots of ambiguities that can't be easily resolved without specific knowledge about the product - knowledge that probably was lost at the same time as the original source code. And that costs lots of money for a developer to regain when trying to learn everything about the workings of the product.