PICcoder.co.uk Forum  


Post a new message in "Article Discussion"
Name:
Subject:
This image contains a scrambled text, it is using a combination of colors, font size, background, angle in order to disallow computer to automate reading. You will have to reproduce it to post on my homepage Enter what you see: *
tips: hit Reload page before writing a text if you have difficulty reading characters in image
topic icon:
no
boardcode:
 Colour:  Size:   Close all tags
Message:

emoticons
B) ;) :) :P
:laugh: :ohmy: :sick: :angry:
:blink: :( :unsure: :kiss:
:woohoo: :lol: :silly: :pinch:
:side: :whistle: :evil: :S
:blush: :cheer: :huh: :dry:

Topic History of: USB Bootloader
Max. showing the last posts - (Last post first)
Author Message
anonymous :) Hi 2 all

What is the SW2?
Mike Not an example as such because all the useful code is hidden in the dll!



Mike
Mat Forget that, i'm being really stupid its late here in the UK (23:12) and my brain wasn't quite functioning right. Bank 4 of the RAM can be used for general purpose, however if you want to use the USB port then bank 4 will be required by the SIE (USB controller), as it is the dual port RAM, and therefore cannot be used for any other purpose, if the USB is being used. See section 5.3.1 of the pic18f4550 data sheet.



So rearrange your RAM usage around Bank 4 for the time being and that should help you out a bit later on.



Sorry about the mistake before, its been a long day.



Mat
Mat Hi TIA,



This is a bit of a guess, but from one of my compiles I would be looking at around 1700 for the program memory and 350 for the data memory. You will need this for the boot loader and for the usb code, so in total, 3400 and 700 respectively would be my estimate.



If you take a look in the linker files with the microchip demo code, you will be able to see the memory break down, I would try and avoid the usb areas, although I can't see any reason why these can't be moved around, it just might complicated things later on, if you try to integrate the microchip usb code into your application.



Mat
NAB Thanks for your reply and for your offer, we'll see where this project goes.



I would just like you to clarify your answer if you could.

We're not talking about having to reserve particular memory addresses, just reserving enough free RAM to allow our firmware to grow...right?



Currently, the Memory Usage Gage indicates I have used 10000 bytes out of 16384 bytes for program memory and 973 bytes out of 2048 bytes for data memory. How will this change with the addition of a bootloader and how much should I assume we will need for USB development? If you don't know then just take a wag at it !



TIA
Mat Hi NAB,

Firstly welcome to the site, and i'm glad you've found the articles helpful!!



You guy is correct the USB requires a proportion of the RAM to operate and without this life gets very difficult if not impossible. So you have to keep an eye on the RAM usage, the amount you will need will be affected by how well the USB functionality is written, and what type of data you are transporting via the USB.



The easiest way to find out how much ram is being using is by using the memory gauge in MPLAB (its under the view menu), least this is where I remember it being off the top of my head.



One thing I should probably warn you about though is that adding USB functionality later could prove very difficult. USB cannot be treated like RS232 and added in where required, the very nature of USB means that it needs constant monitoring and therefore I would recommend organizing the firmware to cope with these additions as soon as possible, otherwise you will create larger issues later on.



I have just setup an embedded consulting company, Wakari Limited. If you need any software or circuitry developing for embedded systems, especially for USB coding, then do not hesitate to contact me and I will happily provide you with a quote.



Hope that helps,



Mat