Add a game, maybe

[joric]

Managed to run Tetris on TS100 on top of official 2.17 firmware: https://github.com/joric/ts100tris/ Maybe add a game too, or an easter egg of some sort, there's plenty of space and CPU power. Though it's pretty hard to play tetris using only two buttons - I haven't managed to make use of accelerometer - it seems there's only one working X axis in a standard API and it doesn't differentiate left and right. Is it possible to use a built in accelerometer to determine left and right tilt?

[gordio]

Better spend time on menu and configuration. For example "Favorite Temperature", or smart decrease temperature if iron pointing to up, and increase when down, I think.

[Ralim]

Hi, @joric You should be able to detect the tilt by reading the status from the Accelerometer in the iron. Sadly I cannot build your firmware as I don't currently use the IAR software toolchain, however adding a game or something fun could be an interesting idea to expand on in the firmware.

@gordio Can you expand on the Favourite Temperature suggestion? The system currently remembers your last temperature, is this more in reference to setting a default instead, and adjusting per session?

I'm not sure what you are referring to using tilt to adjust temperature or?

[joric]

I mean, that's what I got from available API, using Update_X() (Update_Y/Update_Z are static for some reason):

http://i.imgur.com/G1vSI8d.gif

It can't even be used for adjusting temperature because it's apparently unsigned and the range is just one byte (if you point the tip up from the horizontal position it's precisely the same 0-255 range as if you point the tip down). I guess it needs to be properly initialized or it should be read differently.

void Show_Number(u32 n) {
  int i, k;
  u8 * ptr;
  u8 buf[8];

  for (i=0;i<8; i++) {
    buf[7-i] = (n%10)+'0';
    n/=10;
  }

  for (i=0;i<8; i++) {
    if (buf[i]>=0x30 && buf[i]< 0x3a) buf[i] = buf[i] - 0x30;
  }

  for(i = 0; i < 24; i++)
    for (k=0; k<8; k++)
      Ver_s[k * 24 + i] = Number12[buf[k] * 24 + i];

  for(k = 0; k < 16; k++) {
    ptr = (u8*)Ver_s;
    for(i = 0; i < 8; i++) {
      ptr = Oled_DrawArea(i*12,0,12,16,ptr);
    }
  }
}

void Show_Accelerometer(void) {
  Check_Accelerated();
  u16 n = Update_X();
  Show_Number(n);
}

[joric]

I'm thinking maybe it's possible to add lua/micropython to write user space apps. Considering it already has a built in flash drive for config and logo and can store random files it looks like a trivial task.

[joric]

Though, maybe not. This MCU (STM32F103T8U6) is really micro - 20 Kb RAM, 64 Kb ROM, while eLUA memory footprint is "at least 256 kbytes of flash memory, and at least 64 kbytes of RAM" and micropython is "80K of ARM Thumb2 code" and "8KB is minimal amount to run simple scripts" so I guess we stuck with native C (or smaller interpreters).

[Ralim]

Hi, The other really big issue is that the virtual usb drive takes up the last chunks of flash, so I think there is actually only around 40kb or so of flash left after that, which the current code won't fit in on open source compilers. (I tried for a while to keep the usb config file in this version of the software, but ultimately cut it out to regain the flash space so the other features could fit. This is mostly just a difference in efficiency between iar and gcc at the moment.

Honestly sticking with C makes the most sense anyway, as we want to keep the control loop tight, and it's far more efficient than running any sort of compiler.

[joric]

Apparently there's a good chance that it might have 128k onboard instead of 64k as in specs. "My observations show that stm32f030f4 has 32 kilobytes instead of 16 kilobytes, stm32f103c8 has 128 kilobytes instead of 64, stm32f407ve has 1024 instead of 512, despite its Flash Size area contains value 512." I'll try to figure out maybe there is really 128k. Running micropython on this thing could really give it a second life.

[Ralim]

That was true of some revisions of the chip. Some of the newer ones do not have the extra flash available or they just crash randomly if you try and use it. I feel it would be a serious issue if software assumed it was there and then crashed randomly for some percentage of users because they had an iron that didn't let that flash work?

[joric]

Maybe a lightweight LUA then but I can't find an STM32 compatible LUA as a library that doesn't try to occupy all the possible space (eLUA is not a library).

[Ralim]

Hrm, maybe. I have no idea of what would fit in the remaining 32K of flash that is spare in this build. I'm tempted to add a game or screensaver of some kind just for fun :)

[joric]

Sadly I got no luck with LUA, PyMite (managed to build version 0.3 which is the smallest but couldn't allocate blocks for pm_init) and even Pawn, which has an assembly version with the smallest footprint, about 5kb overall, says the same "unable to allocate space for sections/blocks". I guess stock firmware is just way too large to fit any of that. Wondering what options I could tweak to make it smaller. Also I didn't like the fact that PyMite/Pawn work with precompiled scripts only, makes it way less handy than plain text. Too bad.

[joric]

Managed to run precompiled Pawn script from the USB drive (see the scripting branch). Memory requirements are really tight (Tools-Options-Messages-Show Build Messages-All): Stock firmware:

  30 324 bytes of readonly  code memory 
   1 090 bytes of readonly  data memory 
  13 884 bytes of readwrite data memory 

Added Pawn with pure assembly core:

Error[Lp011]: section placement failed 
          unable to allocate space for sections/blocks with a total estimated minimum size of 0x81d3 bytes (max align 0x4) in <[0x08004000-0x0800bfff]> (total uncommitted space 0x7ed0). 

  32 372 bytes of readonly  code memory 
   1 217 bytes of readonly  data memory 
  13 884 bytes of readwrite data memory 

Commented out a couple of pages of menu handling code:

  31 444 bytes of readonly  code memory 
   1 307 bytes of readonly  data memory 
  14 108 bytes of readwrite data memory 

I guess with Pawn I'd have to replace the built in menu system with scripting.

[Ralim]

I think if you're feeling like going that method it might be worth moving most of the control system over to pawn. Maybe just leave the hardware PID in C code ?

[joric]

Yep. But there's a lot of problems (e.g. that USB drive handling code is pretty weird) and not so much space. And I'd really have to do a lot of experimenting before rolling this scripting feature out. Closing for now. Upd: got working screen autorotation in this branch: https://github.com/joric/ts100tris/tree/autorotate the new accelerometer code can be easily used for the left and right tilt (just call Get_XYZDrt(AXIS_Y) for direction and Update_X() for value).