I have created a JavaFX application to retrieve data from a FTDI peripheral device. I used JNAerator to generate the the API and everything works beautifully on my development machine (OS X). However, when tested on a coworker's box (Windows), the BirdJ Pointer.getBytes() method returns byte arrays where every value is off by exactly 128.
Is there a known platform difference or something else in Java that would explain this inconsistent behavior or is this more likely a problem in the native FTDI drivers?
Is there a cleaner way to resolve it than by introducing ugly platform specific logic to modify every byte read or written?
EDIT
I'm not sure my problem description was clear. Here is a specific example.
I request 3 bytes from the FTDI device to confirm it is ready to send data. I get [-91, -1, -1] which matches the documentation saying to expect "A5 FF FF". My code is written to accept that answer and everything proceeds just fine.
My coworker gets [37, 127, 127] which is "25 7F 7F". Since that is not the expected value, my code reports an error and exits.
Calling SetDataCharacteristics to ensure that all words use 8 bits solved my problem.
Related
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.
I've been filling myself up with notes trying to successfully create my first program on Windows 7 with NASM, but with a few self imposed stipulations (until I'm ready to move forward). In creating this first program, however, I have a ton of questions.
.
The stipulations for now are that:
I'm running Window 7 SP1 - 64-bit
I do not wish to use DOSBox so Interrupts 0x21-24 are likely not applicable
I do not wish to rely on C so this is all NASM
I would really like to avoid downloading Visual Studio or associated WDK tools if I can (this depends on whether or not I NEED to interact with the Windows API and relates to Question 2 below)
I've downloaded and installed MinGW
I'm writing my code in Notepad++ and saving as *.asm
I am linking using "ld" for now, but from what I've read, most seem to recommend "GoLink" (and Alink hasn't been updated in years?). I'll probably migrate to GoLink after I've assured myself that "ld" may be too limiting
I want to know if printing is possible without the use of the Windows API or C because of the code below?
.
The only code example that has worked for me in some capacity can be found here.
nasm is not executing file in Windows 8
.
;FILE: main.asm
[section] .text
global _main
_main:
mov eax, 6
ret ; returns eax (exits)
Linked:
c:\Users\James\Desktop>nasm -fwin32 main.asm
c:\Users\James\Desktop>ld -e _main main.obj -o main.exe
c:\Users\James\Desktop>main.exe
c:\Users\James\Desktop>echo %errorlevel%
6
.
My questions (a ton):
The fact that in the code above "ret" by itself gives output, although it just returns whatever is in EAX, is there a way to use it (or another directive outside of the Windows API) to return the contents of a variable (hopefully a string variable)? I tried to use ret with DOS calls, but as noted above, that definitely doesn't work because I'm on a 64-bit system.
In case I absolutely must use the Windows API, is the only way to interact with it by using the WDK tools? Is there some other way because that last time I downloaded Visual Studio and associated WDK tools it took up a ton of memory and massively slowed down my computer. Is there another way to make programs give output or print to the screen either by using internal commands or some other method to use API calls? One thread I admittedly skimmed (amidst 40 more tabs I have open) mentions "Russinovich's Windows Internals" but not a direct answer. At current every time I use code with the extern commands "ld" tells me that the references to commands like WinMain/WinMain#16 are undefined. In the same vein is there a table I can consult containing accurate calls to the API (i.e. _ExitProcess#4 vs. ExitProcess). I found this link to what think may be the NT API but I'm not sure it applies given my stipulations, but in reality, I'm just kind of confused:
http://j00ru.vexillium.org/ntapi/
In bits of code I've encountered I've seen directives for [Bit 16], [Bit 32], and [Bit 64]. [Bit 16] is likely ignorable, but I'm confused by the [Bit 32] and [Bit 64] for the following reasons which may not even be related: Via the code above I'm using the command, "nasm -fwin32 main.asm", then I'm linking it successfully and going on to receive output. For some reason - though I have not read the full "ld" documentation yet - when I use the command "nasm -fwin64 main.asm" and link it in the same way I receive an error saying "main.obj: File not recognized: File format not recognized". I don't understand why differentiating between 32 and 64 while I'm on a native 64-bit machine causes an error although this probably is just unique to ld.
.
In the meantime I'll be reading this question and will post an update it if helps: Executable isn't compatible with 64 bits processor
I can't answer some parts in great detail, so I expect somebody either putting up better answer, or feel free to edit this one.
you are linking against default clib, so your _main is called after Clib is initialized, the ret with value in eax is like return 6; in C++. Then Clib correctly destructs everything and calls windows exit process with exit code 6. You can return only int from _main, and I'm not even sure if full int is propagated to exit process call, or only 8 bit value is used. So you can return single char in ASCII encoding, if you treat that number as char.
You must call Windows API, if you want to display something in console/window, or write something into file, ie. do any output (and of course also for input). There's no peripheral available to win32/64 executable directly, like in DOS CGA/EGA/VGA text modes accessible trough int 10h or video ram at B800:0000. Any try to access some I/O peripheral directly should result into access violation. Only Win API should be legal for user-level application code.
How much of WDK you need I have no idea, haven't developed anything for windows for years. I think it's even possible to create executable without WDK, which would provide correct externs and dependencies on kernel32.dll and similar, but the amount of effort is way beyond simply using proper parts of WDK or clib from MinGW.
I think your linker is set to default to 32b executable, you have to figure out what kind of object format is produced by nasm for -fwin64 and how link that one with ld.
Why the difference. The 64b OS can run 32b binaries. But you can't mix 32/64 in single executable so easily (if at all). So you are either producing 32b or 64b binary, and you have to adjust everything to it (asm instructions used, directives and options, and WinAPI calls).
I am trying to make an interface with another program so I have to use C++.
It's been years since I have programmed in C++ and I have been at this problem for about a week so I'm slowly starting to see how everything works.
I want to read byte data coming from a serial port device.
I have verified that I can get text through the serial port using the readline command:
For example:
String^ message = _serialPort->Readline();
Is how the data is read in an example from MSDN that I got to work successfully.
However I have tried to modify it several times and I'm having no luck coming up with something that reads the data as bytes. (I already have conversion of byte data to string so I can actually see the bytes such as the number 15 equaling 0f in bytes.)
Modifying the code to
wchar_t message = _serialPort->Readline();
gives me
error c2440: 'initializing' : cannot convert from System::String ^' to 'wchar_t'.
I'm not familiar with Readline. Is it only for strings? I have verified that it does work with strings and if I use a serial device that sends a string the first set of code does work.
Can someone explain what method I could use to read byte data? Thanks.
If you actually want to use C++ rather than C++/CLI, I recommend using boost.asio. It is well established, relatively easy to understand, and has a specific set of functionality just for working with serial ports.
Update
Pure C++ Win32 API versions:
See the following good references
CodeProject article
MSDN
Is there any specific reason you are doing this in C++/CLI code?
I thought you might not even be aware of that (otherwise, tag your questions, please).
String^, Readline etc are CLR functions (i.e. .NET, think: "you could do this more easily in C#). So, again,
If there is a need for this to be in C++, why don't you look at the native Win32 API
Otherwise, why are you bothering with C++
If you really wanted C++/CLI I suggest not mixing native/managed code when handling the serial IO. You can get an UnmanagedMemoryStream to marshal the data in/out of managed land.
$0.02
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.
I am writing windows32 hooks around DirectX 6.1 library to DirectX 9.0c; Idea is to replace all calls to DX 6.1 3D device with calls to Direct 9.0c and inject some custom code, so old game which I am patching (99' year) will be able to use shaders, post-effects, etc.
The old DX 6.1 3D device was created by creating DDraw module. Game is then enumerating device caps. In my module the entire DDraw module is skiped and 3D view is initialized. So I have problem as I can't give the game Ddraw4 device caps which it requires as I do not have DDraw device at all!
So my question is how to obtain DDraw4 device caps without initializing DDraw4 device. Perhaps it will be sufficient to create fixed list and feed it to the game, but I have no idea what should be on that list (I gave what I thought it should be, and the game exited - logger showed it was just after device caps checked)
I've never tried this, but you might try the following. Assuming you don't have the 6.1 SDK, you could make the DDCAPS structure (the DirectDraw one) yourself (it's basically just DWORDs), then get the capabilities (D3DCAPS9) using the DX9 GetDeviceCaps function. Next, take the values you need from the acquired caps (using DX9) and set the equivalent values for DirectDraw in your DDCAPS structure. You could then feed this populated caps structure to the game. A few caveats--as you mentioned, you don't know what it needs specifically, so it's kind of hit and miss (unless you have the source code). Also, there may not be a 1:1 mapping for the caps structure values (between DX9 and DDraw). Finally--this ties in with not having the 6.1 SDK--if you don't know the flag values, you might set a flag incorrectly when setting the values according to the acquired caps. As I mentioned, this may be way off (or require a lot of detective work), but I figured it might be something you could try.
The solution was a bit crude, but most importantly - is working flawlessly.
I've written small self-contained utility, which initialize DDraw 6.1, than gets device caps, then dump them to the file on disk (device caps is Plain Old C format structure, so saving it is really simple) and quits. Then I can read the device caps file from disk and return it when application ask me for them.