The FRAM (Ferroelectric Random Access Memory) Fujitsu MB85RC256V FRAM MB85RC256V-20171207-5V1 says in page 8 that
• Page Write: If additional 8 bits are continuously sent after the same
command (except stop condition) as Byte Write, a page write is
performed.
This needs no interpretation. But then, on the next page it would say:
• Current Address Read: When the previous write or read operation
finishes successfully up to the stop condition and assumes the last
accessed address is “n”, then the address at “n+1” is read by sending
the following command unless turning the power off.
My question regards interpretation of whether the English in "up to the stop condition" means the same as "except stop condition"?
I guess that not only the English needs to be understood, but also how the device works.
I believe that the two are equal, also inferred from trying to understand how the device seems to work:
Write 8 bits device address with R/W=0=write bit,
then write 16 bits FRAM memory address "n",
then do no stop bit because we could now
send an 8 bits device address with R/W=1=read bit,
then continue to read (first from address "n+1") as many bytes as needed,
until the final stop bit.
This will effectively mean that reading from an address, we need to first set the address register to one lower.
Please correct if my understanding is not 100% correct.
Aside: I have used this FRAM in an earlier project, but via a function called i2c_master_16bit_read_reg in obsoleted library module_i2c_master (which is so hard to understand). The newer lib_i2c does not have that functionality, so I have to do it by extending the XC interface function there. I am using lib_i2c 5.0: XMOS I2C Library (XC is sadly also obsoleted for lib_xcore and C by XMOS, but I still have an older xTIMEcomposer system up and running)
I guess that the next chapters of [ref1], "Random read" and "Sequential read" would show rather explicitly that the stop condition P is indeed only written when "all is done".
In other words, "up to the stop condition" does mean the same as "except stop condition".
I will correct here after I have implemented the code, should my own answer not be correct.
Related
I'm not sure if this is the good website for ladder logic programming questions but I will it a try.
I'm using a Click PLC C0-01 DR-D by Koyo (Desc page: http://www.automationdirect.com/adc/Overview/Catalog/Software_Products/Programmable_Controller_Software/CLICK_PLC_Programming_Software) with it's free software. I'm trying to make a program in Ladder Logic to executes multiples operations by the PLC. To keep track of the current operation, I use an integer value I'm incrementing as the current operation ID. However, I'm not able to reset this value to 0.
First I tried with the COPY but there's a radio button to ignore zeros. This radio button is checked and disabled (can't change it). . The documentation of the software says "Option: This Option is available when the Source is a Data Memory Register Address and the Destination is a TXT Address." But since I just want an ID and I need to compare this ID with = everywhere in my program and increment it, I don't want to put a string.
Then, I can use math to assign a formula to a variable. I tried put zero and it's working half the time. Note that the "One shot" checkbox isn't selected even if it may to be acting like so.
About this option, the documentation says "One Shot: Select One Shot to solve the formula only once after each OFF-to-ON transition of the enabling rung."
However, to be able to set the value to 0 again, I need to restart the PLC. When I first execute the program everything is fine because the value is already 0. When I restart it, the value didn't reset so it's still 7 and it skips all my operations. Then it resets to 0 (it's doing so at the end) and when I restart the PLC, I'm able to run it normally for one time.
Here an example of the current passing but the value not set:
Is it a bug from the PLC ? Is there a workaround ?
In short, I'm looking for a reliable way to set a value to 0.
Thanks in advance for the answers. Sorry If I violated 40 rules, I'm new and happy to join this community.
I though I resolved my problem but I just pushed it further. Thanks to Garry Shortt with his youtube channel dedicated to PLC programming for helping me out with my problem.
His explanation to the problem is "Changed the math to a copy command and placed it in the main program where you had it before. The program seems to work well.
The only thing that I can think of is when you use subroutines, and they are not being scanned. The items within the routine is the same unless you them changed in another part of your program."
Hope it will be helpful for someone someday.
I am working on the MSP430 microcontroller and was going through its architecture. In the user guide, under its features tab, there is a statement like this - "Full register access including program counter (PC), status register (SR), and stack pointer (SP)". I was under the impression that the CPU always has access to all the registers irrespective of the architecture.
My understanding of the statement may be wrong. Can anyone explain me what it means exactly?
As per the wikipedia page:
The processor contains 16 16-bit registers, of which 4 are dedicated to special purposes: R0 is the program counter, R1 is the stack pointer, R2 is the status register, and R3 is a special register called the constant generator, providing access to 6 commonly used constant values without requiring an additional operand. R3 always reads as 0 and writes to it are ignored. R4 through R15 are available for general use.
In other words, "full access" in this case means not just using jmp-type instructions to be able to jump to a new location, but also allowing something like xor r0, #1234 to directly (and probably fatally) modify the program counter.
Ditto for the other special registers, except R3, the constant generator and the only one of the four not mentioned in your quote. While all the instructions could operate on that register, it ignores writes and generates various fixed values on read (-1..2, use of R2 can also give you 4 and 8) depending on the addressing mode used.
That may seem a little strange but it's not the strangest I've ever seen. For that, you would have to investigate the RCA1802A CPU which, like the MPS430 had "general purpose" registers for specific functions but you could actually choose at run time which should be the program counter or stack pointer. It actually had no call or ret instructions, instead it used a standard call and return technique (SCRT) to emulate it.
Why all programs are divided into 200 basic blocks by Valgrind? And how to divided?
First Question
It's been some time since I've worked on a Valgrind tool (even longer than this question is old), but in case anyone is still interested, here's what I've dredged up from memory:
First, a distinction: a super block is a bit different from a basic block. Valgrind uses super blocks, not basic blocks. A super block may exit at any point, but a basic block will only ever exit by running off its end.
Valgrind doesn't divide a program into 200 super blocks. I'm pretty sure that it instead breaks programs up into super blocks of no more than 200 IRStatements (which may or may not translate directly into instructions).
The reason for this I'm pretty sure is for efficiency of the translator: at least with current versions of Valgrind I'm reasonably sure it doesn't translate your entire program up front. Translating the program into its IR format is time consuming and resource intensive, so the translator seeks to only translate as much of the program as it needs to. It does this by only translating code as it gets executed for the first time.
Second Question
Now, as to your second question... I'm not entirely sure what you're asking. If you're asking, "How does Valgrind decide how to divide up the program?", then the answer is that it decides similarly to a compiler. It starts converting the program into super blocks, and starts a new super block whenever it reaches the block limit size or detects that there is an entry point into the block from elsewhere (super blocks and basic blocks can only have one entry point).
If you instead meant, "Can I change the size of an IRSB super block?", then yes, there is an option you can pass back to Valgrind in your tools initialization code to tell it what size super blocks you want (although I don't recall if you can increase this to an arbitrary size). None of this is documented online, and only sparsely documented in the files themselves. You can take a look at the source to the other tools to see how they pass configuration options to Valgrind during initialization. That should at least give you a good idea on which headers to look at to figure out what option you need to pass back to Valgrind.
Good news, my c64 ist still running after lots of years spending time on my attic..
But what I always wanted to know is:
How can I automatically load & run a program from a floppy disk that is already inserted
when I switch on the c64?
Some auto-running command like load "*",8,1 would be adequate...
Regards
MoC
You write that a command that you type in, like LOAD"*",8,1 would be adequate. Can I assume, then, that the only problem with that particular command is that it only loads, but doesn't automatically run, the program? If so, you have a number of solutions:
If it's a machine language program, then you should type LOAD"<FILENAME>",8,1: and then (without pressing <RETURN>) press <SHIFT>+<RUN/STOP>.
If it's a BASIC program, type LOAD"<FILENAME>",8: and then (without pressing <RETURN>) press <SHIFT>+<RUN/STOP>.
It is possible to write a BASIC program such that it automatically runs when you load it with LOAD"<FILENAME>",8,1. To do so, first add the following line to the beginning of your program:
0 POKE770,131:POKE771,164
Then issue the following commands to save the program:
PRINT"{CLR}":POKE770,113:POKE771,168:POKE43,0;POKE44,3:POKE157,0:SAVE"<FILENAME>",8
This is not possible without some custom cartridge.
One way to fix this would be getting the Retro Replay cartridge and hacking your own code for it.
I doubt there is a way to do it; you would need a cartridge which handles this case and I don't think one like that exists.
A better and more suitable solution is EasyFlash actually. Retro Replay is commonly used with its own ROM. Since it is a very useful cartridge by default ROM, I would never flash another ROM to it. Also it is more expensive than EasyFlash if you don't have any of those cartridges.
At the moment, I have Prince Of Persia (!) ROM written to my EasyFlash and when I open my c64, it autoruns just like you asked for.
Not 100% relevant, but C128 can autoboot disks in C128 mode. For example Ultima V (which has musics on C128 but not on C64 or C128 in C64 mode) autoboots.
As for cartridges, I'd recommend 1541 Ultimate 2. It can also run games from module rom images (although Prince of Persia doesn't work for me for some reason, perhaps software issue?), but you also get rather good floppy emulator (which also makes it easier to transfer stuff to real disks), REU, tape interface (if you order it) etc.
If you are working with a ML program, there are several methods. If you aren't worried about ever returning to normal READY prompt without a RESET, you can have a small loader that loads into the stack ($0100-$01FF) The loader would just load the next section of code, then jump to it. It would start at $0102 and needs to be as small as possible. Many times, the next piece to load is only 2 characters, so the file name can be placed at $0100 & $0101. Then all you need to do is set LFS, SETNAM, LOAD, then JMP to it. Fill the rest of the stack area with $01. It is also rather safe to only save $0100-$010d so that the entire program will fit on a single disk block.
One issue with this, is that it clears out past stack entries (so, your program will need to reset the stack pointer back to the top.) If your program tries to do a normal RTS out of itself, random things can occur. If you want to exit the program, you'll need to jmp to the reset vector ($FFFC by default,) to do so.
Would it be possible to take the source code from a SNES emulator (or any other game system emulator for that matter) and a game ROM for the system, and somehow create a single self-contained executable that lets you play that particular ROM without needing either the individual rom or the emulator itself to play? Would it be difficult, assuming you've already got the rom and the emulator source code to work with?
It shouldn't be too difficult if you have the emulator source code. You can use a method that is often used to store images in c source files.
Basically, what you need to do is create a char * variable in a header file, and store the contents of the rom file in that variable. You may want to write a script to automate this for you.
Then, you will need to alter the source code so that instead of reading the rom in from a file, it uses the in memory version of the rom, stored in your variable and included from your header file.
It may require a little bit of work if you need to emulate file pointers and such, or you may be lucky and find that the rom loading function just loads the whole file in at once. In this case it would probably be as simple as replacing the file load function with a function to return your pointer.
However, be careful for licensing issues. If the emulator is licensed under the GPL, you may not be legally allowed to store a proprietary file in the executable, so it would be worth checking that, especially before you release / distribute it (if you plan to do so).
Yes, more than possible, been done many times. Google: static binary translation. Graham Toal has a good howto paper on the subject, should show up early in the hits. There may be some code out there I may have left some code out there.
Completely removing the rom may be a bit more work than you think, but not using an emulator, definitely possible. Actually, both requirements are possible and you may be surprised how many of the handheld console games or set top box games are translated and not emulated. Esp platforms like those from Nintendo where there isnt enough processing power to emulate in real time.
You need a good emulator as a reference and/or write your own emulator as a reference. Then you need to write a disassembler, then you have that disassembler generate C code (please dont try to translate directly to another target, I made that mistake once, C is portable and the compilers will take care of a lot of dead code elimination for you). So an instruction of a make believe instruction set might be:
add r0,r0,#2
And that may translate into:
//add r0,r0,#2
r0=r0+2;
do_zflag(r0);
do_nflag(r0);
It looks like the SNES is related to the 6502 which is what Asteroids used, which is the translation I have been working on off and on for a while now as a hobby. The emulator you are using is probably written and tuned for runtime performance and may be difficult at best to use as a reference and to check in lock step with the translated code. The 6502 is nice because compared to say the z80 there really are not that many instructions. As with any variable word length instruction set the disassembler is your first big hurdle. Do not think linearly, think execution order, think like an emulator, you cannot linearly translate instructions from zero to N or N down to zero. You have to follow all the possible execution paths, marking bytes in the rom as being the first byte of an instruction, and not the first byte of an instruction. Some bytes you can decode as data and if you choose mark those, otherwise assume all other bytes are data or fill. Figuring out what to do with this data to get rid of the rom is the problem with getting rid of the rom. Some code addresses data directly others use register indirect meaning at translation time you have no idea where that data is or how much of it there is. Once you have marked all the starting bytes for instructions then it is a trivial task to walk the rom from zero to N disassembling and or translating.
Good luck, enjoy, it is well worth the experience.