On 09/21/2016 09:53 PM, bruce m beach wrote:
memory will be very tight. There is 160k or known ram and bits and pieces
elsewhere. The rom is 24k (maximum). I currently am not to worried about
it. (although I am watching it)
bruce
Probably you know this...but check structs for memory holes, unused
fields (write only, for instance) and other wastes.
ath10k firmware was full of needless memory bloat in those areas.
Global pointers can be used in some cases to help, but mysteriously
seem to cause more instruction RAM in some cases.
Watch 'instruction ram' usage: Changing code to use a bitfield may save
some BSS ram, but may easily use far more instruction ram than what you
saved with the bitfield.
Good luck!
Thanks,
Ben
On 9/21/16, Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote:
On 09/21/2016 08:34 PM, bruce m beach wrote:
i.e a lable that the code jumps to and nothing else. At this point I
have
added VendorCommand(), and a debugger via ep0. ( ep0 is a good choice
since it is available a boot, no matter what) and over the next few
months I am going to move ->all<- the rom code into ram starting with
the USB subsystem.
Have you investigated whether you have enough RAM to do this?
I haven't looked at ath9k_htc, but in general, that type of architecture
is tight on RAM in my experience.
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
