• AVR Freaks

Hot!Programming via Ethernet interface?

Page: < 12 Showing page 2 of 2
Author
Olin Lathrop
Super Member
  • Total Posts : 7463
  • Reward points : 0
  • Joined: 2004/02/26 17:59:01
  • Location: Littleton Massachusetts
  • Status: offline
RE: Programming via Ethernet interface? 2007/03/08 16:48:16 (permalink)
0
If I go ahead with this type of plan is the PIC going to have to be programmed via ICSP or some other method initially to get the bootloader code into the micro, or is there some method of doing the initial programming in a similar fashion to our firmware upgrade?

No.  A bootloader is code that runs in the PIC, so it has to get there somehow without its own assistance at least once.
 
The easiest way is to program the bootloader into the PIC at production time using ICSP.  You have to consider the programming lines getting wiggled when you design your circuit, but it's usually not much trouble as long as you think about it up front.  Take a look at my circuit design guide for ICSP before you design your circuit.
 
Others have suggested gettng pre-programmed PICs, but this is only a feasible solution in certain cases.  There is some expense to get this going, but the biggest problem is that you are committing to a particular firmware version with a long lead time.  You can't discover a bug or add a new feature easily and quickly, and you might then end up with a bunch of PICs preprogrammed to a old version you no longer want to use.  This is really only for high volume stable products.  Your product is going to go thru some sort of manufacturing test anyway, usually adding ICSP to that process is a relatively small incremental cost.
#21
Olin Lathrop
Super Member
  • Total Posts : 7463
  • Reward points : 0
  • Joined: 2004/02/26 17:59:01
  • Location: Littleton Massachusetts
  • Status: offline
RE: Programming via Ethernet interface? 2007/03/08 16:51:52 (permalink)
0
During a brownout, RAM addresses, including the program counter, can take on random values.  If the program counter happens to take on a random value somewhere near the start of your flash write routine, guess what happens?

You're talking about something very unlikely.  I have never seen this happen in my experience, but I have seen problems where bootloaders needed to be updated in the field.  It's all based on probabilities and costs of occurrence.  In my experience it's a lot more expensive to have a permanently fixed bootloader than a unprotected one.
#22
Olin Lathrop
Super Member
  • Total Posts : 7463
  • Reward points : 0
  • Joined: 2004/02/26 17:59:01
  • Location: Littleton Massachusetts
  • Status: offline
RE: Programming via Ethernet interface? 2007/03/08 16:57:58 (permalink)
0
If the vectors are in the bootloader area then either the interrupt routines must be at fixed known locations ...

Well, let's say that the bootloader resides entirely in the space of 0x000 through 0x1FF, and let's assume that the ISR vectors are at 0x008 and 0x018. One would just hardcode a GOTO 0x208 at 0x008 and a GOTO 0x218 at 0x018. Then the user code would reside in one big chunk from 0x200 and beyond,

That's what I meant by interrupt routines at "fixed known locations".

Thus I would say that the drawback of having the bootloader first is pretty much just an issue of performance, specifically those two extra instruction cycles used in the goto.

It can also make development harder.  On a recent 18F bootloader I did, I put a GOTO the bootloader start address at 0.  The bootloader has to know how to start the app somehow, so I made the app start location 4.  That leaves just enough room for a GOTO before the first interrupt vector.  The nice thing about this is that it makes testing the app by itself easy.  The app doesn't specify the locations 0-3, so they stay at the erased state, which is NOPs.  That means if I load in just the app without the bootloader, the PIC executes 4 NOPs on startup followed by a GOTO to the relocatable startup code of the app.  In other words, the app just runs if programmed by itself, but the bootloader runs from reset when the full blown production image is programmed.
#23
jesseg
Senior Member
  • Total Posts : 122
  • Reward points : 0
  • Joined: 2006/08/02 09:20:22
  • Location: 0
  • Status: offline
RE: Programming via Ethernet interface? 2007/03/08 17:03:06 (permalink)
0
but the biggest problem is that you are committing to a particular firmware version with a long lead time.


I suggested only having a simple serial (not TCP based) bootloader pre-programmed. Not the whole firmware!

Thus, all you'd be committing to was whatever the cost of having the pre programmed. First of all, you're certainly not committing to any main firmware whatsoever, and it would be hard to say that you're committing to even that version of bootloader. You can always reprogram them yourself to a different bootloader.

and you might then end up with a bunch of PICs preprogrammed to a old version you no longer want to use.

in which case you'd simply be where you would have otherwise started out -- with a bunch of PICs that need to program before you can use them.

A simple bootloader is really pretty simple.


-Jesse

#24
jtemples
عُضْوٌ جَدِيد
  • Total Posts : 11214
  • Reward points : 0
  • Joined: 2004/02/13 12:31:19
  • Location: Southern California
  • Status: offline
RE: Programming via Ethernet interface? 2007/03/08 17:03:21 (permalink)
0
ORIGINAL: Olin Lathrop

During a brownout, RAM addresses, including the program counter, can take on random values.  If the program counter happens to take on a random value somewhere near the start of your flash write routine, guess what happens?

You're talking about something very unlikely.

Much more likely than you think, apparently.  I've seen several posts on these forums where flash (or internal EEPROM, which faces the same issue) is mysteriously corrupted when a system is powered on or off.  In most cases, these systems had no protection from brownout.  And I've seen commercial products come back from the field with corrupted bootloaders for the same reason.

In my experience it's a lot more expensive to have a permanently fixed bootloader than a unprotected one.

I was not arguing for or against a protected bootloader.  I said, "Any system with a bootloader that isn't code-protected and that has the possibility of browning out can destroy the bootloader."  
#25
asmallri
Super Member
  • Total Posts : 1864
  • Reward points : 0
  • Joined: 2004/05/26 09:00:05
  • Location: Perth, Australia
  • Status: offline
RE: Programming via Ethernet interface? 2007/03/08 20:14:30 (permalink)
0
It can also make development harder.  On a recent 18F bootloader I did, I put a GOTO the bootloader start address at 0.  The bootloader has to know how to start the app somehow, so I made the app start location 4.  That leaves just enough room for a GOTO before the first interrupt vector.  The nice thing about this is that it makes testing the app by itself easy.  The app doesn't specify the locations 0-3, so they stay at the erased state, which is NOPs.  That means if I load in just the app without the bootloader, the PIC executes 4 NOPs on startup followed by a GOTO to the relocatable startup code of the app.  In other words, the app just runs if programmed by itself, but the bootloader runs from reset when the full blown production image is programmed.


I use a different technique but the result is similar. My bootloaders intercepts the application's reset vector code from the source hex record. This tell the bootloader when to pass control. If the bootloader is not installed, the applications reset vector gets executed passing control to the application code. It the bootloader is present it is passed control. None of my bootloaders use interrupts, I consider it bad programming to have the bootloader remap the vectors (and why putting a boot segement in low memory just palin stupid). This unnecessary remapping of the interrupt vectors means the application code is always impacted by the presence of the bootloader.

Regards, Andrew

http://www.brushelectronics.com/index.php?page=software
Home of Ethernet, SD Card, and Encrypted Serial and USB Bootloaders for PICs!!
#26
jesseg
Senior Member
  • Total Posts : 122
  • Reward points : 0
  • Joined: 2006/08/02 09:20:22
  • Location: 0
  • Status: offline
RE: Programming via Ethernet interface? 2007/03/08 20:24:09 (permalink)
0
That's what I meant by interrupt routines at "fixed known locations".

But isn't the condition without a bootloader also the same in that one is required to put their interrupt routines in fixed known locations..?!

I guess I don't see the difference between having the interrupt vector at a fixed location of 0x208 and a fixed location of 0x008. They're both just addresses(Besides, of course, the already noted 2-cycle delay.)Smile

-Jesse


#27
jesseg
Senior Member
  • Total Posts : 122
  • Reward points : 0
  • Joined: 2006/08/02 09:20:22
  • Location: 0
  • Status: offline
RE: Programming via Ethernet interface? 2007/03/08 20:29:32 (permalink)
0
None of my bootloaders use interrupts, I consider it bad programming to have the bootloader remap the vectors (and why putting a boot segement in low memory just palin stupid). This unnecessary remapping of the interrupt vectors means the application code is always impacted by the presence of the bootloader.


Alas, bootloaders require either the remapping of the interrupt vector(s) or the reset vector*.grin
Each can have their drawbacks.
As for me and Microchipgrin, I think I would generally put normal simple bootloaders in the bootblock where it's guaranteed to be that which runs first.grin   Of course there are cases when 2 extra cycles just aren't allowable in which case I'd do something else.

Regards,

-Jesse

Edit & PS: * For all practical purposes, that is.grin
post edited by jesseg - 2007/03/08 20:31:19
#28
Olin Lathrop
Super Member
  • Total Posts : 7463
  • Reward points : 0
  • Joined: 2004/02/26 17:59:01
  • Location: Littleton Massachusetts
  • Status: offline
RE: Programming via Ethernet interface? 2007/03/09 15:19:54 (permalink)
0
in which case you'd simply be where you would have otherwise started out

Except that you spent more money and considerable lead time to get there.  Preprogrammed PICs is a nice service for the right projects, but these are the minority.  I've done close to 100 PIC projects, and I'm not sure any of them ended up getting preprogrammed PICs, maybe a couple at most.
#29
Datman
Starting Member
  • Total Posts : 74
  • Reward points : 0
  • Joined: 2006/01/25 16:46:45
  • Location: 0
  • Status: offline
RE: Programming via Ethernet interface? 2007/03/12 13:53:34 (permalink)
+1 (1)
would I easily achieve this setup with a PIC16F883. Or would i be better of using a micro with the dedicated boot block.. as far i can see the 883 is self programmable, but has no dedicated boot block?
#30
Olin Lathrop
Super Member
  • Total Posts : 7463
  • Reward points : 0
  • Joined: 2004/02/26 17:59:01
  • Location: Littleton Massachusetts
  • Status: offline
RE: Programming via Ethernet interface? 2007/03/12 14:43:03 (permalink)
0
would I easily achieve this setup with a PIC16F883.

What setup?
 
Or would i be better of using a micro with the dedicated boot block.. as far i can see the 883 is self programmable, but has no dedicated boot block?

As I said earlier, I have so far put bootloaders at the end of memory and have never used the boot block.  Don't worry about it if your chip doesn't have one.
#31
baby
Super Member
  • Total Posts : 184
  • Reward points : 0
  • Joined: 2018/07/16 22:33:00
  • Location: 0
  • Status: offline
Re: RE: Programming via Ethernet interface? 2018/08/30 23:20:55 (permalink)
-1 (1)
i am totally confused with ethernet programming in pic32mx795f512L. I can't understand the ethernet programs provide by micropchip library files. i am new one to ethernet programming. please give your guidance to develop myself in ethernet programming. 
 
 

want to be a perfect embedded developer..,
#32
David
Pic User
  • Total Posts : 1286
  • Reward points : 0
  • Joined: 2007/12/17 23:19:53
  • Location: uk sussex
  • Status: offline
Re: RE: Programming via Ethernet interface? 2018/08/31 01:20:48 (permalink)
+2 (2)
11 year old thread

David
I support http://picforum.ric323.com because this forum is often too broken to use!
#33
baby
Super Member
  • Total Posts : 184
  • Reward points : 0
  • Joined: 2018/07/16 22:33:00
  • Location: 0
  • Status: offline
Re: RE: Programming via Ethernet interface? 2018/09/02 21:44:02 (permalink)
0
 but in that forum i can't get  Ethernet communication with PIC32MX795F512L. pink: pink

want to be a perfect embedded developer..,
#34
Page: < 12 Showing page 2 of 2
Jump to:
© 2019 APG vNext Commercial Version 4.5