Playing with SPI RAM
Re: Playing with SPI RAM
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.
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.
Re: Playing with SPI RAM
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.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.
-
- Posts: 1486
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Playing with SPI RAM
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.
Only about 30K of that is not hand crafted ASM or data files. So its about 10% savings.
-
- Posts: 86
- Joined: Sun Jan 04, 2015 4:38 am
Re: Playing with SPI RAM
Pretty easy summary(this is REALLY simplified, so some of these can do "other things" I think):CunningFellow wrote:If someone can teach me to use GIT I can do simple non-chance-of-breaking-anything changes like these myself
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/
Re: Playing with SPI RAM
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...
-
- Posts: 1486
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Playing with SPI RAM
I used this procompiled one
http://www.avrfreaks.net/forum/gcc-492-released-today
(the mobile chess link)
http://www.avrfreaks.net/forum/gcc-492-released-today
(the mobile chess link)
Re: Playing with SPI RAM
OK, thanks, I will try it out.CunningFellow wrote:I used this procompiled one
http://www.avrfreaks.net/forum/gcc-492-released-today
(the mobile chess link)
-
- Posts: 86
- Joined: Sun Jan 04, 2015 4:38 am
Re: Playing with SPI RAM
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.
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.
Re: Playing with SPI RAM
Wasn't aware of that issue, I'll have a look.uberlinuxguy wrote: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.
Re: Playing with SPI RAM
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?