I'm writing an Intel Hex file reader for the application I am currently working on.
One thing I am unclear on in the Intel Hex File spec (http://microsym.com/editor/assets/intelhex.pdf) is what to do if a hex file has an Extended Segment Address and an Extended Linear Address. Is a file with both of those records (02 and 04) legal, or should it be rejected?
If it is legal, how is this handled? When reading in an extended segment address should the extended linear address be cleared (and vice-versa) or should they be combined somehow?
Thank You.
I have ran across this being handled in the source code of Microchip's AN1388
In WriteHexRecord2Flash() of Framework.c it looks like they add the two offsets derived from 02 and 04 records. I'm not saying that this is the correct way of doing things, but it has been the only thing that I have ran into so far that addresses this.
The specification does not seem to specify what to do in this situation.
Related
I have been using this site for many years now. It has been a huge help for me, so first of all thanks for everything. I almost always find the answers to my questions from previous posts, this is the first time I ask a question myself.
Ok, now to the main point. What is the actual protocol used to drive the PGD pin while sending the hex file to the target pic. I know that I could build a DIY ICSP Programmer from the countless projects found on the web but I truly want to understand the low level of this subject and build my own ICSP programmer for the sake of learning.
Some more details:
(Just to give you more info about what is on my mind)
The main idea is to use a pic with a USB module (say PIC18F2550) this pic will communicate with a software that sends the hex file to it. After PIC18F2550 stores this hex file (as raw data) in its memory it is going to send it to the target pic (the pic to be programmed) using the "ICSP protocol" (the thing I am looking for).
This link has the Programming Specification ( protocol ) for the chip family you want
Microchip Programming Specification for PIC18F2550 Family
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
TCP IP: Is it possible to read what TCP/UDP data a program is sending remotely?
I want to read a packet I've captured with Wireshark. The packet contains data, 133 bytes in length. It is not encrypted. Yet, the HEX form of the data decodes in Wireshark as a string of mostly unintelligible gibberish.
Is there any way to read this data in human-readable form? I'm just trying to figure out how a game client works, that's all.
You would have to know the format to convert it into human-readable form. It's like a book written in Chinese -- if you don't know Chinese, it's going to look like unintelligible gibberish. But it makes perfect sense to anyone who does know Chinese.
Figuring out the format from just the data is as difficult as learning Chinese just from a book written in Chinese. It can be done, but it's a highly-specialized art.
For example, you can try not moving and seeing which numbers stay the same. Then move, and see which numbers change. That might clue you in to where the position information is. However, the entire packet might be scrambled with a pseudo-random sequence, in which case, it will be nearly impossible without reverse-engineering the software.
I am attempting to write a userspace application that can hook into an OS's network stack, sniff packets flying past and edit ones that its interested in.
After much Googling, it appears to me that the simplest (yet reasonably robust) method of doing so (on any platform) is Linux's libnetfilter_queue project. However, I'm having trouble finding any reasonable documentation for the project, outside of the limited official documentation. Its main features (as stated by the first link are)
receiving queued packets from the kernel nfnetlink_queue subsystem
issuing verdicts and/or reinjecting altered packets to the kernel nfnetlink_queue subsystem
Emphasis is my own. How exactly am I meant go about this? I've tried modifying the sample code provided, but perhaps I am misunderstanding something. The code is operating in NFQNL_COPY_PACKET mode, so I am receiving the whole packet -- but my modifications to it seem to be restricted to my own application -- as one would expect, given the "copy" semantics.
My feeling is that I am meant to make use of NF_QUEUE somehow, but I haven't quite grokked it. Any pointers?
(If there is a simpler mechanism for doing this, which is also cross-platform, I'd love to hear about it!)
I can't believe I missed this previously. As reticent as I am to post questions on SO, I thought I would never work this one out myself. :)
I didn't look at the function prototype properly. It turns out in the "verdict" function (outlined below),
int nfq_set_verdict(struct nfq_q_handle *qh,
u_int32_t id,
u_int32_t verdict,
u_int32_t data_len,
const unsigned char *buf
)
The last two parameters are for the data to be returned to the network stack. Obvious in hindsight, but I missed it completely as the print_pkt function doesn't take the packet data as a parameter, but extracts it from the struct nfq_data.
The key is to NF_ACCEPT the packet and pass the suitably modified packet back to the kernel.
Just a wild guess from digging around the source code: try explicitly adding the mangled payload using nfnl_addattr_l(…, NFQA_PAYLOAD, …)?
All right, let me preface this by saying: I'm not completely confident this is programming-related. I'm trying to use software to solve a problem, but the software I actually trust; I suspect I'm doing something wrong with the hardware. However, I don't know where else to ask this question. Superuser already shot me down, and the Gadgets FAQ makes me think it's not a good fit there, either. If this question really strikes you as too off-topic to permit here, do what you gotta do. But, please. If you could go either way, I beg for your mercy.
I have a Pioneer DVD-V5000 player that I'm trying to control via 9-pin RS-232 port. (As opposed to the 15-pin port that's hard to find cables for.) Trouble is, I can't get the thing to acknowledge any commands. I'm not even getting any error messages back; only silence.
I have the specs for communicating with that port in front of me, and as far as I can tell I'm doing everything right; I'm sending two-character ASCII commands followed by a <CR>. I've gone into the Advanced Setup menu on the player, and have selected the 9-pin port (factory default is the 15-pin). The spec seems to be indicating the 9-pin port is perfectly standard; I don't see any indication I need some kind of custom cable to be using it. And I'm following all the setup protocols from the spec: 8-bit data length, 1-bit stop bit, no parity. Baud rate can be either 9600 or 19200, depending on the Advanced Setup, but neither works.
I'm fairly sure the software handling the COM-port communication isn't the problem. I've used a version of this software to successfully control another device, and I'm getting identical results (no response whatsoever) when I try to manually shove through commands with a serial port terminal.
Is there anybody familiar with Pioneer's serial-controlled electronics who can give me some suggestions about where I'm going wrong, or for other avenues of investigation?
For the sake of anybody else in a similar bind who stumbles across this question, I'll swallow my pride and record the correct solution, rather than just delete this into oblivion and pretend I was never this dumb. (Topicality hawks, I'm now far less worried about you nuking this thing.) The solution is unrelated to the specific hardware. It's all about the RS-232 cables and what NOT to do with them.
Specifically, if the F-F cable you have is too short, do not use a M-F cable as an extender -- or, if you do, use two of them. Regardless, your total number of cables MUST BE odd. What's Pin 2 on one end is supposed to be Pin 3 on the other end -- but if you have an even number of cables, then Pin 2 on one end goes to Pin 2 on the other end. This is wrong, and whatever gadget you're trying to talk to will rightfully ignore you. You will get very frustrated, fruitlessly Google away trying to figure out what you did wrong, and post lengthy questions of dubious topicality on your favorite Q&A site.
And seriously, who needs that?
Are pointers safe against online change of running PLC program in TwinCAT 2.10 and in CoDeSys 2.3 on which the first one is based? What happens if memory block gets reallocated as part of online program change and there are pointers pointing to that memory block?
ADR (Address Operator) description in TwinCAT's help says:
Attention:
After an Online Change there might be changes concerning the data on certain addresses. Please regard this in case of using pointers on addresses.
It looks to me like pointers cannot be stored permanently if someone pretends to use online modification of the program. Otherwise if pointers are stored (for example as a binding between some data structures) online change should be avoided.