Author Topic: PIC18F1320 in a Raman Spectrometer  (Read 7121 times)

0 Members and 1 Guest are viewing this topic.

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: PIC18F1320 in a Raman Spectrometer
« Reply #50 on: February 06, 2023, 07:14:10 am »
There is no standard header and checksum. UART is just bytes. Everything else is application specific. This is exactly why reverse-engineering of protocols is hard sometimes.

You need to do what that person did, but for your device. First of all, the thing that normally happens in the first 5 minutes of investigation is to determine the baudrate. Then receive a lot of data, look at it and see if you can observe any patterns. Then try to figure out if there is some structure. A lot of guessing and theories involved here.
« Last Edit: February 06, 2023, 07:17:27 am by ataradov »
Alex
 

Offline plancTopic starter

  • Regular Contributor
  • *
  • !
  • Posts: 149
  • Country: us
Re: PIC18F1320 in a Raman Spectrometer
« Reply #51 on: February 06, 2023, 08:04:39 am »


I will no longer do any reverse engineering. It is not easy.

The following is program I personally made for the HC11. Note how simple it is. Just enable the serial port and send Hello, Why is there no headers and checksum in the serial output? Does it mean the source has headers and checksum disabled?  You can tell from the few lines what is the case (it's just generic serial subroutine I saw). Can you do that in the ARM too? disabling them?

Also to write Hello output, would it require many times more machine language lines using the ARM? Note it has "space" added to Hello such that no matter how many times you close and open the serial program, it can resync. Without it. It turns to garbage. If it is easy to write this in the ARM. I may get same model as yours and run it. What particular ARM do you own?

Code: [Select]
REGBASE EQU $1000
SPCR    EQU $1028
BAUD    EQU $102B
SCCR1   EQU $102C
SCCR2   EQU $102D
SCSR    EQU $102E
SCDR    EQU $102F

                ORG     $0100

START LDAA #%00110000      ;    00110000 = 9600 BAUD
STAA BAUD            ;    00110011 = 1200 BAUD
CLR SCCR1
LDAA #$0C
STAA SCCR2           ;RECEIVER & TRANS. ENABLED
clr SPCR

LOOP

                ldaa    #72           ; send "H" to serial
read_again      ldab $102e           ;
bitb    #$80
beq read_again
staa SCDR           ;

                ldaa    #101           ; send "e" to serial
read_again      ldab $102e           ;
bitb    #$80
beq read_again
staa SCDR           ;

                ldaa    #108          ; send "l" to serial
read_again      ldab $102e           ;
bitb    #$80
beq read_again
staa SCDR           ;

                ldaa    #108           ; send "l" to serial
read_again      ldab $102e           ;
bitb    #$80
beq read_again
staa SCDR           ;

                ldaa    #111          ; send "o" to serial
read_again      ldab $102e           ;
bitb    #$80
beq read_again
staa SCDR           ;

                ldaa    #32          ; send "space" to serial
read_again      ldab $102e           ;
bitb    #$80
beq read_again
staa SCDR           ;

BRA     LOOP


 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: PIC18F1320 in a Raman Spectrometer
« Reply #52 on: February 06, 2023, 08:16:35 am »
Why is there no headers and checksum in the serial output?
Because you did not program them.

Does it mean the source has headers and checksum disabled?
There is nothing to disable. You are really misunderstanding how UART works. There is no inherent structure. UART just sends individual bytes. You as a programmer decide what they mean. You may decide that a first byte of all your messages would be '#' and this would be your "header". This is not something you absolutely have to do. You may just dump plain text and then you won't need any headers.

the ARM?
ARM is just a core architecture, specific peripheral details depends on a device based on that architecture. Generally, ARM is more complicated, since it is way more capable. And nobody programs in ASM anyway.

What particular ARM do you own?
I "own" dozens of devices. It is not something I idly play with, I use whatever is best suited for a particular project.

With your current level of understanding there is no chance you will be able to use ARM-based devices. It requires reading of documentation and you refuse to do that.
Alex
 

Offline plancTopic starter

  • Regular Contributor
  • *
  • !
  • Posts: 149
  • Country: us
Re: PIC18F1320 in a Raman Spectrometer
« Reply #53 on: February 07, 2023, 01:15:30 am »
Why is there no headers and checksum in the serial output?
Because you did not program them.

Does it mean the source has headers and checksum disabled?
There is nothing to disable. You are really misunderstanding how UART works. There is no inherent structure. UART just sends individual bytes. You as a programmer decide what they mean. You may decide that a first byte of all your messages would be '#' and this would be your "header". This is not something you absolutely have to do. You may just dump plain text and then you won't need any headers.

the ARM?
ARM is just a core architecture, specific peripheral details depends on a device based on that architecture. Generally, ARM is more complicated, since it is way more capable. And nobody programs in ASM anyway.

What particular ARM do you own?
I "own" dozens of devices. It is not something I idly play with, I use whatever is best suited for a particular project.

With your current level of understanding there is no chance you will be able to use ARM-based devices. It requires reading of documentation and you refuse to do that.

Thanks for all the information.

Last question. I will avoid any ARM-based devices and any that requires C language.

What is the fastest most advanced 32 bit microcontroller  you know that has assembly very similar to the 68HC11 Assembly Language?  I don't want to learn C. I'm not earning anything out of this so I don't want to waste time and learn C. I only want modern MCU with Assembly Language similar to the HC11 I'm already familiar with so I can quickly send the Hello program and see the output.

I also want to explore IR spectroscopy. I'm very tired with Raman. I can't borrow any IR spectrometer so want to build a simple one and needs the most modern microcontroller as this would be the one and final MCU I'd ever own. I don't want the Arduino or Raspberry PI because they are not 32 bit and you need to know C. Many thanks.

 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: PIC18F1320 in a Raman Spectrometer
« Reply #54 on: February 07, 2023, 01:21:17 am »
What is the fastest most advanced 32 bit microcontroller  you know that has assembly very similar to the 68HC11 Assembly Language?
I have no idea how HC11 assembly looks like. You can program any modern MCU in assembly, includeing all ARM-based MCUs, it is just incredibly inconvenient and slow. But if all you are going to be doing are those 20-line tiny programs, then any would work.  And you would have hard time finding example code, since nobody does that.

You would still need to read MCU documentation. And it is generally pretty long for modern devices.

And the amount of C you need to learn is minimal. And you are still going to have to learn a different variety of assembly, I can guarantee that nothing would be exactly like HC11.

The argument "it does not make me money" is also strange. Nothing would make you money until you learn it enough to start extracting that money.
« Last Edit: February 07, 2023, 01:24:49 am by ataradov »
Alex
 

Offline ozcar

  • Frequent Contributor
  • **
  • Posts: 320
  • Country: au
Re: PIC18F1320 in a Raman Spectrometer
« Reply #55 on: February 07, 2023, 04:42:36 am »

Code: [Select]
REGBASE EQU $1000
SPCR    EQU $1028
BAUD    EQU $102B
SCCR1   EQU $102C
SCCR2   EQU $102D
SCSR    EQU $102E
SCDR    EQU $102F

                ORG     $0100

START LDAA #%00110000      ;    00110000 = 9600 BAUD
STAA BAUD            ;    00110011 = 1200 BAUD
CLR SCCR1
LDAA #$0C
STAA SCCR2           ;RECEIVER & TRANS. ENABLED
clr SPCR

LOOP

                ldaa    #72           ; send "H" to serial
read_again      ldab $102e           ;
bitb    #$80
beq read_again
staa SCDR           ;

                ldaa    #101           ; send "e" to serial
read_again      ldab $102e           ;
bitb    #$80
beq read_again
staa SCDR           ;

                ldaa    #108          ; send "l" to serial
read_again      ldab $102e           ;
bitb    #$80
beq read_again
staa SCDR           ;

                ldaa    #108           ; send "l" to serial
read_again      ldab $102e           ;
bitb    #$80
beq read_again
staa SCDR           ;

                ldaa    #111          ; send "o" to serial
read_again      ldab $102e           ;
bitb    #$80
beq read_again
staa SCDR           ;

                ldaa    #32          ; send "space" to serial
read_again      ldab $102e           ;
bitb    #$80
beq read_again
staa SCDR           ;

BRA     LOOP



Do you really have an assembler that does not complain about duplicate symbol "read_again" for the code as shown?
 

Offline plancTopic starter

  • Regular Contributor
  • *
  • !
  • Posts: 149
  • Country: us
Re: PIC18F1320 in a Raman Spectrometer
« Reply #56 on: February 07, 2023, 05:20:17 am »
What is the fastest most advanced 32 bit microcontroller  you know that has assembly very similar to the 68HC11 Assembly Language?
I have no idea how HC11 assembly looks like. You can program any modern MCU in assembly, includeing all ARM-based MCUs, it is just incredibly inconvenient and slow. But if all you are going to be doing are those 20-line tiny programs, then any would work.  And you would have hard time finding example code, since nobody does that.

You would still need to read MCU documentation. And it is generally pretty long for modern devices.

And the amount of C you need to learn is minimal. And you are still going to have to learn a different variety of assembly, I can guarantee that nothing would be exactly like HC11.

The argument "it does not make me money" is also strange. Nothing would make you money until you learn it enough to start extracting that money.

I read there is C and C++ created in the early 1970s.

Do all MCUs use the same C language? So if I can figure out how to say "Hello world" in the 68HC11 (which has C to .s19 converter), the same C program can run in all of your MCUs??

Even though I was able to download the EEG MSP430 firmware (so surprised they didn't even JTAG blow the fuse with just one click). I couldn't understand its machine language after reading them using CCS and IRQ (because as you said, there are also many kinds of Assembly languages). However, the Ghidra Reverse Engineering software can turn the MSP430 to machine code and then to C++.

That means what appear to be very complicated machine code in the MSP430 can be easily converted to C++ and understood more easily? But most MCUs use C only, and not C++.

Also if someone say in China stole your firmware and you live in the US, how are you gonna sue him in China?

(oscar, I ran it using AS11.EXE. THRSIM11 simulator can't run them if the labels have duplicates. I'll try using different labels and and ran them again in AS11.EXE)
 

Offline ozcar

  • Frequent Contributor
  • **
  • Posts: 320
  • Country: au
Re: PIC18F1320 in a Raman Spectrometer
« Reply #57 on: February 07, 2023, 05:33:52 am »
(oscar, I ran it using AS11.EXE. THRSIM11 simulator can't run them if the labels have duplicates. I'll try using different labels and and ran them again in AS11.EXE)

The ancient version of AS11 I have here from the days I used to tinker with HC11 does complain. If something does not complain, then I can only guess that maybe later use of the same symbol replaces the earlier one from that point onward (and you would have to be very careful not to get yourself into trouble with that).

Really that code should be in a subroutine, rather than repeating it every time.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: PIC18F1320 in a Raman Spectrometer
« Reply #58 on: February 07, 2023, 05:46:11 am »
the same C program can run in all of your MCUs??
No. You really need to let go of HC11. There is literally nothing like it anymore. None. If you are going to measure everything by how much it looks like HC11, then you can't use anything.

That means what appear to be very complicated machine code in the MSP430 can be easily converted to C++ and understood more easily? But most MCUs use C only, and not C++.
Ghidra output is not useful directly. It is just a rough sketch of what the program might look like, it never actually compiles back to the useful code.

C is just  a generic language.  The difference between MCUs  is in the peripherals. And again, this is a concept you need to understand well before programming anything. you won't be able yo do anything until you do.

Also if someone say in China stole your firmware and you live in the US, how are you gonna sue him in China?
You don't. But you can prevent import of that product to the US. It would require a lot of effort, but it is possible.
Alex
 

Offline plancTopic starter

  • Regular Contributor
  • *
  • !
  • Posts: 149
  • Country: us
Re: PIC18F1320 in a Raman Spectrometer
« Reply #59 on: February 07, 2023, 06:21:41 am »
the same C program can run in all of your MCUs??
No. You really need to let go of HC11. There is literally nothing like it anymore. None. If you are going to measure everything by how much it looks like HC11, then you can't use anything.

That means what appear to be very complicated machine code in the MSP430 can be easily converted to C++ and understood more easily? But most MCUs use C only, and not C++.
Ghidra output is not useful directly. It is just a rough sketch of what the program might look like, it never actually compiles back to the useful code.

C is just  a generic language.  The difference between MCUs  is in the peripherals. And again, this is a concept you need to understand well before programming anything. you won't be able yo do anything until you do.

Also if someone say in China stole your firmware and you live in the US, how are you gonna sue him in China?
You don't. But you can prevent import of that product to the US. It would require a lot of effort, but it is possible.

I know the difference between MCUs is in the peripherals and different registers to enable ADC for example. So different MCUs have different programs to enable them. I know because I spent 2 months late last year trying to run different registers in the ADC and other peripherals of the HC11 to figure out how the app can distinguish between 2 channels. I tried all sorts of combinations.  After fixing the firmware missing codes (when I became familiar with assembly language enough to figure out the firmware lines that got deleted by their own pc app). I finally understood it used synchronization characters for 2 channels.

And the whole reason I tried to download the firmware of the latest EEG model using MSP430 was to figure out how they could read from the 24 bit external ADC with very clean signal. Now since I found out I couldn't analyze the 27k firmware and how they did it. I just want to know now what MCUs have 24 bit external ADC with existing circuit diagram and library (open source for example)?? So I could just use it, and just ran the library. You know most MCUs have lousy 12 bit ADC with noises. That's why they use 24 bit external ADC for cleaner signal.

Btw.. for the lousy 12 bit ADCs in the best MCU you have encountered, what are the exact noises present that could make 24 bit external ADC so important ?

 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: PIC18F1320 in a Raman Spectrometer
« Reply #60 on: February 07, 2023, 06:33:53 am »
Well, UART is a peripheral, so it would be different between different MCUs. So, you can't take C code for one MCU and compile it for another MCU without changing device-specific parts.

You've already been pointed at a few MCUs that have higher resolution SDADC. Those may or may not be good enough for your application.

Even if you fond some readily available eval board with 24-bit ADC and a MCU (there are not too many of those, I imagine), all the example code would be in C. And it is not likely that example code would do precisely what you want, so you would have to modify it anyway.

Internal ADCs in the MCUs are not meant for metrological applications.

But also, 24-bits is not about accuracy or resolution, but about dynamic range. If you don't need wide dynamic range, you can use low noise amplifier and use internal ADC just as well.
Alex
 

Offline plancTopic starter

  • Regular Contributor
  • *
  • !
  • Posts: 149
  • Country: us
Re: PIC18F1320 in a Raman Spectrometer
« Reply #61 on: February 07, 2023, 08:13:35 am »
(oscar, I ran it using AS11.EXE. THRSIM11 simulator can't run them if the labels have duplicates. I'll try using different labels and and ran them again in AS11.EXE)

The ancient version of AS11 I have here from the days I used to tinker with HC11 does complain. If something does not complain, then I can only guess that maybe later use of the same symbol replaces the earlier one from that point onward (and you would have to be very careful not to get yourself into trouble with that).

Really that code should be in a subroutine, rather than repeating it every time.

Oscar. You are few of the people I know who is familiar with the HC11. So please don't miss the reply to the above (I'll repost this here and delete the reply an hour ago)


I run As11.exe now. It doesn't complain and correctly jumps to the label just above it. That's why it could still output the txt "Hello". I also changed all labels to unique ones. And the same. I know unique labels are important because I was lost in the loop late last year until I discovered the duplicate labels can miss things up. As11.exe doesn't report any error.

Anyway. I think you missed the reply (dated January 28) to your query about Trace. After reading about your Trace thing. I connected jumper XIRQ and PA3, and saw Trace worked for the first time.



Again. I wrote and asked in that January 28 message (pls answer it, thanks).

"A while ago. I used the trace function in Buffalo for the first time. It worked so nice. Didn't know the unit could really do that. But I noticed that whenever it passed through an interrupt enable (for example the CLI which enabled the Real Time Interrupt) . The trace got stuck on the next instruction"

1. Why did it get stuck after passing through instruction that enabled the interrupt? How do you proceed after it got stuck?
 

Offline ozcar

  • Frequent Contributor
  • **
  • Posts: 320
  • Country: au
Re: PIC18F1320 in a Raman Spectrometer
« Reply #62 on: February 07, 2023, 10:17:46 am »

Oscar. You are few of the people I know who is familiar with the HC11. So please don't miss the reply to the above (I'll repost this here and delete the reply an hour ago)


I run As11.exe now. It doesn't complain and correctly jumps to the label just above it. That's why it could still output the txt "Hello". I also changed all labels to unique ones. And the same. I know unique labels are important because I was lost in the loop late last year until I discovered the duplicate labels can miss things up. As11.exe doesn't report any error.


Show us the listing for that assembly when you use the same name several times.

The AS11.EXE that I have throws out this (and refuses to give a normal listing):

Code: [Select]
27: Symbol Redefined
33: Symbol Redefined
39: Symbol Redefined
45: Symbol Redefined
51: Symbol Redefined

If I change the symbols to be unique, it produces this listing:

Code: [Select]
0001 1000                    REGBASE EQU $1000
0002 1028                    SPCR    EQU $1028
0003 102b                    BAUD    EQU $102B
0004 102c                    SCCR1   EQU $102C
0005 102d                    SCCR2   EQU $102D
0006 102e                    SCSR    EQU $102E
0007 102f                    SCDR    EQU $102F
0008                         
0009 0100                                    ORG     $0100
0010                         
0011 0100 86 30              START LDAA #%00110000      ;    00110000 = 9600 BAUD
0012 0102 b7 10 2b            STAA BAUD            ;    00110011 = 1200 BAUD
0013 0105 7f 10 2c            CLR SCCR1
0014 0108 86 0c              LDAA #$0C
0015 010a b7 10 2d            STAA SCCR2           ;RECEIVER & TRANS. ENABLED
0016 010d 7f 10 28            clr SPCR
0017                         
0018                         LOOP
0019                         
0020 0110 86 48                              ldaa    #72           ; send "H" to serial
0021 0112 f6 10 2e           read_again      ldab $102e           ;
0022 0115 c5 80              bitb    #$80
0023 0117 27 f9              beq read_again
0024 0119 b7 10 2f            staa SCDR           ;
0025                         
0026 011c 86 65                              ldaa    #101           ; send "e" to serial
0027 011e f6 10 2e           read_again1      ldab $102e           ;
0028 0121 c5 80              bitb    #$80
0029 0123 27 f9              beq read_again1
0030 0125 b7 10 2f            staa SCDR           ;
0031                         
0032 0128 86 6c                              ldaa    #108          ; send "l" to serial
0033 012a f6 10 2e           read_again2      ldab $102e           ;
0034 012d c5 80              bitb    #$80
0035 012f 27 f9              beq read_again2
0036 0131 b7 10 2f            staa SCDR           ;
0037                         
0038 0134 86 6c                              ldaa    #108           ; send "l" to serial
0039 0136 f6 10 2e           read_again3      ldab $102e           ;
0040 0139 c5 80              bitb    #$80
0041 013b 27 f9              beq read_again3
0042 013d b7 10 2f            staa SCDR           ;
0043                         
0044 0140 86 6f                              ldaa    #111          ; send "o" to serial
0045 0142 f6 10 2e           read_again4      ldab $102e           ;
0046 0145 c5 80              bitb    #$80
0047 0147 27 f9              beq read_again4
0048 0149 b7 10 2f            staa SCDR           ;
0049                         
0050 014c 86 20                              ldaa    #32          ; send "space" to serial
0051 014e f6 10 2e           read_again5      ldab $102e           ;
0052 0151 c5 80              bitb    #$80
0053 0153 27 f9              beq read_again5
0054 0155 b7 10 2f            staa SCDR           ;
0055                         
0056 0158 20 b6              BRA     LOOP


Anyway. I think you missed the reply (dated January 28) to your query about Trace. After reading about your Trace thing. I connected jumper XIRQ and PA3, and saw Trace worked for the first time.

...

Again. I wrote and asked in that January 28 message (pls answer it, thanks).

"A while ago. I used the trace function in Buffalo for the first time. It worked so nice. Didn't know the unit could really do that. But I noticed that whenever it passed through an interrupt enable (for example the CLI which enabled the Real Time Interrupt) . The trace got stuck on the next instruction"

1. Why did it get stuck after passing through instruction that enabled the interrupt? How do you proceed after it got stuck?

I used Buffalo to "debug" HC11 code, but I don't recall ever using the trace facility - I was used to other monitor programs for 6800 and 6809 that did not have anything like that. Looking now at how the trace works I'm pretty sure a badly behaved user program could cause trouble, as the ram locations used by Buffalo itself are not protected in any way. I'm not saying that is what happened, but it is a possibility.

If things went wrong when you enabled IRQ, are you sure the interrupt handling code was set up correctly? Show the listing of the code you were trying to trace. If you were trying to trace execution in Buffalo itself, well, I'm not sure that is supported - it makes my head hurt to think what might happen.

« Last Edit: February 07, 2023, 10:21:07 am by ozcar »
 

Offline plancTopic starter

  • Regular Contributor
  • *
  • !
  • Posts: 149
  • Country: us
Re: PIC18F1320 in a Raman Spectrometer
« Reply #63 on: February 07, 2023, 10:54:14 am »
If the filename is hw.txt with the multiple identical read_again labels. I used the following commands to compile in ms dos

as11 hw.txt   
or
as11 hw.txt -1 >hw.1st

The hw.1st is empty when there is no error, and it successfully compiled to hw.s19 which I can run in the HC11.

How do you show the listing with the address 0001 1000..    0009 0100??  I'll try to reproduce that listing because I haven't seen it before (address listed).

About the interrupt and trace. It's the EEG firmware itself. I think when it encountered the real time interrupt enabled, it waits for the interrupt in the background and so the trace got stuck. It only happens whenever it passed by CLI. The firmware works perfectly because it can send the 2 channels into one serial stream and then separately splits or outputs them at the EEG pc software.

« Last Edit: February 07, 2023, 10:55:50 am by planc »
 

Offline ozcar

  • Frequent Contributor
  • **
  • Posts: 320
  • Country: au
Re: PIC18F1320 in a Raman Spectrometer
« Reply #64 on: February 07, 2023, 11:24:17 am »
If the filename is hw.txt with the multiple identical read_again labels. I used the following commands to compile in ms dos

as11 hw.txt   
or
as11 hw.txt -1 >hw.1st

The hw.1st is empty when there is no error, and it successfully compiled to hw.s19 which I can run in the HC11.

How do you show the listing with the address 0001 1000..    0009 0100??  I'll try to reproduce that listing because I haven't seen it before (address listed).


I was using -L option on the command, so similar to your command, but in upper case. I just tried it now with -l instead, and that works too. If I don't use either, I just get an empty file. Maybe there is some way to set up defaults for the options, but it is so long since I was using this that I have forgotten.

But it seems the AS11 you have may be different.
 

Offline plancTopic starter

  • Regular Contributor
  • *
  • !
  • Posts: 149
  • Country: us
Re: PIC18F1320 in a Raman Spectrometer
« Reply #65 on: February 07, 2023, 12:49:42 pm »
If the filename is hw.txt with the multiple identical read_again labels. I used the following commands to compile in ms dos

as11 hw.txt   
or
as11 hw.txt -1 >hw.1st

The hw.1st is empty when there is no error, and it successfully compiled to hw.s19 which I can run in the HC11.

How do you show the listing with the address 0001 1000..    0009 0100??  I'll try to reproduce that listing because I haven't seen it before (address listed).


I was using -L option on the command, so similar to your command, but in upper case. I just tried it now with -l instead, and that works too. If I don't use either, I just get an empty file. Maybe there is some way to set up defaults for the options, but it is so long since I was using this that I have forgotten.

But it seems the AS11 you have may be different.

Oh my gosh. I just realized I had been using the wrong switch the whole 4 months I was using the HC11. I used number one 1 instead of L in the -L (I used -1). When I used the right -L now. It also listed it. But no error. I ran

As11 hw.txt -L >hw.1st

Code: [Select]
0001 1000                    REGBASE EQU $1000
0002 1028                    SPCR    EQU $1028
0003 102b                    BAUD    EQU $102B
0004 102c                    SCCR1   EQU $102C
0005 102d                    SCCR2   EQU $102D
0006 102e                    SCSR    EQU $102E
0007 102f                    SCDR    EQU $102F
0008                         
0009 0100                                    ORG     $0100
0010                         
0011 0100 86 30              START LDAA #%00110000      ;    00110000 = 9600 BAUD
0012 0102 b7 10 2b            STAA BAUD            ;    00110011 = 1200 BAUD
0013 0105 7f 10 2c            CLR SCCR1
0014 0108 86 0c              LDAA #$0C
0015 010a b7 10 2d            STAA SCCR2           ;RECEIVER & TRANS. ENABLED
0016 010d 7f 10 28            clr SPCR
0017                         
0018                         LOOP
0019                         
0020 0110 86 48                              ldaa    #72           ; send "H" to serial
0021 0112 f6 10 2e           read_again      ldab $102e           ;
0022 0115 c5 80              bitb    #$80
0023 0117 27 f9              beq read_again
0024 0119 b7 10 2f            staa SCDR           ;
0025                         
0026 011c 86 65                              ldaa    #101           ; send "e" to serial
0027 011e f6 10 2e           read_again     ldab $102e           ;
0028 0121 c5 80              bitb    #$80
0029 0123 27 f9              beq read_again
0030 0125 b7 10 2f            staa SCDR           ;
0031                         
0032 0128 86 6c                              ldaa    #108          ; send "l" to serial
0033 012a f6 10 2e           read_again      ldab $102e           ;
0034 012d c5 80              bitb    #$80
0035 012f 27 f9              beq read_again
0036 0131 b7 10 2f            staa SCDR           ;
0037                         
0038 0134 86 6c                              ldaa    #108           ; send "l" to serial
0039 0136 f6 10 2e           read_again     ldab $102e           ;
0040 0139 c5 80              bitb    #$80
0041 013b 27 f9              beq read_again
0042 013d b7 10 2f            staa SCDR           ;
0043                         
0044 0140 86 6f                              ldaa    #111          ; send "o" to serial
0045 0142 f6 10 2e           read_again      ldab $102e           ;
0046 0145 c5 80              bitb    #$80
0047 0147 27 f9              beq read_again
0048 0149 b7 10 2f            staa SCDR           ;
0049                         
0050 014c 86 20                              ldaa    #32          ; send "space" to serial
0051 014e f6 10 2e           read_again    ldab $102e           ;
0052 0151 c5 80              bitb    #$80
0053 0153 27 f9              beq read_again
0054 0155 b7 10 2f            staa SCDR           ;
0055                         
0056 0158 20 b6              BRA     LOOP

It's that awful when you just learnt a new fact when you are about to leave something behind. It could have helped me all those months learning the HC11 and trying to recover and learn how the firmware worked.

If you know where you got your AS11 or can upload it to a file directory somewhere, please do because my As11.exe didn't show error when multilple identical labels were used. But if wrong instructions used, it can show error like yours.
« Last Edit: February 07, 2023, 12:55:27 pm by planc »
 

Offline ozcar

  • Frequent Contributor
  • **
  • Posts: 320
  • Country: au
Re: PIC18F1320 in a Raman Spectrometer
« Reply #66 on: February 07, 2023, 08:43:10 pm »
From that assembly listing, you can see what it has done with the duplicate symbols. Look at the generated code for each instruction as shown on the left, you can see that all the "beq read_again"  instructions assemble as "27 f9" (shown in hexadecimal, of course).The 27 is the opcode for beq, and the f9 (minus 7 in decimal) is the offset, relative to the next instruction, to branch to. So, it has created code that does what you want, but to me just doing that silently is a big trap for the unwary - think what could happen if you accidentally used the same symbol twice.

I don't remember where I got AS11 from. I have it in a directory together with the Axiom IDE  (I had one of their boards), so perhaps it was bundled with that.

You could use asm11.exe from http://www.aspisys.com/asm11.htm ("Click title for binaries" link) instead. That even runs natively on current Windows versions, something that AS11 (at least the one I have) does not. The listing produced by that gives some additional information too, like the cycle counts for each instruction.

For today's assembly language lesson, take a look at the generated code for these four instructions:

Code: [Select]
0020 0110 86 48                              ldaa    #72            ; send "H" to serial
0021 0112 86 48                              ldaa    #$48           ; send "H" to serial
0022 0114 86 48                              ldaa    #%01001000     ; send "H" to serial
0023 0116 86 48                              ldaa    #'H'           ; send "H" to serial

For what you were doing, which of those do you think makes the most sense?
 

Offline plancTopic starter

  • Regular Contributor
  • *
  • !
  • Posts: 149
  • Country: us
Re: PIC18F1320 in a Raman Spectrometer
« Reply #67 on: February 07, 2023, 11:59:41 pm »
From that assembly listing, you can see what it has done with the duplicate symbols. Look at the generated code for each instruction as shown on the left, you can see that all the "beq read_again"  instructions assemble as "27 f9" (shown in hexadecimal, of course).The 27 is the opcode for beq, and the f9 (minus 7 in decimal) is the offset, relative to the next instruction, to branch to. So, it has created code that does what you want, but to me just doing that silently is a big trap for the unwary - think what could happen if you accidentally used the same symbol twice.

I don't remember where I got AS11 from. I have it in a directory together with the Axiom IDE  (I had one of their boards), so perhaps it was bundled with that.

You could use asm11.exe from http://www.aspisys.com/asm11.htm ("Click title for binaries" link) instead. That even runs natively on current Windows versions, something that AS11 (at least the one I have) does not. The listing produced by that gives some additional information too, like the cycle counts for each instruction.

For today's assembly language lesson, take a look at the generated code for these four instructions:

Code: [Select]
0020 0110 86 48                              ldaa    #72            ; send "H" to serial
0021 0112 86 48                              ldaa    #$48           ; send "H" to serial
0022 0114 86 48                              ldaa    #%01001000     ; send "H" to serial
0023 0116 86 48                              ldaa    #'H'           ; send "H" to serial

For what you were doing, which of those do you think makes the most sense?

I'm familiar with the first 3 lines, but I never tried "#'H'. The reason I was so familiar with the first 3 lines was because I had to learn to and distinguish them to even understand what the EEG firmware is doing, and after knowing them, figuring out the missing codes the manufacturer deleted on purpose.

They reason they bricked the old 1999 EEG unit was because it was once free to use. Now you must pay for limited time use and very expensive. When I bought it in 1999 I didn't even use it. I  planned to explore it last year October and I ran the manufacturer latest software which bricked them. Fortunately. My old software in a 1.44M diskette still worked after 22 years. I How long is the 1.44M diskette you have tried to read and no bad sectors?  Then I open the unit and found out it has an HC11 inside and I read everything about HC11 until I know how to write simple codes, and analyze loops. The THRsim11 has helped me a lot. Also in the 7 pages firmware. Only 3 are required, the rest creates many loops that are meant to confuse those who are seeing the firmware. It took me 2 weeks to analyze them after writing each register on paper and tracing the loop. And usng THRsim11 simulator. Had I know how to trace in Buffalo that time, It could have helped me a lot.

If you used identical label names inside loop. It can jump incorrectly, and it took 2 days to discover it last November. In the latest asm11 copy you shared above. The following is the error now. (the reason I still use multiple labels is just to quickly display Hello at serial, that's why I didn't use any subroutine for the serial which I know how to do. I don't use the Hc11 for other purposes except just exploring the EEG thing and I forgot about not using multiple labels because my AS11 copy not showing error.. Ataradov kept asking me why I still use the HC11. It's primarily to fix the bricked EEG which I did successfully):

Code: [Select]
C:\Users\AlbeP\Downloads\asmw32\hw.txt(27): Error: Possibly duplicate symbol "read_again"
C:\Users\AlbeP\Downloads\asmw32\hw.txt(33): Error: Possibly duplicate symbol "read_again"
C:\Users\AlbeP\Downloads\asmw32\hw.txt(39): Error: Possibly duplicate symbol "read_again"
C:\Users\AlbeP\Downloads\asmw32\hw.txt(45): Error: Possibly duplicate symbol "read_again"
C:\Users\AlbeP\Downloads\asmw32\hw.txt(51): Error: Possibly duplicate symbol "read_again"
Assembled hw.txt (56 lines)          [Errs: 5]
1 file processed! (Elapsed time: 0:00:00)

The following is when  the loop has unique names

Code: [Select]
Assembled hw.txt (56 lines)                                                            90 bytes, RAM:     0, CRC: $EEF8
1 file processed! (Elapsed time: 0:00:00)

What web sites can one upload files that you can download? The as11 is open source. I want to upload you my as11 copy which doesn't show any error even if all identical labels used. It can run only in 32bit Windows DOS.  Your as11 link is great because I can now run it in my 64 bit windows without having to use Oracle Virtual box just to run it in windows 32 bit and dos.

My Microsoft Surface Pro 7 can only run Windows 64 bit and not 32 bit. But with your programming skill guys, can you share how to run windows 32 bit in the Microsoft Surface notebooks?

 

Offline plancTopic starter

  • Regular Contributor
  • *
  • !
  • Posts: 149
  • Country: us
Re: PIC18F1320 in a Raman Spectrometer
« Reply #68 on: February 09, 2023, 10:00:23 am »
Well, UART is a peripheral, so it would be different between different MCUs. So, you can't take C code for one MCU and compile it for another MCU without changing device-specific parts.

You've already been pointed at a few MCUs that have higher resolution SDADC. Those may or may not be good enough for your application.

Even if you fond some readily available eval board with 24-bit ADC and a MCU (there are not too many of those, I imagine), all the example code would be in C. And it is not likely that example code would do precisely what you want, so you would have to modify it anyway.

Internal ADCs in the MCUs are not meant for metrological applications.

But also, 24-bits is not about accuracy or resolution, but about dynamic range. If you don't need wide dynamic range, you can use low noise amplifier and use internal ADC just as well.

In your work, how often do you integrate pc software to the embedded MCU? If you can use password in the pc software that would be tied up with the serial number in your circuit or module. Then why be concerned the circuit and firmware are copied when they don't have your pc software source code?  Is there a Ghidra reverse engineering that can hack all software too?

Btw..I will no longer reverse engineer the Raman spectrometer or EEG and will move from the 68HC11. I don't want to offend those manufacturers too. I heard they can get you if there is an extradition treaty between the United States and that country? And I will not hack any software too Don't worry. Instead I'll focus on my interests in the brain and physics. I have over 50 books of the brain, and nearly 300 on physics, and interested in biophysics as I've been trying to understand why emotions are contagious and how people can affect one another non-locally and something nonphysical is also feeding on the emotions and provoking violence (like when soldiers killed civilians en masse). The following headlines about quantum entanglement detected in the brain will let me review it all (I wonder what kind of MCU and ADC is inside MRI, any clue?0. By the way. what is your area of expertise along the line of programming embedded circuits and MCUs?

https://www.freethink.com/science/consciousness-quantum-entanglement?utm_source=facebook&utm_medium=social&utm_campaign=BigThinkdotcom&fbclid=IwAR1q_d5W7NbWiIh_a9QBwDgF6Kq3gahEwIHKPjViG59cn8YUwbbdJzQrKzs

"Seeing entanglement in the brain may show that the brain is not classical, as previously thought, but rather a powerful quantum system. If the results can be confirmed, they could provide some indication that the brain uses quantum processes. This could begin to shed light on how our brain performs the powerful computations it does, and how it manages consciousness."

https://iopscience.iop.org/article/10.1088/2399-6528/ac94be

"Our findings suggest that we may have witnessed entanglement mediated by consciousness-related brain functions. Those brain functions must then operate non-classically, which would mean that consciousness is non-classical."


 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: PIC18F1320 in a Raman Spectrometer
« Reply #69 on: February 09, 2023, 06:09:57 pm »
In your work, how often do you integrate pc software to the embedded MCU?
Never.

If you can use password in the pc software that would be tied up with the serial number in your circuit or module.
If I clone your hardware, I would just clone the same serial number and then distribute a single known password that works with that SN.

Is there a Ghidra reverse engineering that can hack all software too?
Ghidra works with PC software too. And there are a ton of other tools. You can forget about locking down the PC software. It is impossible to do.

Don't worry.
I'm not worried, based on this thread, there is no chance of you successfully reverse-engineering anything. You are pretty safe here.

By the way. what is your area of expertise along the line of programming embedded circuits and MCUs?
Why?

"Seeing entanglement in the brain
I'm done here. I don't do quack pseudo-science.
Alex
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf