Owen has mentioned another of my HW/SW axioms. If you have done all of the things in SW that seem reasonable without seeing any real progress on SW, blame the hardware and go find out why the HW isn't working. I have been bitten way too many times chasing issues with HW bring up or just new SW on a previously working platform. After one day of chasing your tail with SW inexplicably not working, it is a reasonable thing to check the HW to make darn sure it didn't fail while you were doing your SW stuff.

You say you are having trouble reading the data from SPI. DO you have a basic understanding of SPI? To shorten the process in case the answer is no, I am going to take a wild guess that you may not be aware that in order to read 16 bits of data, you first have to clear your input buffer (may or may not be necessary), write 16 bits of either good data or just 16 bits of zeros. That write of 16 bits will force your device to spit out 16 bits of data onto MISO. Only *then* you can read the 16 bits of real data from your device. Same applies whether you are reading 16 bits of data, or 8 bits, or 24 bits, etc. There is another issue with SPI. It comes in 4 flavors. It depends on the device you are trying to read/write. I once had an issue where the HW engineer didn't realize he had put a type 1 and a type 3 device on the same SPI bus. It has to do with when the data is valid and the edge of the clock where the data is valid. You can't put a type one and a type 3 on the same bus unless you change the mode at the Master for *every* transaction :( Just trying to preemptively point you at possible problems based on not enough information in your post. Hope this helps. Feel free to IM me. I am one of those weird HW guys who also is a heavy duty embedded SW guy. You could build your own logic analyser given enough time using a TI MSP432E launchpad or a Tiva 1294 Launchpad. Then you could transfer the data to a PC logger that would gather the data and store it. A lot of work but it would let you control what gets stored. A real logic analyser is a better bet though in terms of the time spent.

Charlie: I see I am falling into the next thread (Sure sign I should retire -- I know what a Wang and an AS/400 are). Batch files predate MS-DOS. They were how things were done on RT-11 and RSX-11 on PDP-11 computers. Many of the C and Unix and early PC operating system guys all started on PDP-11s (circa 1975) when they were in school. So the guy you are looking for probably is very long dead and buried near Boston. I suppose it is interesting that it is still possible to write really horrible batch files to run in a command window. Just recently did an update on a set of TeraTerm command files. Interesting, but not something I would do by choice! The guy who *really* deserves our hatred is the guy who created all the macros for MASM and early versions of Microsoft C. If you ever had a bug caused by one of those, you could spend a career just trying to unroll all of the macros :-) :-(

Honey, that is exactly why they are confusing! The problem is English and the really sloppy way programmers use English! Pointers do not actually "point" to a memory location. The fact that you can get to a data element in memory and that method that can be manipulated as if it were a number is a *compiler specific concept* in the C family of languages. And an incredibly stupid idea that creates tons of security vulnerabilities. NEVER, EVER use a pointer as if it were a number. ALWAYS use it as an abstract data type and you will avoid 99.9% of pointer type defects in your code. I am mentoring a young woman who is taking her first real programming class (Python *DOES NOT* count). --------------- Here is what I told her: Anyone who has ever written in a "proper" language like Pascal, Modula, PLM-86, or Ada or who studied actual Computer Science will tell you that a "pointer" is an abstract data type that is nothing more than a handle to some object in your program. There are *NO* operations defined for a pointer other than connection to some object, referencing an object (either an actual object in C++, C#, Ada, etc. or a struct or intrinsic in C) or copying a pointer to another pointer of the same type. You can literally use a "pointer" as a handle to carry data around in your program from one place to another. In some languages we use the word "reference" as a synonym for a pointer. I also gave her a physical example of how pointers can be used in linked lists. ---------------- Kernighan and Ritchie (bless their hearts) improperly called a data type by the CS name "pointer" when they should have named it an "address". They ARE NOT the same thing. In modern computers, that is absolutely the case because the "address" you get is just a virtual mapping of an actual address to some other thing that just happens to be a number (but you have to understand hardware to understand why that is). K&R (or some folks after them) also screwed up the keyword "static" which has two *completely different* meanings depending on context. The list of things screwed up in C is a long one! It is why the MISRA standard is necessary. C was just readable assembly language for the PDP-11 computer which got moved over time to other computers. Because you are forced on very small computers to play tricks in C/assembler in order to save data and code space, C has some really egregious history of confusing pointers with addresses and the fact that you can actually see a *real* computer underneath the virtu