|
View:
New views
19 Messages
—
Rating Filter:
Alert me
|
|
|
git equivalent for svn updateI need to use git for the latest libusb 1.0 branch. But I
dare not to ask this question in the libusb mailing list. ;-) I read through git user manual here and also "git --help" but I could not find the equivalent of "svn update". http://www.kernel.org/pub/software/scm/git/docs/user-manual.html Am I missing something obvious? Xiaofan http://mcuee.blogspot.com -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
Re: git equivalent for svn updateOn Mon, May 5, 2008 at 8:05 PM, Xiaofan Chen <xiaofanc@...> wrote:
> I need to use git for the latest libusb 1.0 branch. But I > dare not to ask this question in the libusb mailing list. ;-) > > I read through git user manual here and also "git --help" but I could > not find the equivalent of "svn update". > http://www.kernel.org/pub/software/scm/git/docs/user-manual.html > > Am I missing something obvious? > It seems to me that "git pull" is the one. Is this correct? Xiaofan -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
Re: git equivalent for svn updateOn Mon, May 05, 2008 at 08:08:23PM +0800, Xiaofan Chen wrote:
> It seems to me that "git pull" is the one. Is this correct? Xiaofan, Yes - this is what I use. After the git checkout, I issue git pull to merge in the contents of the branch I switched to using the checkout command. Take care, -Chris -- | Christopher Cole, Cole Design and Development, LLC cole@... | | Embedded Software Development and Electronic Design http://coledd.com | | Stow, Ohio, USA 800-518-2154 | -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
Re: git equivalent for svn updateOn Mon, May 5, 2008 at 8:44 PM, Christopher Cole <cole@...> wrote:
> Yes - this is what I use. After the git checkout, I issue git pull to merge > in the contents of the branch I switched to using the checkout command. > Just want to double confirm this. I use "git clone" to get the initial check out. After that I use "git pull" inside the directory to update the check out, right? Something like following, right? git clone git://projects.reactivated.net/~dsd/libusb.git cd libusb git pull For subversion, I use "svn co" for the initial check out, and then I use "svn update" inside the check out directory to update. Something like following: svn co https://openusb.svn.sourceforge.net/svnroot/openusb/trunk openusb cd openusb svn update Xiaofan -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
Re: git equivalent for svn updateOn Mon, May 05, 2008 at 09:09:01PM +0800, Xiaofan Chen wrote:
> Just want to double confirm this. > I use "git clone" to get the initial check out. After that I use "git pull" > inside the directory to update the check out, right? Xiaofan, You are correct. Here is a nice web page that will allow you to leverage your SVN knowledge to learn git: http://git.or.cz/course/svn.html The top example is exactly what you are asking about. Take care, -Chris -- | Christopher Cole, Cole Design and Development, LLC cole@... | | Embedded Software Development and Electronic Design http://coledd.com | | Stow, Ohio, USA 800-518-2154 | -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
Re: git equivalent for svn updateOn Mon, May 5, 2008 at 10:29 PM, Christopher Cole <cole@...> wrote:
> You are correct. Here is a nice web page that will allow you to leverage > your SVN knowledge to learn git: > > http://git.or.cz/course/svn.html > > The top example is exactly what you are asking about. > Thank you. My git knowledge is now equivalent to my svn/cvs knowledge now. ;-) I only use two commands for all three. I only used "svn co" and "svn update"; "cvs checkout" and "cvs update"; and now "git clone" and "git pull". Now my limited knowledge serves me well. But I will need to learn more about cvs/svn/git and Bash/Make/etc. Xiaofan -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
Re: git equivalent for svn updateOn Mon, May 5, 2008 at 10:50 PM, Xiaofan Chen <xiaofanc@...> wrote:
> On Mon, May 5, 2008 at 10:29 PM, Christopher Cole <cole@...> wrote: > > You are correct. Here is a nice web page that will allow you to leverage > > your SVN knowledge to learn git: > > > > http://git.or.cz/course/svn.html > > > > The top example is exactly what you are asking about. Thanks again. This is a good site. Today I learned to use "git apply" (equivalent to patch -p0). Xiaofan -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
another bootloader questionIf I understand correctly, the bootloader code is typically located in an lower address area of the PIC flash memory, and protected from being written over. So when you want to execute the bootloader, you have to vector off to this address, and this is where my question comes in. I've seen it stated by some that you set a jumper or something that the code checks on power cycle to then branch to execute this code, but what about doing it in just firmware over the serial link? In other words, I have a remote box that I can't just go flip a switch or set a jumper and power cycle, but I need it to vector when it gets the command. Shouldn't be any different doing it that way vs some sort of hardware select? Pros, cons or issues?
--------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
Re: another bootloader questionOn Tue, May 6, 2008 at 8:38 PM, alan smith <micro_eng2@...> wrote:
> I've seen it stated by some that you set a jumper or something that the > code checks on power cycle to then branch to execute this code, but what > about doing it in just firmware over the serial link? PICkit 2 provides both method, you can either use a switch or send a command (over USB link) to get into the bootloader mode. PICkit 2 source codes (firmware+software) can be downloaded from the product website. http://www.microchip.com/pickit2 There are also internet bootloader for 18J Ethernet PIC. http://www.microchip.com/tcpip Xiaofan http://mcuee.blogspot.com -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
Re: another bootloader questionOne method of handling this is to have the bootloader send a character or
string on reset, then wait for a response from a host computer. If there is no response, the main application starts. If the main application wants to start the bootloader, it can either reset the PIC or do a goto 0. One issue is that if the main application gets corrupted. You then can't get it to accept the command to start the bootloader. But, if you have the WDT running, ideally a corrupt program will cause an occasional WDT reset. This starts the bootloader, which the host then has an opportunity to respond to. Harold -- FCC Rules Updated Daily at http://www.hallikainen.com - Advertising opportunities available! -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
Re: another bootloader questionIn this case, PIC1 will be updating PIC2 over a serial link, where PIC1 is connected to a PC host, sending commands thru a serial port. PIC1 acts as a gateway for PIC2, so I guess that does answer the question, since you can do updates over an ethernet link, you can via software commands put the remote into a bootloader mode.
Thanks Xiaofan Chen <xiaofanc@...> wrote: On Tue, May 6, 2008 at 8:38 PM, alan smith wrote: > I've seen it stated by some that you set a jumper or something that the > code checks on power cycle to then branch to execute this code, but what > about doing it in just firmware over the serial link? PICkit 2 provides both method, you can either use a switch or send a command (over USB link) to get into the bootloader mode. PICkit 2 source codes (firmware+software) can be downloaded from the product website. http://www.microchip.com/pickit2 There are also internet bootloader for 18J Ethernet PIC. http://www.microchip.com/tcpip Xiaofan http://mcuee.blogspot.com -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
Re: another bootloader question>> I've seen it stated by some that you set a jumper or something that the
>> code checks on power cycle to then branch to execute this code, but what >> about doing it in just firmware over the serial link? > > PICkit 2 provides both method, you can either use a switch or send a > command (over USB link) to get into the bootloader mode. And now for the $$$ question: *why* does pickit2 offer both methods? (sorry, switch off interactive teacher mode, switch on instruction mode) The main point with any bootloader is: can you trust the application to jield control to the bootloader? In most cases you can't, so you need a 'hardware' method to activate the bootloader. -- Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: www.voti.nl/hvu -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
|
|
|
RE: another bootloader question> -----Original Message----- > From: piclist-bounces@... [mailto:piclist-bounces@...] On Behalf > Of Funny NYPD > Sent: 06 May 2008 19:16 > To: Microcontroller discussion list - Public. > Subject: Re: [PIC] another bootloader question > > I would like to say, one for easy of use, and one for reliability. > Our bootloaders support both entry method too: you can use a hardware > signal to trigger bootloader mode, or you can have the embedded > application software developed and use the "Reset PIC" push button on the > bootloader program force the chip enter bootloader mode. > > Here is a bootloader ( with encryption capability) application note for > the hot SAE-J1939 simulator product: > http://www.auelectronics.com/UserManual-Au_PICBootloader.htm The bootloader I developed for use in a product is always run at power up, and checksums the main program image (which is always a fixed size). If the image is ok, it jumps to the entry point, if not it's ready to accept some code over the comms link. The main program can also jump to another entry point in the bootloader if the user wants to download new code, or one of several other services the bootloader offers (almost like a BIOS). Regards Mike ======================================================================= This e-mail is intended for the person it is addressed to only. The information contained in it may be confidential and/or protected by law. If you are not the intended recipient of this message, you must not make any use of this information, or copy or show it to any person. Please contact us immediately to tell us that you have received this e-mail, and return the original to us. Any use, forwarding, printing or copying of this message is strictly prohibited. No part of this message can be considered a request for goods or services. ======================================================================= -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
Re: another bootloader question> The bootloader I developed for use in a product is always run at power
> up, and checksums the main program image (which is always a fixed size). > If the image is ok, it jumps to the entry point So how do you re-bootload once Murphy has succeeded in bootloading an image (with correct checksum) that refuses to bootload? -- Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: www.voti.nl/hvu -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
RE: another bootloader question> -----Original Message----- > From: piclist-bounces@... [mailto:piclist-bounces@...] On Behalf > Of Wouter van Ooijen > Sent: 06 May 2008 20:20 > To: Microcontroller discussion list - Public. > Subject: Re: [PIC] another bootloader question > > > The bootloader I developed for use in a product is always run at power > > up, and checksums the main program image (which is always a fixed size). > > If the image is ok, it jumps to the entry point > > So how do you re-bootload once Murphy has succeeded in bootloading an > image (with correct checksum) that refuses to bootload? The bootloader is only for the convenience of our customers, so any firmware images will be thoroughly tested before being released. In the lab or production facility we use a JTAG interface to program the devices. The products have no user interface, e.g. buttons etc. so checking for this kind of input is difficult. The latest project has enough spare pins on the main interface that we can use a separate serial interface for bootloading and test another pin to enable it, but this is very much an exception as we rarely have spare pins on the modules connector (which is usually defined by a multi-source agreement and therefore can't be changed). Regards Mike ======================================================================= This e-mail is intended for the person it is addressed to only. The information contained in it may be confidential and/or protected by law. If you are not the intended recipient of this message, you must not make any use of this information, or copy or show it to any person. Please contact us immediately to tell us that you have received this e-mail, and return the original to us. Any use, forwarding, printing or copying of this message is strictly prohibited. No part of this message can be considered a request for goods or services. ======================================================================= -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
Re: another bootloader question>> So how do you re-bootload once Murphy has succeeded in bootloading an
>> image (with correct checksum) that refuses to bootload? > > The bootloader is only for the convenience of our customers, so any > firmware images will be thoroughly tested before being released. In the > lab or production facility we use a JTAG interface to program the > devices. That approach is (of course) feasible if the chance of uploading a non-cooperative image is 'sufficiently small' compared to the cost of re-programming using another mechanism (or the loss of the device). Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: www.voti.nl/hvu -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
Re: another bootloader question> >> So how do you re-bootload once Murphy has succeeded in bootloading an
> >> image (with correct checksum) that refuses to bootload? > > > > The bootloader is only for the convenience of our customers, so any > > firmware images will be thoroughly tested before being released. In the > > lab or production facility we use a JTAG interface to program the > > devices. > > That approach is (of course) feasible if the chance of uploading a > non-cooperative image is 'sufficiently small' compared to the cost of > re-programming using another mechanism (or the loss of the device). Personally this is one reason why I like bootloaders that initialise at reset, briefly look for comms from a loader program, and if not present run previously loaded code. I often also write into the PIC application code a "soft entry" mechanism for starting the bootloader at will (often causing a watchdog timeout is the easiest/tidiest, depends if I need to maintain I/O staus or anything special) on receipt of an appropriate serial command. That way there is less for the user to do when upgrading firmware (even for me when developing ~ I hate reaching accross the desk to press a reset button or cycle power!). This also suits when a hardware reset or power on/off is not convenient or otherwise not possible, eg. target may be remotely located and code updated over internet. Oh, and the loader program I use also toggles the RTS line which in some cases I use to force a hardware reset of the PIC. In testing I intentionally crash the bootloading operation to see what ill effects it has. Most of the time, surprisingly, there is no problem, and the process can be easily restarted! It can of course mess up your application code, but not as much as you might think, thanks in part to the PIC's single word instruction width (other micro's go beserk easier it seems). If the application code does hang after a failed loading operation and doesn't allow the "soft entry" to the bootloader, power cycling or other hardware reset will initiate the bootloader and get things going again. In reality I very rarely see any cases where I need to re-load the bootloader, if I do this usually happens during development. What also aids robustness is having bootloader code designed so that it can not write over itself. Simple bootloaders don't check for this (minimses bootloader code size). Some rely on the PC side filtering out illegal addresses (errant code on PIC can still cause havoc). Even better if the area of memory the bootloader code resides in can be secured. -- Brent Brown, Electronic Design Solutions 16 English Street, St Andrews, Hamilton 3200, New Zealand Ph: +64 7 849 0069 Fax: +64 7 849 0071 Cell: +64 27 433 4069 eMail: brent.brown@... -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist |
|
|
RE: another bootloader question |