Skip to main content
Topic: Scripting engine (new term) (Read 13813 times) previous topic - next topic

Re: Scripting engine (new term)

Reply #15
thanks. It was on the list for 5.1 but i kept it postphoning.

Re: Scripting engine (new term)

Reply #16
Please note there are probably 2 more issues not handled yet:
1. I haven't figured yet how you handle error cases in your parser, as it seems there is no way to return an error code from assign() and getnumvar().
2. In my patch, getnumvar() is calling assign() when maybe I should have called evaluate() so that the following can be done:


I haven't written BASIC in 25 years, so I don't remember if this is legal or not (it certainly legal in C and other languages I'm used to).

One more issue I saw is that you have to type NEW on the first time you go into the script mode, otherwise it locks up on the first command entered.
Why is NEW not done automatically?

Re: Scripting engine (new term)

Reply #17
[quote author="udif"]
A few other things I noted: ... areCompile
The Wiki page says you need to export the result into an Intel Hex file, but in reality running Make or Build All with the default bus pirate project file from the trunk does this for you.
In fact, when I tried to follow the instructions above and generated a hex file I got a file starting at 0 that was rejected because it tried to overwrite the boot sector.

One more thing: the current project includes no optimizations, and uses 94% of the code space. Turning size optimization (-Os) reduced this to ~67% !!!.
I haven't tried running the result though.

The major reason I got into the Bus Pirate in the first place is JTAG.
I wanted a cheap and open source platform for JTAG experimenting. It now seems that JTAG is disabled on v5. Why was that done, and how do I enable it again on my builds?
busPirateCode.c now have a structure with member functions for each mode, and I see no wuch table for JTAG.

I want to incorporate the following code, which on a 2nd thought probably needs a new separate mode, and not any existing JTAG: ... detection/


This is from a PM, I wanted to answer it here so Sjaak can comment too.

The wiki is really outdated, it refers to the v2 bootloader branch, not the new v4 bootloader. Writing at 0 should be fine, it's the last page and configuration words that aren't allowed by the ds30loader app and bootloader self-protection. You can also do a file->export and change the end range to 0xa7fe and it should work (I still do this for some reason, even though it's not needed).

I believe Sjaak has tried an -O level or two. I haven't even tried because I'm such a sloppy coder that I assume there's no way the compiler is going to optimize things right, Sjaak's code is much cleaner with much more attention paid to variable types, etc, but a huge amount is still written by me :)

The v5 branch is a complete revamp of v4. The JTAG library was not ported to v5 because we didn't know anyone used it, there is new OpenOCD JTAG support, and we are quickly running out of space. It would have to be ported from teh v4 style to v5 style, which means breaking it up into discrete functions and assigning them to a commands in the core.c file.  JTAG should also be ported to the central bitbang library to save space, it currently uses it's own software pin routines. We had a brief conversion about it here:

Basically, the JTAG library uses a really ugly state machine to track your way through the JTAG states and do stuff like clock out the last databit of a byte while doing the TMS transition, which is difficult to do in raw3wire or SPI libraries.
I'm not exactly sure how to integrate the statemachine tracker in the JTAG library into the newterm.

The JTAG detector looks interesting. It would be nice to add it to a revamped JTAG library.
Got a question? Please ask in the forum for the fastest answers.

Re: Scripting engine (new term)

Reply #18
Sorry, that JTAG conversation link is here: ... 35#msg5635
Got a question? Please ask in the forum for the fastest answers.

Re: Scripting engine (new term)

Reply #19
I tried optimize (-o1) but the binary won't work as expected. I'm afraid it will cost a lot of time to get it ok to optimize.

GCC optimize for microncontrollers with seperate code and data memory requires strict use of variables, and I believe gcc can't cope easy with with seperate code and data memory (assumption). You need to keep track of a variable is dirty or reused and use the keyword volatile to avoid being cached. I had in the past (about 5 years ago) lots of problems with turning optimalization on after writing programs for an embedded system. This experience is a bit old so it could be not true (anymore).

We are trying to get a new hw revision with more memory out, so optimizing isn't a very big issue. There are several ways to make it work on the old platform.

Using the .hex directly (from the ouput instead of exporting) will not work on the pirateloader on linux (it can't cope with lowercase (yet?))

Error handling is done by the stop var, which is not global ( more or less assume the evaluate does work always (evaluate() consumes what it understands and leave the pc there, the

evaluate() consumes what it understands and leave the pc there. If there is an error it will be a syntax error.

let a=(b>c) isn;t valid I guess (At least i made it invalid ;) )

NEW isn't automatically done so the program stays in memory after quitting the scripting language, and initialising the array globally would eat another 1k of code space. I struggled a bit how to get it right but it is a bit unpolished ;) Perhaps a proper check in the lineadder function would do the trick.

Re: Scripting engine (new term)

Reply #20
I commited my changes (r386), plus a new fix that allows relational operators ("<", ">", etc.) to be a part of an expression.
I cross checked this with some BASIC manuals that seems to confirm this is the required behavior.

However, one change I didn't implement yet, was that at least in commodore BASIC, the return value of the relational operators was 0 for false and -1 for true, while BP uses '1' for true.

Re: Scripting engine (new term)

Reply #21
Thanks udif, here's a updated nightly with your fix and a few others: ... e-v5.1.hex

I didn't mean to kill the JTAG discussion :) If you want it, but all means I want to put it back in. Have you used it in the past? Do you have an opinion about how it worked, how it could be improved? What abilities do you want the most?
Got a question? Please ask in the forum for the fastest answers.

Re: Scripting engine (new term)

Reply #22
Commodore BASIC! Still alive. It says Microsoft Corporation during initialization.

Re: Scripting engine (new term)

Reply #23
I haven't used JTAG before, but I consider it most valuable. That is, if it's able to program and debug ARM uC's (or even a FPGA).

Re: Scripting engine (new term)

Reply #24
That is, if it's able to program and debug ARM uC's (or even a FPGA).

The terminal JTAG mode is mostly for very low level JTAG debugging - reading the scan chain, pushing a couple bytes in and out of the JTAG interface. The OpenOCD JTAG support is a full-featured JTAG programmer/debugger.

Maybe we can add the low-level JTAG stuff to raw3wire - JTAG scan chain, the JTAG pin detection that udif mentioned?

I have another feature request :) 1-16bit binary entry, or configurable bit-length in the rawwire libraries. For example entering 0p111 would only send a partial byte (3 high bits), and maybe a macro to set the word length to non-8bit words. I'll probably work it a little this week. My newbin port hit a snag because the only way I could figure out how to do it is make a 32 function prototype for all the possible commands and then use it like the newterm, it's unwieldy, this would be a nice break.
Got a question? Please ask in the forum for the fastest answers.

Re: Scripting engine (new term)

Reply #25
Script mode does not work for me :S why ?

Syntax error at char 1

Bus Pirate v3.5
Firmware v6.1 r1676  Bootloader v4.4
DEVID:0x0447 REVID:0x3046 (24FJ64GA002 B8)

Re: Re: Scripting engine (new term)

Reply #26
Hi stdjmax,
script mode was removed in v6.1 due to space issues and would have to be back in v6.2.
Actually it is back in the last firmware release in the SVN, v6.3 r2012.
The latest version is the one that you find here:
Please pay attention to the fact although the script mode is come back working, there may be other weird things due to bugs.