Help with very simple strings problem

[joe rocci]

Why does this very simple code not work:

#chip mega328p, 16
#define USART_BAUD_RATE 9600
#define USART_BLOCKING
#define USART_DELAY 0 ms
initusart

dim aa as string
dim bb as string

aa = "abcd"
bb = "efgh"

if left(aa,2) = "ab" then
   hserprint "OK"
end if

The program never gets to the hserprint "OK". I have this problem with all the simple string functions (left, right, mid, etc).

I'm using the latest download of GCBSyn.

[Anobium]

Hi Joe,

What date is your GBASIC.EXE?

There seems to be an issue with an 'Unknown array type'. I am reviewing the source code. But, I need the date of your EXE.

Anobium

[joe rocci]

Version 0.9 dated 11/5/2014

[Anobium]

Its an issue in the compiler. Please wait until we resolve.

[joe rocci]

Thought I was going crazy as this was code developed a couple years ago and it worked last time I compiled it.

Can you venture an ETA?

[joe rocci]

Any feedback on resolving this?

Thanks

[Anobium]

We discussed this at the weekend, Hugh and I. We have an issue with parameter passing within the AVR code. This issue also causes errors with LCDCreateChar when using AVR code.

Hugh will get to this asap.

Meanwhile I have created a workaround for you. You need to use some global arrays and a function.

  #chip mega168, 16
  #define USART_BAUD_RATE 9600
  #define USART_BLOCKING
  #define USART_DELAY 1 ms

  #define err1

  #ifdef err1
      'Unknown array type, SysTempArray is REGISTER@-2
      dim aa as string * 16
      dim bb as string * 16

      dim global_testarray as string
      dim global_teststring as string

      aa = "abc"
      bb = "ab"

      global_testarray = aa    ; your teststring
      global_teststring = bb    ; match string

      if  strtest = true  then
         hserprint "OK"
      else
         HSerPrint "Not OK"
      end if
      end

      function strtest
               strtest = true
               for xloop = 1 to len(global_teststring)
                   if global_testarray(xloop) <> global_teststring(xloop) then strtest = false
               next

      end sub
  #endif

[joe rocci]

Thanks guys!

This issue also affects Case statements, so I'm not sure one work-around fixes all related problems. I look forward to a proper solution.

[Anobium]

@joe.

What was the exact code you used to get an error with CASE?

Can you attach an example please?

[Anobium]

We are working on the root cause. We want to fix before the planned release.

Can you post an attachment with an example of the Case error condition ?

Thank you.

[joe rocci]

I blew that code (Select Case)away when I implemented a work-around for the problem, so I can't send it. However, here's another case of something that used to work but now doesn't (same chip, mega328p)

for ii = 0 to 99
dim jj as Byte
dim kk as Word
kk = (ii * 255)/100
jj = kk
hsersend jj
next ii

I'd expect it to send increasing byte values from 0 to 252, but all it sends is 2.

It appears that something (at least related to mega328p chip) got broken since I worked on this code about a year ago.

Joe

[Anobium]

yes, your are right. There is something totally wrong. I have adapted to this test program. I get 1's and 2's where I should be getting 02h to FCh.

I converted to hex values to get Hserprint to show the values.

  #chip mega328p, 16
  '#chip 16f877a, 16
  ; ----- Define Hardware settings
    'Config hardware UART
    #define USART_BLOCKING
    #define USART_BAUD_RATE 9600
    #define USART_DELAY 10 ms

    dim jj as Byte
    dim kk as Word

    HSerPrintCRLF 2
    for ii = 0 to 99
        kk = (ii * 255)
        HSerPrint hex(kk_h)
        HSerPrint hex(kk)
        HSerSend 9

        kk = kk /100
        HSerPrint hex(kk_h)
        HSerPrint hex(kk)
        HSerSend 9

        kk = [word](ii * 255)/100
        HSerPrint hex(kk_h)
        HSerPrint hex(kk)

        HSerPrintCRLF
    next ii

[joe rocci]

In my code, I did the copy from a word value to a byte value before sending just to convince myself the problem isn't due to hsersend not evaluating the formula properly.

[Anobium]

Here is a method that works on test here.

for ii = 0 to 99
dim jj as Byte
dim kk as Word
kk = ([word]ii * 255)/100
jj = kk
HSerPrintByteCRLF jj
next ii

[Chuck Hellebuyck]

I'm confused by this.

kk is a word and ii is converted to a word prior to storing a value in kk.
But then you make jj, which is a byte, equal to kk which has a word size value.
Will jj just contain the lower byte?

That seems like an error waiting to happen.

[joe rocci]

There are any number of work-arounds possible, but if the compiler doesn't behave as expected to evaluate simple expressions without workarounds, then it becomes very difficult to use and one can waste a lot of time when things don't work as expected. Something clearly got broken along the way and it's affecting numerous methods. All of this used to work; I don't think a new official release should be considered until the root causes are found, fixed, and tested by the community through a series of test releases.

[Anobium]

I have been reviewing the changes and testing I believe the error occurred in a release between June and August last year. It is now on the fix list.

Your comments are very valid. We did release a Hot Version but issue was not picked up.

[Anobium]

@joe. I have been going through all the releases I have. Can you zip up and attached a version where this does work. Thank you.

[joe rocci]

Chuck
I overwrote any old version I had when I installed this version.

[joe rocci]

Hi Guys

Were the above issues resolved in the new release?
Joe

[joe rocci]

Hi Guys

Were the above issues resolved in the new release?
Joe

[Anobium]

That is plan. :-)

We are close, a few more days. It is a lot of work to pull together and we have two bugs to fix.

Anobium

[joe rocci]

Thanks all for your untiring (and unpaid) efforts on this project.

[joe rocci]

Thanks all for your untiring (and unpaid) efforts on this project.