I want to protect my hex code to just run one electronic circuit.
So I want protect my hexadecimal code against copying.
How can I do this ?
If you want your code to run just once, you should destroy your own code when it ran one circuit.
WHEN finished
copy ptr loc_memory_start, 0000
;comment: fill in zeros at the start of program.
END
Related
I would really like some help with this one.
I have a requirement to play an audio file, read the numeric values and end playing another audio file all on the one line, can this be done in the dialplan?
For example I want to be able to say.
You have a incoming call for(playing) & 15 (read minutes) & minutes(playing). I need to put this into the Dial() string as the mA.
You have macro and gosub procedures for that.
M(macro[^arg[^...]]):
U(x[^arg[^...]]):
https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Application_Dial
Etc.
If that not works for you, you have rewrite app dial.
I hope to read some characters or strings and display them with QTextBrowse from serial port by Qt 4.8.6 and called the following functions( textBrowser is a object of QTextBrowser):
connect(com, SIGNAL(readyRead()), this, SLOT(readSerialPort()));
connect(textBrowser, SIGNAL(textChanged()), SimApplianceQtClass, SLOT(on_textBrowser_textChanged()));
void SimApplianceQt::on_textBrower_textChanged()
{
ui.textBrowser->moveCursor(QTextCursor::End);
}
void SimApplianceQt::readSerialPort()
{
QByteArray temp = com->readAll();
ui.textBrowser->insertPlainText(temp);
}
However, every time I cannot display characters or strings in the textBrowser rightly. Those input strings are always cut into smaller strings to be displayed in multiple lines in the textBrowser. For example, a string "0123456789" may be displayed as (in multiple lines):
01
2345
6789
How to deal with this issue? Many thanks.
What happens is that the readyRead signal is fired not after everything has been received, but after something has been received and is ready to read.
There is no guarantee that everything will have arrived or is readable by the time you receive the first readyRead.
This is a common "problem" for almost any kind of IO, especially if the data is larger than very few bytes. There is usually no automatic way to know when all the data has been received.
There are a few possible solutions:
All of them will require you to put the data in a buffer in readSerialPort() instead of adding it directly to the text browser. Maybe a simple QByteArray member variable in SimApplianceQt would already do the trick in your case.
The rest depends on the exact solution.
If you have access to the sender of the data, you could send the
number of bytes that will be sent before sending the actual string.
This must always be in an integer type of the same size (for
example, always a quint32). Then, in readSerialPort(), you would
first read that size, and then continue to read bytes to your buffer
in readSerialPort() until everything has been received. And then,
you could finally print it. I'd recommend that one. It is also what is used in almost all cases where this problem arises.
If you have access to the sender of the data, you could send some
kind of "ending sequence" at the end of the string. In your
readSerialPort(), you would then continue to read bytes into your
buffer until you receive that ending sequence. Once the ending
sequence has been received, you can print everything that came in
prior to it. Note that the ending sequence itself could be interrupted,
so you'd have to take care of that, too.
If you do not have access to the sender, the best idea I could come
up with would be to work with a timer. You put everything into a
buffer and re-start that timer each time you readSerialPort() is
called. When the timer runs out, that means no new data has been
sent for a while and you can probably print what you have so far.
This is... risky and I wouldn't recommend it if there is any other way.
I am trying to disassemble a code from a old radio containing a 68xx (68hc12 like) microcontroller. The problem is, I dont have the access to the interrupt vector of the micro in the top of the ROM, so I don't know where start to look. I only have the code below the top. There is some suggestion of where or how can I find meaningful routines in the code data?
You can't really disassemble reliably without knowing where the reset vector points. What you can do, however, is try to narrow down the possible reset addresses by eliminating all those other addresses that cannot possibly be a starting point.
So, given that any address in the memory map that contains a valid opcode is a potential reset point, you need to either eliminate it, or keep it for further analysis.
For the 68HC11 case, you could try to guess somewhat the entry point by looking for LDS instructions with legitimate operand value (i.e., pointing at or near the top of available RAM -- if multiple RAM banks, then to any of them).
It may help a bit if you know the device's full memory map, i.e., if external memory is used, its mapping and possible mapped peripherals (e.g., LCD). Do you also know CONFIG register contents?
The LDS instruction is usually either the very first instruction, or close thereafter (so look back a few instructions when you feel you have finally singled out your reset address). The problem here is some data may, by chance, appear as LDS instructions so you could end up with multiple potentially valid entry points. Only one of them is valid, of course.
You can eliminate further by disassembling a few instructions starting from each of these LDS instructions until you either hit an illegal opcode (i.e. obviously not a valid code sequence but an accidental data arrangement that looks like opcodes), or you see a series of instructions that are commonly used in 68HC11 initialization. These involve (usually) initialization of any one or more of the registers BPROT, OPTION, SCI, INIT ($103D in most parts, but for some $3D), etc.
You could write a relatively small script (e.g., in Lua) to do the basic scanning of the memory map and produce a (hopefully small) set of potential reset points to be examined further with a true disassembler for hints like the ones I mentioned.
Now, once you have the reset vector figured out the job becomes somewhat easier but you still need to figure out where any interrupt handlers are located. For this your hint is an RTI instruction and whatever preceding code that normally should acknowledge the specific interrupt it handles.
Hope this helps.
Memory in pic microcontrollers is cleared by ones so we get 3FFF for an empty word (of 14 bits). But 0b11 1111 1111 1111 is ADDLW 255 according to the datasheet. Why not fill everything with zeros (NOPs) or GOTO 0000h? What if code execution gets to those 3FFFs, will it get to reset vector 0000h eventually? If yes will there be any side effects?
Also interrupt vector 0004h is 3FFF by default, does it mean that the code after it will be executed on interrupt?
A typical FLASH (also EEPROM) memory is erased when all bits of memory are set to the one. During programming of FLASH memory bits can only be set to zero. So before programming of FLASH we must do a special sequence named erasing, after that the memory is ready to be programmed.
The "0b11 1111 1111 1111" opcode is ADDLW 255 and ALU should always executed it. Normally compiler translate your program and the programmer program opcodes to appropriate FLASH memory locations, after that the memory check is made, so don't care about wrong opcode execution!
You can only read and write to an arduino's memory about 100,000 times. I was wondering if there was a proper way of testing if an Arduino has run out of reads and writes to its internal memory other then it just not saving anything. I just want to be sure that's whats happening before I buy a new one. Thanks in advance
Just like the quote, "measurement changes state", you must first waste a write to prove you can read it back correctly.
Erasing a cell is setting all bits to 1, so you could write 0x00, check all bits are what you expect, then write 0xFF completing a full cycle. If the cell has 'cleared' to 0xFF then the cell is still good. However there is no guarantee the next write will work when you put your actual data in it.
Keeping track of the state of each cell/block and verifying the contents on write is part of what would typically be implemented in a wear leveling routine, and would allow you to provide data integrity for as long as possible.