I would like to maybe even take a class. This was my first OO language (and really my first real language period), which is why I couldn't read a spec and learn a language. Maybe that'd be possible if this was my 3rd or 4th language that I was learning?
I found out some information by grouping together a bunch of posted information that shows the code is instantiating a protocol, with linear feedback shift register verification.
I'm still trying to get used to this short hand of if/then/else and I can't seem to get the long hand version translation of the first code block? The second code block is my 4th attempt, I'm just not sure how they are setting lfsrData array value to 0xFE (254) or if true 1 else 0. That logic is escaping me?
First the Propeller Tool seems to open the serial port in 115200-8-N-1 mode. After toggling the DTR line to reset the Propeller, it transmits 0xF9 followed by a sequence of 0xFEs and 0xFFs. This sequence is followed by a large block of 0xF9s. I'm sure all this corresponds to the 250 iterations of the LFSR but I don't see how. When I tried to duplicate the LFSR in Python I couldn't get anything even remotely close. Then the Propeller responds with a similar (but different) block of 0xFEs and 0xFFs. Again I'm
sure this corresponds to the LFSR somehow. The Propeller then sends 2 bytes 0xFE 0xFE which I believe is the version number?
After this the Propeller Tools sends a command byte (RAM or EEPROM) followed immediately by block of data which corresponds to the binary image of the program. I haven't spent alot of time analyzing the format of the this data, but it doesn't seem to directly match up with the bytecodes of the program. Something weird is going on here and I think has to do with how the Propeller is "reading" the serial data.
Finally the Propeller Tool sends 0xF9 periodically (every 50msec seems to work) until the Propeller responds with 0xFE. This acknowledgment protocol can be repeated twice more if the command code was programming to the EEPROM.
The $F9 (249) is the 'calibration pulse'. The start pulse is a short (one) pulse while the two zero bits in the $F9 (249) is a long (zero) pulse. After that, the least significant bit of the LFSR is sent by the Tool, one per character, for 250 bits, with the $FF (255) being a short (one) pulse and the $FE (254) being a long (zero) pulse. Then the Propeller sends back the next 250 bits in the LFSR, also one bit per byte by echoing the $F9 (249) characters, changing them to $F8 (248) to indicate that they were processed properly.
After all the LFSR bits, the Tool and the Propeller shift into a 3 bits per byte mode with each bit cell being 3 bits and the start bit counting as one bit of the first cell (which is always zero). As you might expect, a one is a short (1 zero pulse time) and a zero is a long (2 zero pulse times) and the Propeller echos the data. There's a mix of 8 bit and 32 bit sequences, etc
The long-hand version is only meant to show what ?: does, it is not the same thing. The problem here is that if/else is a statement (so it has no value, only a side effect) and a?b:c is an expression (it computes a value).
On top of that, the || operator is a short circuiting operator that obviously (once you know what it does) can not work on bytes.
Furthermore, in C# arithmetic operators on bytes produce ints as result, so even if you fixed the other errors the compiler would complain about the type.
But that's all easy to solve, for example:
- by writing (byte)(IterateLFSR() ? 0xFF : 0xFE)
- by writing
x = 0xFF;
x = 0xFE;
(and then using x, of course)
- or (byte)(IterateLFSR() | 0xFE) if you change IterateLFSR to this:
_LFSR = unchecked((byte)((_LFSR << 1) | (_LFSR >> 7 ^ _LFSR >> 5 ^ _LFSR >> 4 ^ _LFSR >> 1) & 1));
return _LFSR >> 1; // the previous bit is still available, it just moved one place
I moved some stuff around there, but the result is the same (as a bit in an int instead of a bool that has to be converted back to that bit). The other bits in the result should be treated as garbage. Or-ing it with something that has 1 in all the high bits throws them out which is why it isn't a problem in IterateLFSR() | 0xFE.
If you're asking why the code does what it does, that answer can be found in the documentation for whatever chip this is driving.
Some parts of that code look rather strange, you might want to go back to the source (metaphorically speaking, not this source code!) and rewrite the protocol code yourself. It would be a good exercise in 'bit-twidding' in C#. Does this code actually work? It doesn't look like it should in a few places unless the underlying protocol is weird.
First of all you should have a flag field on your users table which determines which user are online. On my databases this field I name it as "logged" with the type of bit and then on the time when the user is logged to the application then this field will be updated to true and on the time when he is loged out then will be false. Since you have this flag on your users table it's very easy to know which users are online.
Do you really need to sort the collection itself or just view it as sorted without changing the underlying collection? If the first, follow the previous answers. If the second, then you can just expose an ICollectionView[^] and bind to that rather than to the root collection.
hi frnds im doing a project and in a face of adding a forum in my project so is there anyone who can help me....with code or ideas regd forum in .net c#.....im new here and wish ur help and support dear friends........
- Please do not use text speech. it's annoying to read. Also use full sentences and try to correct spelling errors before posting. Not everybody is native English, but do give an effort.
- People will not give you code. They will only point you in the right direction if you have a well defined problem. It helps if you explain what you tried or what you searched for yourself. If you do post code, do so with smaller snippets.
- We don't dislike you, but we're not your friends.
- Don't expect people to put time into research and formulating an answer when you can't put time in asking the question.
I built a plugin for a parent application on an x86 OS at work, and came home to try it and it would not work. I got the error code of "0x8007000B" when trying to load the dll which lead me to find out that because dll was set to build to anycpu there is some sort of conflict.
Does anyone have any idea as to how to fix this so that it always works, no matter the CPU architecture?
There is no general solution, applicable to all applications. The fundamental rule is a process must be homogeneous, i.e. consist of all x86 or all x64 code; so e.g. you can't build a plug-in that works for both a 32-bit and a 64-bit native app (say Internet Explorer).
However, if app and plug-in are both managed code, then building for x86 should always work, as each x64 processor and Windows version (at this moment) is able to execute x86 code as well. One caveat: you need all referenced files on your machine, and that may be tricky in some situations.
Remark: Visual Studio Express doesn't let you choose, it generates "AnyCPU" (Google will yield some work-arounds though). Full Visual Studio lets you choose, unfortunately the default is "AnyCPU", which may cause your app to start as a 64-bit process, to later discover some needed native file isn't available for 64-bit (warning: on Win64, 64-bit system code resides in system32, and 32-bit code in systemWow64!).
With some further troubleshooting, I have discovered something interesting. I thought the problem was the plugin dll I had written, but it turns out it was actually a resource dll that was inside of my projects plugin dll. So the hierarchy is this:
I do not have any control over either the Parent Applications code or the resource dll. It looks as if when the Parent application and the plugin I wrote are ran as a 64bit application (on a 64bit OS) the resource dll will not load. Does this sound like a reasonable diagnosis? If so, is there a work around for this situation?
The main code decides on the word size of the process (either directly by being built for 32 or 64bit, or by looking at the OS when managed and "AnyCPU"); everything else must comply to the top-level code.
Hence, if resource.dll is 32-bit, it all must be 32-bit; there is no way around that.