Skip to main content
Topic: Bus Pirate BASIC script engine problems (Read 7516 times) previous topic - next topic

Bus Pirate BASIC script engine problems

Hello,

I just got my Bus Pirate a couple days ago from SparkFun.  I have since read that there was some minor controversy over SparkFun creating their own hardware version.  I just wanted to add that I would have probably never heard of the Bus Pirate or found DangerousPrototypes if it wasn't for SparkFun selling their version.  Now that I'm here I'll probably end up getting a Logic Sniffer too.

The first thing I tried to do with my Bus Pirate was get a surplus LED display working.  I had picked up the alphanumeric display some time ago but never got around to playing with it.  This seemed like a reasonable first challenge.  The Bus Pirate and I would have to do some "real" work instead of just reenacting a canned EEPROM demo.  But it I thought it would be a simple enough exercise to be accomplished in an evening.  The display uses a serial to parallel shift register and then the digits are multiplexed.  It must be sent a "packet" of five bytes continuously to keep all the segments refreshed. 

Using the SPI mode I could easily send the five bytes needed to get one digit at a time to light correctly.  I was able to verify the display hardware and my understanding of the digit and segment to bit mapping.  Next I wanted to try to see if I could get multiple digits working.  I read through the whole Bus Pirate documentation Wiki and it appeared that the BASIC script engine would let me do what I needed.  I was planning to create a loop that would send the seven five-byte packets repeatedly with time delays between each packet. 

I first discovered that the SEND command will only accept a one byte argument and it must be  in decimal format.  This is not very convenient but it is workable.  I was not yet sure how I was going to do the looping or the delays so I just typed out all the send commands on lines 100-104,200-204,...,700-704.  I am not at my development computer now but I think the LIST command said it was 202 bytes. 

On to my problem.  I typed RUN just to see if a "0" would rapidly flash across all the digits in succession.  And it did, more or less.  The display flickered with what looked like a zero on each digit but it did not stop with the 7th digit light.  The 5th digit was the one still light.  When I LIST'ed the program I found that the lines were not in order!  Each subgroup was in the correct order, i.e. X00,X01,...,X04, but the groups themselves were not in order.  It went some thing like 100-104,300-304,...,700-704,...,500-504.  This somewhat explained why the fifth digit was the one that remained light. 

Now the bigger question is why are the lines out of order.  When I typed the lines in I typed them all in order, 100-104,200-204,...,700-704, all at one time so I know they are not being listed in the order I typed them.  Does anyone have any idea what is going on? 

I searched the forums and could not find any threads about the BASIC script engine at all, let alone any problems.  It appears maybe not that many people use this feature but I think could be very useful -- if it works.  From what I have read it seems a lot of people are using some scripting language on a computer for more complex tasks instead on the internal BASIC interpreter.  In my case, I do not regularly use any scripting language.  It would take me longer to install, configure, troubleshoot, learn, etc. a new scripting language to do some simple development work than to just switch over to MPLAB and write a test program in C natively for the PIC/dsPIC I normally use.  The built-in BASIC script engine however would be a very quick way to test things a little to complex or burdensome to do by hand with the normal Bus Pirate interface.  I vote to keep it.

The Bus Pirate is still plugged in with the BASIC program in memory.  When I get back to that computer I can provide actual listings or any other data that may be useful.  Thanks for making this project available and for any help you can provide.

-Eric

Re: Bus Pirate BASIC script engine problems

Reply #1
Well the basic engine has some quirks. It was for me the first time I wrote an interpreter, so some parts can be optimized or coded better ;) I believe a forummember is currently rewriting/optimizing parts of it.

One of those quirks to enter new before entering anything else entering line will fail. Another is the syntax is not checked when entering but during runtime (flashmemory didn't permit it) and only one statement is allowed per line. Due to spaceconstraints the editor is fairly dumb.

Also it only accepts decimal values, 16 bit signed IIRC. THe bottleneck here is that the spi mode (and most others) are just using 8 bits.

There is however some documentation about it in the wiki: http://dangerousprototypes.com/docs/Bus ... _reference

And some sample scripts are in the development section of this board: http://dangerousprototypes.com/forum/in ... opic=413.0

this topic is written during the development, so some of it may not be accurate.

please post the listing as currently in your buspirate, and if you got it a log of you entering it into the buspirate, and also a debug which should print out the programmemory as is. Also post the firmware version you are using. I'll look into it.

Re: Bus Pirate BASIC script engine problems

Reply #2
Sjaak,

Thanks for the reply.

Quote
One of those quirks to enter new before entering anything else entering line will fail.

I did enter the NEW command before I began.

Quote
Also it only accepts decimal values...

The decimal only issue is an inconvenience but not too hard to work around.  Having hex entry as well would be welcome if possible.

Quote
There is however some documentation about it in the wiki:

I had found and read through all of the Bus Pirate BASIC script reference page on the Wiki before I started.

Quote
...some sample scripts are in the development section of this board... written during the development...

I had not found the thread you linked, thank you.  I am not sure why search does not return that thread.  When I type "basic" in to the search box I only get one page of 16 results.  Interestingly, your reply to my post is listed but my original post is not.

Quote
please post the listing as currently in your buspirate, and if you got it a log of you entering it into the buspirate, and also a debug which should print out the programmemory as is. Also post the firmware version you are using. I'll look into it.

When I get to that computer I will post as much information as I can.

Thanks again.


-Eric

Re: Bus Pirate BASIC script engine problems

Reply #3
Below is the log from the terminal as I was entering the program.  I have cut out a few portions where I exited out of the BASIC interpreter to test a few things and then came back.  If needed I can paste the full log but here I tried to keep it to the relevant parts.

[tt:]Ready
SPI(BASIC)> 100 send 254
Ready
SPI(BASIC)> 101 send 0
Ready
SPI(BASIC)> 102 send 0
Ready
SPI(BASIC)> 103 send 2
Ready
SPI(BASIC)> 104 send 0
Ready
SPI(BASIC)> list

100  SEND 254
101  SEND 0
102  SEND 0
103  SEND 2
104  SEND 0
1000 END
65535  END
36 bytes.
Ready
SPI(BASIC)> run
Error(3) @line:1000 @pgmspace:33

Ready
SPI(BASIC)> 1000
Ready
SPI(BASIC)> list

100  SEND 254
101  SEND 0
102  SEND 0
103  SEND 2
104  SEND 0
65535  END
30 bytes.
Ready
SPI(BASIC)> run

Ready
SPI(BASIC)> run

Ready

SPI(BASIC)> list

100  SEND 254
101  SEND 0
102  SEND 0
103  SEND 2
104  SEND 0
65535  END
30 bytes.
Ready
SPI(BASIC)> 200 send 254
Ready
SPI(BASIC)> 201 send 0
Ready
SPI(BASIC)> 202 send 0
Ready
SPI(BASIC)> 203 send 1
Ready
SPI(BASIC)> 204 send 0
Ready
SPI(BASIC)> list

100  SEND 254
101  SEND 0
102  SEND 0
103  SEND 2
104  SEND 0
200  SEND 254
201  SEND 0
202  SEND 0
203  SEND 1
204  SEND 0
65535  END
57 bytes.
Ready
SPI(BASIC)> 300 send 254
Ready
SPI(BASIC)> 301 send 0
Ready
SPI(BASIC)> 302 send 0
Ready
SPI(BASIC)> 303 send 0
Ready
SPI(BASIC)> 304 send 128
Ready
SPI(BASIC)> 400 send 254
Ready
SPI(BASIC)> 401 send 0
Ready
SPI(BASIC)> 402 send 0
Ready
SPI(BASIC)> 403 send 0
Ready
SPI(BASIC)> 404 send 64
Ready
SPI(BASIC)> 500 send 254
Ready
SPI(BASIC)> 501 send 0
Ready
SPI(BASIC)> 502 send 0
Ready
SPI(BASIC)> 503 send 0
Ready
SPI(BASIC)> 504 send 32
Ready
SPI(BASIC)> 600 send 128
Ready
SPI(BASIC)> 601 send 1
Ready
SPI(BASIC)> 602 send 248
Ready
SPI(BASIC)> 603 send 0
Ready
SPI(BASIC)> 604 send 32
Ready
SPI(BASIC)> 700 send 128
Ready
SPI(BASIC)> 701 send 1
Ready
SPI(BASIC)> 702 send 248
Ready
SPI(BASIC)> 703 send 0
Ready
SPI(BASIC)> 704 send 32
Ready
SPI(BASIC)> list

300  SEND 254
301  SEND 0
302  SEND 0
303  SEND 0
304  SEND 128
600  SEND 128
601  SEND 1
602  SEND 248
603  SEND 0
604  SEND 32
100  SEND 254
101  SEND 0
102  SEND 0
103  SEND 2
104  SEND 0
400  SEND 254
401  SEND 0
402  SEND 0
403  SEND 0
404  SEND 64
700  SEND 128
701  SEND 1
702  SEND 248
703  SEND 0
704  SEND 32
200  SEND 254
201  SEND 0
202  SEND 0
203  SEND 1
204  SEND 0
500  SEND 254
501  SEND 0
502  SEND 0
503  SEND 0
504  SEND 32
65535  END
202 bytes.
Ready
SPI(BASIC)> run

Ready
SPI(BASIC)> run

Ready
SPI(BASIC)> exit[/tt:]

Here is the debug output.

[tt:]SPI(BASIC)> debug
0xE4 0x01 0x2C 0x93 0x32 0x35 0x34 0xE2 0x01 0x2D 0x93 0x30 0xE2 0x01 0x2E 0x93
0x30 0xE2 0x01 0x2F 0x93 0x30 0xE4 0x01 0x30 0x93 0x31 0x32 0x38 0xE4 0x02 0x58
0x93 0x31 0x32 0x38 0xE2 0x02 0x59 0x93 0x31 0xE4 0x02 0x5A 0x93 0x32 0x34 0x38
0xE2 0x02 0x5B 0x93 0x30 0xE3 0x02 0x5C 0x93 0x33 0x32 0xE4 0x00 0x64 0x93 0x32
0x35 0x34 0xE2 0x00 0x65 0x93 0x30 0xE2 0x00 0x66 0x93 0x30 0xE2 0x00 0x67 0x93
0x32 0xE2 0x00 0x68 0x93 0x30 0xE4 0x01 0x90 0x93 0x32 0x35 0x34 0xE2 0x01 0x91
0x93 0x30 0xE2 0x01 0x92 0x93 0x30 0xE2 0x01 0x93 0x93 0x30 0xE3 0x01 0x94 0x93
0x36 0x34 0xE4 0x02 0xBC 0x93 0x31 0x32 0x38 0xE2 0x02 0xBD 0x93 0x31 0xE4 0x02
0xBE 0x93 0x32 0x34 0x38 0xE2 0x02 0xBF 0x93 0x30 0xE3 0x02 0xC0 0x93 0x33 0x32
0xE4 0x00 0xC8 0x93 0x32 0x35 0x34 0xE2 0x00 0xC9 0x93 0x30 0xE2 0x00 0xCA 0x93
0x30 0xE2 0x00 0xCB 0x93 0x31 0xE2 0x00 0xCC 0x93 0x30 0xE4 0x01 0xF4 0x93 0x32
0x35 0x34 0xE2 0x01 0xF5 0x93 0x30 0xE2 0x01 0xF6 0x93 0x30 0xE2 0x01 0xF7 0x93
0x30 0xE3 0x01 0xF8 0x93 0x33 0x32 0xE1 0xFF 0xFF 0xA1 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Ready
SPI(BASIC)>[/tt:]

Here is the version information.

[tt:]SPI> i
Bus Pirate v3a
Firmware v5.7 (r478)  Bootloader v4.1
DEVID:0x0447 REVID:0x3043 (B5)
http://dangerousprototypes.com
CFG1:0xF9DF CFG2:0x3F7F
*----------*
Pinstates:
1.(BR)  2.(RD)  3.(OR)  4.(YW)  5.(GN)  6.(BL)  7.(PU)  8.(GR)  9.(WT)  0.(Blk)
GND     3.3V    5.0V    ADC     VPU     AUX     CLK     MOSI    CS      MISO
P       P       P       I       I       I       O       O       O       I
GND     3.30V   5.05V   0.00V   5.03V   L       L       L       H       H
Power supplies ON, Pull-up resistors ON, Open drain outputs (H=Hi-Z, L=GND)
MSB set: MOST sig bit first, Number of bits read/write: 8
a/A/@ controls AUX pin
SPI (spd ckp ske smp csl hiz)=( 2 0 1 0 1 1 )
*----------*
SPI>[/tt:]

Let me know if there is anything else useful I can provide.  I will try to hold off doing anything with the Bus Pirate for a while in case there is something you want me to test.  Thanks again.

-Eric

Re: Bus Pirate BASIC script engine problems

Reply #4
I just wanted to add that the Bus Pirate is still up and running and I do have an ICD3.  So, if a memory dump of the PIC is useful let me know.

-Eric

Re: Bus Pirate BASIC script engine problems

Reply #5
No need I do have the logs and the debug from the programmemory.

feel free to do somehting different with you PC or buspirate. ;)

Re: Bus Pirate BASIC script engine problems

Reply #6
Thanks.  Let me know if you figure anything out.  I'm going to clear it and start over.  After refreshing my memory on BASIC I realized the READ/DATA commands will make what I am trying to do a bit easier and shorter. 

-Eric

Re: Bus Pirate BASIC script engine problems

Reply #7
Don't forget the for/next combo's ;) Please share the scripts if you want.

It is prolly an error in the editor (which is one big hack :D)

Re: Bus Pirate BASIC script engine problems

Reply #8
Yes, I should have said the READ/DATA commands in combination with a FOR/NEXT loop which is what I was thinking.  I know FOR/NEXT loops as they are used in nearly every language but I had forgotten about the READ/DATA commands since they are peculiar to BASIC (and possibly some other languages).  I will post whatever I get working strictly for entertainment purposes since it will probably not be useful for anything else.

-Eric

Re: Bus Pirate BASIC script engine problems

Reply #9
I cleared the Bus Pirate and started over with a little better idea of where I was going.

This is what I ended up with.
Code: [Select]
100  FOR I=1 TO 10000
105  FOR J=1 TO 5
110  READ A
120  SEND A
125  NEXT J
130  DELAY 5
140  NEXT I
150  SEND 8
160  SEND 0
170  SEND 0
180  SEND 0
190  SEND 0
1000  DATA 246,68,63,194,0
2000  DATA 249,17,25,16,64
2001  DATA 206,69,121,0,32
1010  DATA 249,80,195,201,0
1020  DATA 206,1,181,152,128
65535  END
173 bytes.
Notice however that there are still some line numbers in the incorrect order.  I am not sure what order they are actually executing in because for this purpose it does not matter.

The results are shown below.  It is not all that impressive but it verified the display was working and that I knew how to interface with it.  The inner FOR/NEXT loop sends one the five bytes packets to refresh one part of the multiplexed display.  The outer FOR/NEXT loop sends the packets repeatedly in a loop for a few seconds with a 5ms delay between each refresh.  Finally, the last five SEND statements clear the display.

-Eric

Re: Bus Pirate BASIC script engine problems

Reply #10
The program is executed in the way it is stored in memory (and listed!)

BTW nice display, is it from an answering machine?

Re: Bus Pirate BASIC script engine problems

Reply #11
Thanks for the picture, I'll post this on the blog.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate BASIC script engine problems

Reply #12
Ian,

I'm not sure that it is exactly blog worthy but if you'd like, go ahead. 

I do not know what the display was originally intended for but it was likely some type of office equipment.  I picked up a few of the them for a dollar each from All Electronics (my favorite surplus dealer) a few years ago but never got around to playing with them.  Since the displays have not been available for quite a while I'm not sure how much general interest there will be in this information but, below are several web pages about the displays.

http://www.robotroom.com/MultiSegmentLEDDisplay.html
http://www.serialwombat.com/sdk/pin_mode_phoneled.htm
http://www.82smugglers.com/blog/?p=3
http://www.siti.com.tw/product/spec/LED/ST2225A.pdf

If you would like a better picture of the display I can pull out the DSLR and take a better photo.  That was just a quick cell phone pic because it was quick and easy.

[hr:][/hr:]

Sjaak,

I thought there was a good probability that the lines would execute in the order they listed.  I just started looking at basic.c and haven't quite figured it all out yet.  In particular, the TOK_LEN define is a bit confusing in how it is being used.  But I've never looked at or tried to write anything like an interpreter before.

Take a look at the clip from the terminal log below.

[tt:]SPI(BASIC)> list

100  FOR I=1 TO 10000
105  FOR J=1 TO 5
110  READ A
120  SEND A
125  NEXT J
130  DELAY 5
140  NEXT I
150  SEND 8
160  SEND 0
170  SEND 0
180  SEND 0
190  SEND 0
1030  DATA 254,1,248,0,64
1040  DATA 254,1,248,0,32
1000  DATA 254,0,0,2,0
1010  DATA 254,0,0,1,0
1020  DATA 254,0,0,0,128
65535  END
158 bytes.
Ready
SPI(BASIC)> 1000 data 246,0,63,194,0
Ready
SPI(BASIC)> 1010 data 249,80,195,201,0
Ready
SPI(BASIC)> 1020 data 206,1,181,152,128
Ready
SPI(BASIC)> 1030 data 249,17,25,16,64
Ready
SPI(BASIC)> 1040 data 206,69,121,0,32
Ready
SPI(BASIC)> list

1030  DATA 249,17,25,16,64
1040  DATA 206,69,121,0,32
100  FOR I=1 TO 10000
105  FOR J=1 TO 5
110  READ A
120  SEND A
125  NEXT J
130  DELAY 5
140  NEXT I
150  SEND 8
160  SEND 0
170  SEND 0
180  SEND 0
190  SEND 0
1000  DATA 246,0,63,194,0
1010  DATA 249,80,195,201,0
1020  DATA 206,1,181,152,128
65535  END
172 bytes.
Ready
SPI(BASIC)>[/tt:]

The first list has lines 1030 and 1040 out of order but they are in the right block so they will work for this purpose.  I then changed the data to display the "ABCDEFG 1234" seen in the photo instead of all zeros as the original data produced.  Now notice where lines 1030 and 1040 have moved.  I had to keep playing with the line numbers of those two DATA commands to get them back down into the block of data at the end of the list.  I was not sure if the program would work with two DATA commands before the READ so I just tried different line numbers till I got them in a workable spot.


-Eric

Re: Bus Pirate BASIC script engine problems

Reply #13
I found the error. It was in the linefinding algo. I updated the svn to r491 and update the nightly builds.

The TOK_LEN is always the first token on the line, and is used as check for a valid line (at least a valid start of a line :D). It also tells how long the line is and is used to speed up goto/gosub linenumber lookup (don't have to seek for a newline, but jump immediately to the next (poormans linked list :D))

I'm not an interpreter expert either ;) but it was fun to write and it even works (and comes with free bugs off course)

Re: Bus Pirate BASIC script engine problems

Reply #14
Sjaak,

Glad you found the problem in the basic engine.

It seemed like TOK_LEN was an identifier for the beginning of a line with a length then added to it.  I guess part of my confusion was coming from the name of the define TOK_LEN = token length.  It seemed like the value of a define with such a name must be some kind of length constant.  But I could not figure out what had a length equal to TOK_LEN.  I didn't look through it long enough to figure out what was going on though.

I'd like to get back to playing with my Bus Pirate and a couple ideas I have to make a few changes.  Unfortunately right I'm now deep into the code of my thesis project -- which is what I should be working on anyway -- and need to keep going while it is all fresh in my head.  I'm an EE who started programming microcontrollers in assembly and only moved to C for a few years ago.  The basics of C are pretty easy but complex pointers still cause me grief from time to time.  I'm working with a dsPIC33 and am using FreeRTOS, which I really like.  Right now though I'm having a fit figuring out how to declare a pointer for a two dimensional array that needs to be in far memory and who's address is passed on a queue to another thread.  I know what I want to do but so far I haven't figured out the correct way to declare the variable, a pointer to it, a queue that passes its address, how to get it into the correct memory segment, etc.  I have figured out that a typedef does not seem to carry an __attribute((far)) with it.  Anyway, I'll get back to it in the morning. 

Where are you all located?  Most of you seem to post really early in the day for me here on the US west coast.


-Eric