Integrating Bitlash into an ATMega328

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bill,

If a 328 is used and the Bitlash code takes 14.4K, that leaves over 17K spare. My code will probably fit in 2-3K including the pixel data and stuff (freaky assembler code). This will still leave a whopping 14 to 15K left.

A few thoughts regarding the use of spare flash ROM for storing macros -

As the EEPROM is small by comparison, would it make sense to actually keep most of the macros in the flash ROM, and just use the EEPROM as a kind of scratch-pad area where the user enters and edits their program?

This would allow a much larger and more powerful system - I assume. Also, it would be nice to have a lot of routines, macros and so on just there so you could call on them.

In this case, could the macros be encoded in the EEPROM as byte or word tokens which simply called a macro in ROM without having to be parsed each time, so that you would get much more room in there? I don't think I understand your software well enough to really see into this, but I'm looking at it from a space point of view (must be my assembler leanings here).

From an interpreter point of view, I can't understand why tokens would be a bad thing. I have not written a compiler or an interpreter, and don't actually know what I'm talking about here, I'm just trying to understand your software and how it works.

As well as taking up less space than a character string, once a function has been translated into a token, the interpreter could just load the token into a jump table (or whatever you call it in C) and execute the code immediately.

I'm sure there's at least one reason why you are not using tokens, sorry to be nosey and actually want to know how it works and so on... not really relevant to getting it working but I'm just a curious sort.

To start with I will do some code to just read and write from the standard serial port, and leave the USB handling as a "to do".

I'm not too sure I need to worry too much about integrating Bitlash with my code as long as I understand what bits it interfaces through.

As long as I can compile the Bitlash code it will stay more or less constant and I will be erasing and re-programming my code and interface software until I get it right, so I will probably use a fixed location to call Bitlash and leave it where it is.

My aim is to get Bitlash up and running with just a basic serial port communication on an ATM328. From this I can start playing around and work out how to run my code fired off interrupts, while Bitlash runs as the main program loop.

It would probably be of great interest to many AVR Freaks to be able to get a ready compiled hex file which could be uploaded to a blank ATM328 via AVRDude, to let people play with Bitlash via the serial port. This would only need a couple of connections (Rx, Tx) to have a working system that could be experimented with.

I can't put any time into this right now as I have a development job which is late, but I will look at doing it as soon as I can unless someone else beats me to it!

Thanks all,

Zadok.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello again, Zadok:

I have nothing against tokenizing interpreters and compilers. I'm just not smart enough to write one that is small enough to fit at the low end. I would be happy to accept education on the matter in the form of patches ;)

The program flash is a good target of opportunity for static content that can be bound at build time. It is less straightforward for dynamic storage because of the page-buffer management requirements during writing. It could be done. You see a thread here from time to time about it.

But let me ask this question: do you really want to be writing applications bigger than a kilobyte or two in a language that doesn't have procedures with call-by-argument, where you edit by retyping code, and where everything happens in a terminal emulator?

My experience has been that right around the time Bitlash runs out of steam as a prototyping tool (either by running out of space, or running out of time/speed), the problem has coughed up enough information that you can go write the program you wanted to from the beginning.

Here's an offer and a challenge: the hex files you asked for are at:
http://bitlash.net/downloads/hex/ -- get it up and running on your testbed, get some time and familiarity with the language, and report back to let us know if the code space is the first thing you'd solve.

Happy to take more questions along the way.

Cheers,

-br

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bill,

Thanks for providing the hex files. Now I need to order some ATM328 chips, and get this current job off my back, then I can sit down and have a play.

Thanks again,

Zadok.

PS Regarding your point about tokens:

I guess the reason why I am a bit "obsessed" with tokens, is that I so often use the assembler code:

mov ZL,Command
icall

To execute code based on the contents of a byte, that I must want to do it for everything. It takes 3 instructions and 6 clock cycles to get there and I like this! (Another 2 cycles and one instruction because of the intermediate jump table).

[Note: This code works if the jump table is on a 512 byte boundary - 256 words, ZH contains the high address.]

So if there were tokens in the EEPROM (or Flash) it would mince through them like lightning. Well, I know, that's the *easy* part, the tough part is making the language work, but then you have already done that...

[Although I don't know how this is implemented in C for the AVR, I should think a similar sort of construction is used]

With 256 unique codes, there would probably be enough for all the basic functions, operators, use maybe a-z and / or A-Z letters as variables and so on.

Of course, I again have to say that I haven't written a language or a compiler so this is just hot air from me.

It was interesting to read about the old ZX80 home computer that someone in our earlier thread referred to, it only had 1K RAM, but because it used tokens, apparently you could even get a chess program (of sorts) into it!

So I guess that just goes to prove your point that you don't need space for 1,000 instructions in a system of this sort. From a marketing point of view though, people are nowadays used to such absurd amounts of memory that our world of microcontrollers leaves them aghast that anyone could do anything in such a tiny space. So I think most people who were looking at buying something like a single chip computer would be a lot happier to be able to read something like "a maximum of 1,000 program statements" rather than "1K byte of program memory" if you see what I mean.

So, just wanted to say why I'm secretly hankering for tokens, even though as you say, and as the chess program example illustrates, it doesn't really matter!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I hear you, man.

I bet you want a decompiler to go with that token compiler, too, right :)

Best,

-br

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bill, I've been thinking about compilers and stuff and now (I think) I understand...

There's no point having a token type interpreter with source code as well, at least in an AVR there's not enough RAM for both. As the whole point of tokens is to save RAM, it's pointless unless you interpret and store each line of code as p-code as it's typed in.

This leads to interesting problems with resolving forward address references and loops, and means editing is a whole new challenge. Plus listing the program needs a decompiler as you said above.

Yes, I've been thinking about it. I'm just one of those people who has to understand before he can use something, so now the penny has dropped, I can get on with it.

I've ordered a couple of ATM328's so they should turn up next week some time.

Thanks for bearing with me while my brain cells do their thing (albeit slowly).

Zadok.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Zadok,

If you want to implement a P-code system it's going to need to be a compiler (presumably a cross-compiler on a PC?) rather than an interpreter for the exact reasons you just identified.

This has been discussed from time to time - there's a "smartcard" version of Java bytecode which is cut-down for embedded systems which has been suggested from time to time - though it may be too smartcard-centric.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
If you want to implement a P-code system it's going to need to be a compiler (presumably a cross-compiler on a PC?) rather than an interpreter for the exact reasons you just identified.

On the old ZX80 there must have been a kind of compiler / interpreter as it stored programs as tokens (which I equate to p-code) in the precious 1K of memory. Must have been pretty hairy software in the ROM, or maybe it used some tricks to keep the job simple. No labels for a start I would imagine.

They're a rare item these days. I wonder if anyone has the Z80 source code for the software.

Z.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The Spectrum used a similar system - it's fully documented ROM disassembly is available in the book by Dr Ian Logan. There's something similar for the ZX80 here:

http://www.wearmouth.demon.co.uk...

It hinges around "TKN-TABLE"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello again, Zadok et al:

Excellent review of the technical points. Building a parse tree representation of the input, resolving references (and types!), flattening the tree to byte code to be eaten by the interpreter; providing decompile for re-edit; and the actual run-time interpreter itself: none of these is difficult per se, but each one adds code that consumes flash and needs working storage.

You could definitely build that ship in a bottle; you'd just need a little more bottle.

CLawson: That ZX80 code is a trip down memory lane. Thanks for the link.

Best all,

-br

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
The Spectrum used a similar system - it's fully documented ROM disassembly is available in the book by Dr Ian Logan.
I doubt any BASIC of the 8 bit era used anything else for program storage but tokens. Think about the memory requirements of even a moderately sized program if stored as plaintext - tokenisation cuts this down to a fraction, and RAM was really a scarce resource those times.

But the Sinclair computers employed one more smart trick: they simply did not allow to enter the keywords as strings, character per character; rather, each keyword was assigned to a key on the keyboard. The keyboard had all the keywords printed on the keys. The editor changed "modes" according to the syntax of the entered commands, automatically outputting either the keyword or single characters appropriately. This allowed to omit the tokenising parser altogether, at the cost of a slightly more complex editor. And it also spared some typing, which compensated somewhat for the crappy keyboard ;-) But you don't want that: it would be prohibitively restricting for the users if they would need to produce a custom keyboard to be able to use your system.

JW

PS. For studying purposes: the BASIC-52 sources are freely available together with the doc, but it's rather a mess as a result of squeezing an incredibly lot of functionality including floating point into 8kB of ROM.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Excuse my delurking. I though it might be worth while to take a look at AMForth. While Forth might not be an appropriate language for your application, it has already implemented some of the issues you're talking about, such as storing the program code into flash. It runs on any Mega with 8K or more of flash, including the 328.

http://amforth.sourceforge.net/