怎么通过指针读取字节

版本=（Unt8*T*）（0x400 - 1）；应该BeValue=（const Unt8*T*）（0x400—1）；（不知道为什么使用中介指针）版本，而不是JavaSpS2Buf= *（const Unt8*T*）（0x400—1）；



      以下为原文

    version = (uint8_t *)(0x400 - 1);
 
should be
 
version = (const uint8_t *)(0x400 - 1);
 
(not sure why you're using the intermediary pointer "version" there instead of just
 
SSP2BUF = *(const uint8_t *)(0x400 - 1);

你需要用某种方式传达指针指向闪存的想法，而不是RAM。OR不确定它会起作用。但你总是可以看看拆卸，看看到底发生了什么。



      以下为原文

    You need to somehow convey the idea that the pointer points to flash, not to RAM.
 
version = (const uint8_t *)(0x400 - 1);
 
or
 
version = (uint8_t *)(0x8400 - 1);
 
I'm not sure it's going to work. But you always can look at the disassembly to see what is actually happening.
 

真的？我可以想象它将错误的值加载到SSPBUF中，但不会崩溃。有一个很好的机会，发送的值将是0x00。这会不会导致其他事情失火？



      以下为原文

   
Really?
I can imagine it loading the wrong value into SSPBUF, but not crashing.
There's a good chance the value sent will be 0x00. Will that cause something else to misfire?
 

我不知道PIC指针是如何实现的，但是如果它是RESLW，那可能会崩溃。



      以下为原文

   
 
I don't know how const pointers are implemented on that PIC, but if it's RETLW, that could crash.

好点约翰，但我怀疑它是在16F1xxx芯片中这样做的。指针将被加载到一个FSR对中。



      以下为原文

    Good point John, but I doubt it's done that way in a 16F1xxx chip.
The pointer would just be loaded into one of the FSR pairs.

由XC8 Pro 1.34 SO编译的POST 1版本显然是将指针加载到0x83FF，然后将其复制到FSR1，然后将Idf1复制到SSP2BUF。它应该从ROM中的偏移0x3FF中获取值，因此它应该作为尼尔的意图工作。切换到PRO模式给出了与下一篇文章完全相同的代码，即它消除了中间指针变量。



      以下为原文

    Post#1 version compiled by XC8 pro 1.34
598: void nktest(void)
  18B5 30FF MOVLW 0xff
599: {
600: uint8_t const *version;
601: version = (uint8_t *)(0x400 - 1);
  18B6 0020 MOVLB 0
  18B7 00A0 MOVWF 0x20
  18B8 3083 MOVLW 0x83
  18B9 00A1 MOVWF 0x21
602: SSP2BUF = *version;
  18BA 0820 MOVF 0x20, W
  18BB 0086 MOVWF 0x6
  18BC 0821 MOVF 0x21, W
  18BD 0087 MOVWF 0x7
  18BE 0801 MOVF 0x1, W
  18BF 0024 MOVLB 0x4
  18C0 0099 MOVWF 0x19
603: }
  18C1 0008 RETURN
So plainly it is loading the pointer with 0x83FF, then copying that to FSR1, then copying INDF1 to SSP2BUF.
That should have grabbed the value from offset 0x3FF in the ROM, so it should have worked as Neil intended.
 
EDIT
The above code was generated in FREE mode. Switching to PRO mode gave exactly the same code as in the next post.
i.e. it eliminated the intermediate pointer variable
 

按照我建议的方式（使用Extn）和JTPLE版本来生成完全相同的代码。



      以下为原文

    And doing it the way I suggested (with extern)
599: extern const uint8_t majorVersion @(0x400-1);
600: extern const uint8_t minorVersion @(0x400-2);
601:
602: void nktest(void)
  279E 30FF MOVLW 0xff
603: {
604: SSP2BUF = majorVersion;
  279F 0084 MOVWF 0x4
  27A0 3083 MOVLW 0x83
  27A1 0085 MOVWF 0x5
  27A2 0800 MOVF 0, W
  27A3 0024 MOVLB 0x4
  27A4 0099 MOVWF 0x19
605: }
  27A5 0008 RETURN
 
and jtemples version generates exactly the same code.
 
 
 

这种方法似乎是从代码空间读取的：



      以下为原文

    This method seems to read from CODE space:---  C:PublicPIC16F16F194616F1946_Test.8main.c  --------------------------------------------
1:                 #include
2:                 
3:                 volatile unsigned char Major;
4:                 volatile unsigned char Minor;
5:                 
6:                 void main ( void )
  07E4    30FF     MOVLW 0xff
7:                 {
8:                     const unsigned char * pCode;
9:                     pCode = (const unsigned char *)(0x400-1);
  07E5    00F1     MOVWF main@pCode
  07E6    3083     MOVLW 0x83
  07E7    00F2     MOVWF main@pCode+1
10:                
11:                    for(;;)
12:                    {
13:                        Major = *pCode--;
  07E8    0871     MOVF   main@pCode, W
  07E9    0084     MOVWF  FSR0L
  07EA    0872     MOVF   main@pCode+1, W
  07EB    0085     MOVWF  FSR0H
  07EC    0800     MOVF   INDF0, W
  07ED    00F0     MOVWF  0x70      ; dance of the
  07EE    0870     MOVF   0x70, W   ; de-optimizer
  07EF    00F4     MOVWF  Major
  07F0    3001     MOVLW  0x1
  07F1    02F1     SUBWF  main@pCode, F
  07F2    3000     MOVLW  0
  07F3    3BF2     SUBWFB main@pCode+1, F
14:                        Minor = *pCode;
  07F4    0871     MOVF   main@pCode, W
  07F5    0084     MOVWF  FSR0L
  07F6    0872     MOVF   main@pCode+1, W
  07F7    0085     MOVWF  FSR0H
  07F8    0800     MOVF   INDF0, W
  07F9    00F0     MOVWF  0x70      ; dance of the
  07FA    0870     MOVF   0x70, W   ; de-optimizer
  07FB    00F3     MOVWF  Minor
15:                    }
  07FC    2FE8     GOTO 0x7e8

底线，原来的代码应该已经工作，其他东西是造成“崩溃”。



      以下为原文

    Bottom line, the original code should have worked, something else is causing the "crash".
 

因为XC8使用了整个程序中指针使用的所有历史来决定指针（它们的大小和内存类型），一个小的例子不一定表明在一个更大的程序中会发生什么。



      以下为原文

   


 
Because XC8 uses all the history of pointer usage across the program to make decision about pointers (their size and kind of memory), a small example is not necessarily indicative of what could happen in a bigger program.
 
What is the nature of the "crash"?

因为：McCyPrimeAddioStudio/SPI2. C：239：警告：（358）非法转换指针到PielGMCCH生成文件/SPI2. C：239：错误：（712）不能为这个表达式生成代码，这是我的第一个猜测。您的方法工作得更好，但它正在损坏某些东西。或者开始做怪异的事情，比如永远嘟嘟声。也许它没有恢复什么东西，因为它在中断中。我使用了Flash API，看起来很高兴。它只是不那么优雅。



      以下为原文

   

Because:
mcc_generated_files/spi2.c:239: warning: (358) illegal conversion of pointer to integer
mcc_generated_files/spi2.c:239: error: (712) can't generate code for this expression
That was my first guess.
 
Your method works better but it is corrupting something.
I get the correct answer, but It crashes or starts doing weird stuff, like beep forever.
Maybe it is not restoring something, since it is in the interrupt.
I used the Flash API it seems happy with that.
It is just less elegant.

那是我原来的帖子里的一个打字错误。它应该是BSP2BUF＝*（const Unt8*T*）（0x400—1）；



      以下为原文

   
 
That was a typo in my original post.  It should be
 
SSP2BUF = *(const uint8_t *)(0x400 - 1);

坠落不同于LED的疯狂舞蹈。哔哔哔哔声永远响，而不是几秒钟。将军只是在工作，我刚刚断了什么东西。我认为你是正确的指针。它必须对如何访问它感到困惑。在一个中断中，也许Flash API是留下来的方法。



      以下为原文

    The crash varies from the LEDs dancing wildly. The Beeper beeping forever, instead of a few seconds.
General it was just working what did i just break stuff.
I think you are right about the Pointer. It must be confused about how to access it.  And in an interrupt.
Maybe the Flash API is the way to stay.
 

这可能是问题，但我不知道如何。FSRX寄存器在PIC16F1XXX设备中断期间自动保存，所以除非您允许嵌套中断，否则不能成为原因。



      以下为原文

   
This could be the problem, but I'm not sure how.
The FSRx registers are automatically preserved during interrupts in PIC16F1xxx devices, so unless you are allowing nested interrupts, that can't be the cause.

有些事是错误的。我不确定我有时间追踪它。特别是因为我能很容易地工作。也许杰夫或MLP会重来。



      以下为原文

    Something is wrong. I am not sure I have the time to track it down. Especially since I can work around it so easily.
Maybe Jeff or MLP will weigh in.

因为你正在读指针，而不是写它，它不太可能破坏某些东西。我猜在其他地方有一个bug消失了，当你正在调整的代码变长或缩小时，它就会重新出现。试着用不同的NoP替换它，看看“崩溃”是否持续。



      以下为原文

    Since you're reading pointer, not writing it, it is very unlikely to corrupt something.
 
I guess there's a bug somewhere else which disappears and reappears as the code you're tweaking grows or shrinks. Try replacing it with different stretches of nops and see if the "crashes" persist.

阅读可能会导致问题。我尝试了5个（比）10个（），程序正常运行。我只是不确定我有时间深入研究ASM。



      以下为原文

    Reading may use RETLW which can cause issues.
I tried 5 NOP()s than 10 NOP().
The program worked normally each way.
 
I am just not sure I have the time to dig deeper in to the ASM.
 

不，它在一个增强的PIC16设备中没有这样做。我在它上面做了什么。你可以看看你的LST文件，看看它在你的代码中做什么。它不到5分钟就可以看到它产生了什么代码。



      以下为原文

   
No, it doesn't do that in an enhanced PIC16 device.
I posted above what it does.
You can just look in your LST file to see what it's doing in your code.
 

It should take less than  5 minutes to see what code it generated.