Playing with SPI RAM

[uze6666]

I'm ok with the size right now. I'd like to be the sole maintainer of the bootloader due to it's criticality and the fact I include it in all my kits. I don't want to deal with returns because of things I didn't know.

On this one, for me its going to be: if it's not broken don't fix it. At least for now.

Update: Which reminds me of putting a copy the original sd code in the project to avoid any regressions.

[uze6666]

BTW - is the bootloader still using GCC 4.7.x with -Os for the C parts? Switching to 4.9.x alone may save significant space.

Hum, though I had a more recent version, but no...I still use 4.6.1 on my main machine (with -Os always). Will look to upgrade to 4.9 if it's available in minGW.

[CunningFellow]

In T2K the difference between 4.7.x and 4.9.2 is -Os not fitting the game into 60K of flash to having 4K free.

Only about 30K of that is not hand crafted ASM or data files. So its about 10% savings.

[uberlinuxguy]

If someone can teach me to use GIT I can do simple non-chance-of-breaking-anything changes like these myself

Pretty easy summary(this is REALLY simplified, so some of these can do "other things" I think):

git clone - copies repo into a new directory
git pull - pulls changes into an already established local repo
git commit - commits your changes but doesn't push them back to the main repo (think of it as a checkpoint)
git push - pushes changes back to the main repo.

There are TONS of other bits, but that is the quick start version.

This also seems useful: https://training.github.com/kit/downloa ... -sheet.pdf
As well as the links here: https://help.github.com/articles/good-r ... nd-github/

[uze6666]

Where have you got the 4.9.2 version for AVR? I'm looking for a precompiled version for Window and can't seem to find one...

[CunningFellow]

I used this procompiled one

http://www.avrfreaks.net/forum/gcc-492-released-today

(the mobile chess link)

[uze6666]

I used this procompiled one

http://www.avrfreaks.net/forum/gcc-492-released-today

(the mobile chess link)

OK, thanks, I will try it out.

[uberlinuxguy]

So I just got back to playing around with Uzebox. Things have been insane for me.

I was working on the emulator code again and finally figured out one of my problems. For some reason, all the SD code was returning nothing in the buffer. After some investigation, and flipping from Emulator, to ROM code, to Kernel Code, I figured out that the first line in "mmc_init:" in mmc.s got set to "call spi_init" but that this clobbered the arguments sent to mmc_init. That line needs to move under the "sts" calls in that function. Not sure if you already picked up on this or not Uze.

But with that fixed, the emulator still travels off to never-never-land for some reason. So that is the next thing I have to figure out. I think it's a logic error on my part in the new SPI code, but I have to find out where.

[uze6666]

So I just got back to playing around with Uzebox. Things have been insane for me.

I was working on the emulator code again and finally figured out one of my problems. For some reason, all the SD code was returning nothing in the buffer. After some investigation, and flipping from Emulator, to ROM code, to Kernel Code, I figured out that the first line in "mmc_init:" in mmc.s got set to "call spi_init" but that this clobbered the arguments sent to mmc_init. That line needs to move under the "sts" calls in that function. Not sure if you already picked up on this or not Uze.

Wasn't aware of that issue, I'll have a look.

[D3thAdd3r]

Pretty basic question about the AVR SPI hardware, and I think I already know the answer, it is a shift register that I cannot "access early" until it latches correct? If an SPI byte 0b11111111 was coming in at 1 bit every 2 clocks, and I read it after 4 clocks, I would not expect to get 0b00000011 but instead whatever last latched until the new byte has fully arrived?