Some new/random ideas...

A stateful/functional/concurrent programming language? These are very rough notes as I'm getting too tired to write more about it tonight.

const int exampleconstant = 12345;
^ syntatic sugar for:
object exampleconstant {
start() = {int this = 12345; state = const;}
}

class foo {
start(type(input) != foo) = {
int i = 0;
int a = 32;
int b = 64;
state = wait;
}
start(typeof(input) == foo)) {
this = input;
}
iterate(typeof(input) == integer) = {
a = a + input;
b = b - input;
i = i + input;
output = a * b;
state = (a < b) ? iterate : end;
}
iterate(typeof(input) != integer) = {
print("illegal input: " + input);
output = error;
}
end() = {
output = i;
}
}

It's an odd mixture of functional/concurrent programming with a C-like syntax.

What makes it different than you see in the code sample...

- input and output are reserved variables. you don't have to 'catch' the output if it's not the type you're looking for, i think. they can also be arrays.

- state is an implicit variable that denotes what to run on the next trigger. i.e. all objects are state machines.

- functions are transactional. everything you see changed is actually pushed into the object at the end of the iteration - what would be a side effect in a regular language is *not* one here.

- objects can also be an instance of one variable.

----

slightly leaving cloudcucooland, i should write a simple FM-type synthesizer because, well, they're not hard to do.

the synth algo i have in mind supports continuous frequency adjustment (calculus-)integration. the frequency and amplitude are continuous functions in time, allowing for smooth changes in generated sound.

sine waves can be flattened from from triangular (0) to square (1), with sine = 0.5. phase restrictions can create interesting waveform patterns on top of that. for instance sawtooth waves can be generated by using (0, pi/4?) phase restrictions.

---

haven't touched my ARM project lately. need to get interrupts working, add newBSD/MIT license, and give credit to Vijay Kumar for showing the path.

I want something simple to play with registers without flashing - it might mean making the serial code I have now a bootloader that can cut over to a new downloaded program in memory... or I might write something small and FORTHlike.

Checked hw-working code into SVN...

Finally cracked serial port and clock setup on real hardware tonight. I was also able to set up the PLL to run the chip at 50mhz - and even over clock it to 100mhz. :)

Interrupts don't work yet, but eh.

I think I should write something FORTH-like next so I won't have to flash the chip too much, or at least a super-simple interpreter of some sort for HW bringup.

c++ virtual-functioning runtime in 270 lines, no asm.

Interrupts definitely won't work yet, but I've got virtual functions working and it's dealing with multiple source files even. No assembly needed! (and it does use libgcc for some helper code...)

http://code.google.com/p/chadslab/source/browse/#svn/trunk/m++

Cortex-M3 + CodeSourcery startup...

This .pdf documents how to write a minimal C program to run on the LM3S811EVB qemu target:

http://www.bravegnu.org/gnu-eprog-handout.pdf

Install CodeSourcery and have fun! I'm going to look into elaborating on this over the weekend. Maybe even blink an LED on my LPC13xx board...

---

Compiling CMSIS w/CodeSourcery w/o IDE...

This is for the LPC13XX target. This also works with Luminary Micro's stuff as long as you change the relevant LPC13xx's to LM3's.

- Get the CodeSourcery tarball for Linux and extract it.
- Set path to [extraction dir]/bin:$PATH to get the toolchain in path

- Get the CMSIS library from onarm.com and extract it
- create a flat cmsis directory outside of that tree
- copy CMSIS_V1P30/CM3/CoreSupport/core_cm3.* to it
- then CMSIS_V1P30/CM3/DeviceSupport/NXP/LPC13xx/startup/gcc/*
- finally CMSIS_V1P30/CM3/Example/Sourcery\ G++Lite/LPC13xx/*

Then make a start.c with an empty _start() function.

To build: arm-none-eabi-gcc -mcpu=cortex-m3 -msoft-float -mthumb -fno-common -Wl,-cref,'-Map=map.txt',-S,'-TLPC13xx.ld' *.c startup_LPC13xx.s

And to de-ELF it so you can write it to flash: arm-none-eabi-objcopy a.out -O binary a.bin

Now to actually build and run code. The next step is to build the LM3 version and run it under qemu's L3MS811 EVB emulation... and not have it crash.

Some crazy macro-abuse I came up with..

... not terribly useful in and of itself, but it allows for an organized extensible systemcall-y/pseudo-dynamic library setup.

#include <stdio.h>

#define BEGIN_FUNC(name, inm, outm) \
       typedef struct name##_in_t { inm }  name##_in; \
       typedef struct name##_out_t { outm }  name##_out; \
       name##_out name(name##_in *in) {name##_out out; printf("l%d %d\n", sizeof(name##_in), sizeof(name##_out));

#define END_FUNC return out;}
#define CALL(output, name, invar ... ) output = name(&(name##_in){invar})
#define CALLA(output, name, invar ... ) name##_out output = name(&(name##_in){invar})

BEGIN_FUNC(test, int a; int ab;, int b;)
       printf("%d %d\n", in->a, in->ab);
       out.b = in->a * 2;
END_FUNC

int main(void)
{
       int x = 2;

       CALLA(outpt, test, 20, x);
       printf("%d\n", outpt.b);
       CALL(outpt, test, 30);
       printf("%d\n", outpt.b);

       return 0;
}

Notes on the PS3 wireless keypad and Linux...

The "PS3" Wireless Keypad is actually a small Bluetooth(r) keyboard+mouse.

To get it into pairing mode with other devices, hold down the blue button and turn the power 'on' and wait for blinkinglights. Then you can pair with it normally - set a PIN and like most other bluetooth kbd's, enter the PIN number and type enter.

And no, you can't use it as a USB keyboard.

I'm not quite sure how the modifier keys work yet, and how to properly map it. More details will come later as I figure out how to actually use it. ;) I've made a little progress using the "input-events" program (ubuntu: input-utils pkg)

As a general keyboard there are definitely "holes" in the keymap. The blue(left) button works as left shift for the keys it feels like working for, and the right is right alt.

However, they're only active for some keys, and those keys get remapped.

Therefore, to make this thing *actually* work, one needs to map other keys in as CTRL and ALT. The two buttons next to the keypad select switch (which map as F24 and F23) should work nicely for this.

The Linux input drivers can't do remapping on this, but x.org's event driver can.

xmodmap -e "keycode 202 = Control_L" < that *should* have worked, but the actual modifier isn't kicking in. Argh. But I'm tired, so that's a problem for another day...

mini 6502 emulator v0.001

I checked my very early 6502 source into google code (project: chadslab) - it's not debugged at all, but it's the smallest emulator I know of.

tl;dr the 6502's logic is really elegant and I felt like trying to writing .c file out of it. :)