Searching \ for '[PIC] Community ed class' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Community ed class'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Community ed class'
2006\01\24@191335 by Mike Hord

picon face
I'm thinking about putting together a community ed
class for the spring "semester" here in Minneapolis,
and I'm wondering what everyone's thoughts are on
the most cost effective method is to get my students
set up with a programming/prototyping board that they
could make good use of would be.

My initial thought is something like Olin's Quickproto
and Easy prog, but at ~$140 per setup, it might shy
away a few people.

Other options would include something with a
bootloader, which would be good from a cost
standpoint (maybe $40 for a populated board and I
could program the PICs beforehand) or a cheaper
programmer (WISP628, perhaps).  A programmer is
the desirable outcome because I think the students
would get more long-term benefit from being able to
program a chip on their own after the class, but I
could just teach them the basics and leave it to them
to buy a programmer to take it to the next level on
their own.

Mike H.

PS- Tentative curriculum, by class session:
1.  Architecture sketch, instruction set, blink an LED.
2.  Peripherals, interrupts, blink an LED with interrupts,
respond to buttons and debouncing.
3.  LCDs, ADC, oscillator options.
4.  Serial communications.
5.  ???

I'm limited to 8 weeks, and fewer classes per week
makes it more likely that people will sign up for them.
More than 1.5 hours is likely to get boring; I may need
to stretch these classes out some to get things I want
done accomplished, but I'd really like the students at
the end of each class to walk away having made a PIC
do something.

2006\01\24@193020 by Chen Xiao Fan

face
flavicon
face


> -----Original Message-----
> From: spam_OUTpiclist-bouncesTakeThisOuTspammit.edu On Behalf Of Mike Hord
> Sent: Wednesday, January 25, 2006 8:14 AM
> To: Microcontroller discussion list - Public.
> Subject: [PIC] Community ed class
>
> I'm thinking about putting together a community ed
> class for the spring "semester" here in Minneapolis,
> and I'm wondering what everyone's thoughts are on
> the most cost effective method is to get my students
> set up with a programming/prototyping board that they
> could make good use of would be.
>

I think PICKit 1 is a good choice and it is very cheap
(programmer cum demo board at US$35). It only supports
PIC16F though. The unpopulated area can support RS232.

PICKit 2 (plus the Low Pin Count Demo) board (US$50)
is a good choice as well. It supports lots of PICs.
You do need to get the RS232 and LCD expansion
modules though from other sources.

ICD2 bundle with PICDEM2+ is good but it is too expensive.


Regards,
Xiaofan

2006\01\24@200021 by Mike Hord

picon face
> I think PICKit 1 is a good choice and it is very cheap
> (programmer cum demo board at US$35). It only supports
> PIC16F though. The unpopulated area can support RS232.
>
> PICKit 2 (plus the Low Pin Count Demo) board (US$50)
> is a good choice as well. It supports lots of PICs.
> You do need to get the RS232 and LCD expansion
> modules though from other sources.

Both of those look pretty good to me- especially the PICKit 1,
since it comes with a nice little demo board that I could wire up
ahead of time for RS-232 and LCD functionality.

> ICD2 bundle with PICDEM2+ is good but it is too expensive.

Agreed.  For some reason, uChip doesn't seem to be pushing
the PICKit as hard as the PICDEM series.  I didn't even see the
PICKit on the website.

Mike H.

2006\01\24@211926 by Chen Xiao Fan

face
flavicon
face


> -----Original Message-----
> From: .....piclist-bouncesKILLspamspam@spam@mit.edu
> [piclist-bouncesspamKILLspammit.edu] On Behalf Of Mike Hord
>
> > ICD2 bundle with PICDEM2+ is good but it is too expensive.
>
> Agreed.  For some reason, uChip doesn't seem to be pushing
> the PICKit as hard as the PICDEM series.  I didn't even see
> the PICKit on the website.
>

I think they are promoting the PICKit 2. PICkit 1 is a bit
old and there is no plan to update the firmware and
supported chips. Anyway I think PICkit 1 is still quite
good for new beginners. And the chip support of PICkit 1
is actually not so bad for PIC16F. It also supports
the base line PICs.

The following is a list of the officially supported chips.
PIC16F54/57/59/505/506
PIC12F508/509/510
PIC10F200/202/204/206/220/222

PIC12F629/675, PIC16F630/676
PIC16F716
PIC16F627A/628A/648A
PIC12F635, PIC16F636, PIC12F683/684/688
PIC16F785
PIC16F913, PIC16F914, PIC16F916, PIC16F917

The Microchip PICkit 1 V2.02 firmware should be able
to support the following PICs as well but this requires
the change of the source code (VB6) or to use Mark Rages'
Python based pyk. I think it should be able to support
some other PICs as well but not the popular 16F818/819
and 16F87/88. I think I will try this sometime later
with the PICkit 1.

PIC16F73/74/76
PIC16F737/747/767

PICKit 2 is of course better for new buyers. For those who
have the PICkit 1, there is no need to throw the PICkit 1.

I think it is possible to replace the PICKit 1 MCU (16F745)
with 18F2550 and the 6MHz oscillator with 20MHz and then
backport the PICkit 2 firmware to PICkit 1 as well. However
PICkit 2 is cheap so I think this hack is not worth the
time and money. Still it is a possible way to "upgrade" the
PICkit 1.

Regards,
Xiaofan

2006\01\24@220314 by Mark Rages

face picon face
On 1/24/06, Chen Xiao Fan <.....xiaofanKILLspamspam.....sg.pepperl-fuchs.com> wrote:
>
> I think it is possible to replace the PICKit 1 MCU (16F745)
> with 18F2550 and the 6MHz oscillator with 20MHz and then
> backport the PICkit 2 firmware to PICkit 1 as well. However
> PICkit 2 is cheap so I think this hack is not worth the
> time and money. Still it is a possible way to "upgrade" the
> PICkit 1.
>

Is the pinout the same between the 16F745 and the 18F2550?  I think I
looked into this once and concluded it would be easier to build a
PICkit 2 clone from scratch than to do this mod.

Regards,
Mark
markrages@gmail
--
You think that it is a secret, but it never has been one.
 - fortune cookie

2006\01\24@222614 by Chen Xiao Fan

face
flavicon
face

> From: EraseMEpiclist-bouncesspam_OUTspamTakeThisOuTmit.edu
> [piclist-bouncesspamspam_OUTmit.edu] On Behalf Of Mark Rages
>
> Is the pinout the same between the 16F745 and the 18F2550?  I think I
> looked into this once and concluded it would be easier to build a
> PICkit 2 clone from scratch than to do this mod.
>

The pinout is compatible but the firmware will be quite different.
PIC18F2550 has some more functions than 16C745 (there is no
16F745) though.

WH Tan has built a PICKit 1 clone with 18F2550 and I think he
has some good results. He has ported the boost converter
assembly code of 16C745 to 18F2550 and use the C18 based
USB framework for the USB. I think he is still working on it.

Actually I looked at PICkit 2 schematics before and my
conclusion is to _buy_ a PICKit 2 rather than building a
PICkit 2 clone. ;-)

Regards,
Xiaofan

2006\01\24@223140 by Russell McMahon

face
flavicon
face
> I'm thinking about putting together a community ed
> class for the spring "semester" here in Minneapolis,
> and I'm wondering what everyone's thoughts are on
> the most cost effective method is to get my students
> set up with a programming/prototyping board that they
> could make good use of would be.

If you are happy to stray from the fold then a close to zero cost
solution with vast utility can be achieved.

The most basic AVR programmers operate from a parallel port (for those
who remember what that is) and typically a 74HC244 IC and a few parts.
A typical circuit copyright Olimex 2002 can be found at
http://others.servebeer.com/temp/avrprog.jpg and, I imagine, on
Olimex's site. Google will tell you about many others. So far material
cost is scrap or under $10. Using a(n Olimex?) PCB may be a good idea
but the keen could do it on vero/vector/... board.

Power supply costs as little as you wish with all the usual tricks.

The AVR is now running.

Free essentially unknobbled BASIC (apart from a code size limit which
is reasonable) can be had from BASCOM.
Atmel's IDE is also free.

While compelling people to do hello world / blinking LED etc in
assembler, doing it in BASIC, feelings of horror notwithstanding, is
liable to get a lot more people going a lot quicker, he a lot more
done and interest more people. With BASIC you can progress from
blinking LED to Christmas Tree light controller (may The Lord have
mercy ...) in an evening.

Add up cables, power etc and you get: Programmer, BASIC, IDE, ... all
for, with a little care, maybe $20.

Maybe you can do the same with PIC, but the point is that people can
and do with AVRs.




       RM


_________________________

CONFIG    PortD = output

DO
   PortD = 255
   WAITMS 500
   PortD = 0
   WAITMS 500
LOOP

___________

Progressing from there to only flashing one pin is a pleasant (and
easy) experience. In fact so easy that you may decide to do that 1st
and avoid having to initially explain why 255 = 11111111 :-):

DO
   PortD.1 = 1
   WAITMS 500
   PortD.1 = 0
   WAITMS 500
LOOP

   R heresy M

2006\01\24@224256 by Shawn Wilton

picon face
Don't forget about the FREE GCC AVR C compiler.

(You never mention what previous level of knowledge, if any, you prefer your
students to have.)


On 1/24/06, Russell McMahon <@spam@apptechKILLspamspamparadise.net.nz> wrote:
{Quote hidden}

> -

2006\01\24@233538 by Chen Xiao Fan

face
flavicon
face

> -----Original Message-----
> From: KILLspampiclist-bouncesKILLspamspammit.edu
> [RemoveMEpiclist-bouncesTakeThisOuTspammit.edu] On Behalf Of Russell McMahon
>
> Add up cables, power etc and you get: Programmer, BASIC, IDE, ... all
> for, with a little care, maybe $20.
>
> Maybe you can do the same with PIC, but the point is that people can
> and do with AVRs.
>

I think AVR is a fine choice as well other than the fact that this is
a PIC list. ;-) For AVR, the parallel port based programmer
is quite cheap yet quite capable. AVR butterfly (with LCD) is also
quite cheap. AVR GCC is free and very good.

Still you can do the same thing for PIC. You can build a simple
parallel port based programmer, using Basic/Pascal/C from
Mikroelektronika (and they have free books as well) with only
code size limit (2kb). MPLAB is as free as AVR Studio. SDCC is free
and open source as well even it is not up to the standard of AVR GCC.

There is another route, the US$29 Silicon Labs C8051F064 demo
board has everything in as well (USB based power supply, programmer
cum debugger, powerful ADC), free IDE and code limit Keil C,
free SDCC (quite good for the 8051). People can do AVR and
people can do 8051 as well. ;-) Here the hardware debugger is
even bundled as well (JTAG)!

Regards,
Xiaofan

2006\01\25@005552 by Chen Xiao Fan

face
flavicon
face

> -----Original Message-----
> From: Chen Xiao Fan
> Sent: Wednesday, January 25, 2006 12:36 PM
>
> There is another route, the US$29 Silicon Labs C8051F064 demo
> board has everything in as well (USB based power supply, programmer
> cum debugger, powerful ADC), free IDE and code limit Keil C,
> free SDCC (quite good for the 8051). People can do AVR and
> people can do 8051 as well. ;-) Here the hardware debugger is
> even bundled as well (JTAG)!
>

And the specification for C8051F064 is really impressive.
25MIPS, 64KB Flash + 4k RAM, 2 x 16bit ADC and 2 USART.

I've played a bit with the demo kits and I think it is
quite good.

The development tools for C8051Fxxx is quite cheap.
The dedicated USB debugger /programmer is only US$50.
Still the chip may not be so cheap...

Regards,
Xiaofan

1. Kit Contents
C8051F064 Evaluation Kits contain the following items:
?? C8051F064 Evaluation Board
?? Silicon Laboratories Evaluation Kit IDE and Product
Information CD-ROM. CD content includes the following:
?? Silicon Laboratories Integrated Development Environment (IDE)
?? Keil Software 8051 Development Tools (evaluation assembler,
linker, and "C" compiler)
?? Source code examples and register definition files
?? Documentation
?? Evaluation Kit Demos, C8051F064 ADC Demo
?? USB Cable
?? C8051F064 Evaluation Kit User's Guide

2. Kit Overview

Figure 1 illustrates the block diagram of the C8051F064
Evaluation Kit. The board includes an analog front end to
signal condition and digitize (through the C8051F064) analog
input signals. The board also includes two USB ports
to transfer conversions to a PC: the DATA Port and the
Self-Demo/IDE Debug port. The DATA port consists of a
Silicon Laboratories CP2101 (UART to USB bridge) and a
USB connector. The Self-Demo/IDE Debug port
consists of Silicon Laboratories' debug interface hardware
and a USB connector.

Power for the C8051F064 board can be supplied from either
USB connection. An alternative lower noise supply
can be used for better measurement performance if desired.

3. Spec for C8051F064:

Analog Peripherals
- Two 16-Bit SAR ADCs
* 16-bit resolution
* ±0.75 LSB INL, guaranteed no missing codes
* Programmable throughput up to 1 Msps
* Operate as two single-ended or one differential converter
* Direct memory access; data stored in RAM without
software overhead
* Data-dependent windowed interrupt generator

- Three Analog Comparators
* Programmable hysteresis/response time
- Voltage Reference
- Precision VDD Monitor/Brown-Out Detector

On-Chip JTAG Debug & Boundary Scan
- On-chip debug circuitry facilitates full-speed, nonintrusive
in-circuit/in-system debugging
- Provides breakpoints, single-stepping, watchpoints,
stack monitor; inspect/modify memory and registers
- Superior performance to emulation systems using
ICE-chips, target pods, and sockets
- IEEE1149.1 compliant boundary scan
- Complete development kit

High Speed 8051 µC Core
- Pipelined instruction architecture; executes 70% of
instruction set in 1 or 2 system clocks
- Up to 25 MIPS throughput with 25 MHz clock
- Flexible Interrupt sources

Memory
- 4352 Bytes internal data RAM (4 k + 256)
- 64 kB Flash; In-system programmable in 512-byte sectors
- External 64 kB data memory interface with multiplexed
and non-multiplexed modes

Digital Peripherals
- 59 general purpose I/O pins
- Hardware SMBus(tm) (I2C(tm) Compatible), SPI(tm), and
two UART serial ports available concurrently
- Programmable 16-bit counter/timer array with
6 capture/compare modules
- 5 general purpose 16-bit counter/timers
- Dedicated watchdog timer; bi-directional reset pin

Clock Sources
- Internal calibrated precision oscillator: 24.5 MHz
- External oscillator: Crystal, RC, C, or clock

Supply Voltage .......................... 2.7 to 3.6 V
- Multiple power saving sleep and shutdown modes
64-Pin TQFP Packages
Temperature Range: -40 to +85 °C

2006\01\25@071605 by olin piclist

face picon face
Mike Hord wrote:
> My initial thought is something like Olin's Quickproto
> and Easy prog, but at ~$140 per setup, it might shy
> away a few people.

That's the single quantity price for a QuickProto-01 ($40) and a fully
assembled EasyProg ($100).  This would certainly not be the price for a
class.  Even for 3 at a time the QuickProto-01 price goes down to $33.

I'll be the first to admit the fully assembled version of the EasyProg is
not a good value.  I'm really interested in selling kits, but some people
asked for assembled units.  These are all built one-off by hand here in the
US, so there is no way to make them cheaply, but the volumes are so low it's
not worth getting them built elsewhere.  In fact I give the manufacturer the
same kits you buy and have them build up just 5 at a time.  If you don't
want students to have to build their tools first, I don't think I have a
good programmer solution for you at this time.  When will this course start?

You should also think about how the students are going to debug their code.
Do you want them to have a debugger, or are they going to test on the
simulator and wiggle pins for final hardware debugging?

My recommendation is each student gets a QuickProto-01, a 18F2520, and some
sort of programmer.  Maybe Wouter has something?  As I've said before, I'm
willing to give an educational discount if everything for a class is bought
at one time.  I do believe the QuickProto-01 at $33 is a good value, and I'm
thinking $30 each for a class of 10 or more, or something like that.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\01\25@080331 by Wouter van Ooijen

face picon face
> My recommendation is each student gets a QuickProto-01, a
> 18F2520, and some
> sort of programmer.  Maybe Wouter has something?

I have plenty, either available or as vapourware in my head :)

But I missed the start of this discussion, so maybe I am asking for what
was already said, but: what are the course objectives?

I have one course for 2nd year informatics students, who are not
expected to do much electronics, and I want them to be able to do work
at home. So they buy a one-PCB thing that contains both a programmer
(connect USB and you are on the move) and the target and some
peripherals, and the lessons and assignments are matched to the
peripherals on the PCB. Some students connect external peripherals
anyway, but that is for extra points.

For 3d year electronics students, who are expected to work in small
groups and create quite some additional circuitry and use all kinds of
tools (o-scopes etc) that are available only at the school it makes no
sense to provide an all-in-one PCB or to make it possible to work at
home. For them we have [ one ICD2 and a few cheaper programmers ] per
group.

I can imagine lots of inbetween situations (my dwarf boards might fit
some of these cases, or an ICSP programmer + a solderless breadboard, or
...). Or more extreme: maybe you can do with just the MPLAB simulator,
no hardware at all. I often do this for the first assignment of my
course. Or maybe your students have to dig in real deep and need an
expensive in-circuit emulator and a fast logic analyzer.

So you must first define your course objectives!

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\01\25@083022 by olin piclist

face picon face
Wouter van Ooijen wrote:
> I have plenty, either available or as vapourware in my head :)

If he wants vaporware, I've got plenty of that too.  And mine costs less,
does more, is smaller, more environmentally friendly, takes less power, and
looks nicer than yours! (*)





* Specs subject to change without notice until product actually offered for
sale.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\01\25@083620 by Andrew Kieran

picon face

Have you considered giving each student a breadboard and a PIC
with a Bootloader?  Each student would need only a few
components.

The PIC of your choice
resonator
MCLR resistor
reset switch
wire

You could use an in-line level converter
(http://www.piclist.com/techref/io/serial/RCL1.htm) or save a
little money by including a Max232, capacitors, and cable and
have them add it to their breadboard.

Of course you would need a programmer to load the Bootloader,
but this is only done once so you can use your existing
programmer.

With this setup, the students could be given a handful of
additional parts for each lab. E.g. LEDs, switches, 7 segment
displays, LCDs, etc.  As an added benefit, the RS-232 connection
can be used to output debug information to the attached PC for
display in HyperTerminal.

Andrew


________________________________________________
Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag

2006\01\25@084830 by Xiaofan Chen

face picon face
On 1/25/06, Olin Lathrop <spamBeGoneolin_piclistspamBeGonespamembedinc.com> wrote:
> Wouter van Ooijen wrote:
> > I have plenty, either available or as vapourware in my head :)
>
> If he wants vaporware, I've got plenty of that too.  And mine costs less,
> does more, is smaller, more environmentally friendly, takes less power, and
> looks nicer than yours! (*)
>

I guess that 18F2550 based Wisp2550 programmer (as well as the
Wisp648) and PICkit 2 clones are some of the "vapourware" from Wouter. ;-)

And 18F2550 USB based EasyProg cum ICD2 killer are the "vaporware"
(noticed the different spelling) from Olin. ;-)

Hopefully these vaporwares will soon be reality. ;-)

And I guess the OP would not want some vaporware but rather something
tangible and PICkit 1 is quite a good choice.

Regards,
Xiaofan

2006\01\25@085109 by Xiaofan Chen

face picon face
On 1/25/06, Andrew Kieran <TakeThisOuTakieranEraseMEspamspam_OUTureach.com> wrote:
>
> Have you considered giving each student a breadboard and a PIC
> with a Bootloader?  Each student would need only a few
> components.
>

In my opinion it is not a good choice to use a bootloader for
beginners. Then theny need to change the linker scripts or
the source code to suit the bootloader. And they do not have
a real programmer for later use.

Regards,
Xiaofan

2006\01\25@085122 by Michael Rigby-Jones

picon face


>-----Original Message-----
>From: RemoveMEpiclist-bouncesspamTakeThisOuTmit.edu [piclist-bouncesEraseMEspam.....mit.edu]
>Sent: 25 January 2006 13:36
>To: EraseMEpiclistspammit.edu
>Subject: Re: [PIC] Community ed class
>
>
>
>Have you considered giving each student a breadboard and a PIC
>with a Bootloader?  Each student would need only a few components.


Breadboards are evil things IMO, especialy in the hands of students who don't think twice about poking big bits of copper wire into the holes, thus ensuring that any IC using the same hole will likely have an intermittant contact.

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.
=======================================================================

2006\01\25@095303 by Wouter van Ooijen

face picon face
> Have you considered giving each student a breadboard and a PIC
> with a Bootloader?  Each student would need only a few
> components.

You must also consider powering. A serial bootloader would require a
separate power (wall wart) or an extra cable to steal USB power. An
usb-to-serial converter (FT232) could be used, but that would be an
extra chip. And bootloader can be overwritten by a clever programmer
(remember, these are students!). The current setup uses a pickit1 clone
circuit, powered from the USB and supported by uChips software. Next
year I'll probably switch to a pickit2 clone.

> With this setup, the students could be given a handful of
> additional parts for each lab. E.g. LEDs, switches, 7 segment
> displays, LCDs, etc.

For certain course objectives that would be a good idea. But remember,
these are informatics students, not electronics. I wanted something they
could take home, which favours an all-in-1 PCB.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\01\25@103110 by David VanHorn

picon face
>
>
> If you are happy to stray from the fold then a close to zero cost
> solution with vast utility can be achieved.


Thanks Russel, :)  Us heretics need to stick together!

The most basic AVR programmers operate from a parallel port (for those
> who remember what that is) and typically a 74HC244 IC and a few parts.


The BA1FB programmer just used resistors. I don't think he's updated it for
the later devices, but it works nicely on the smaller chips, like the 2343
which IMHO is a nice introductory chip, having ram, rom, timer, and a few
I/O, and the 8 pin "one chip wonder" applications are pretty nice.


>
> Maybe you can do the same with PIC, but the point is that people can and
> do with AVRs.


I did an LED blinky on the 2343.  I always said I wouldn't ever do that, but
actually it was to drive two lasers on a sattelite in different morse code
blink patterns concurrently (cooperative multitasker) so I thought it had
sufficient 'cool factor' to outweigh the rest.


If one wanted to, one could adapt my "fuser" (on the T11 group) to a larger
AVR, and turn that into a chip programmer easily enough.
Add serial support, and follow the standard AVRISP protocol.

Just remember to ALWAYS program the CKOPT fuse unless you KNOW that you know
better.

2006\01\25@112129 by Mike Hord

picon face
Wow.  Lots to comment on!

First, the AVR concept.  In order to do this, I'll
need to get my act together and learn to use
relocatable code, either that or just start them
out on an HLL (I was thinking JAL).  If I use an
AVR, I'd have to learn more about that, too,
and for right now I'd rather not.  A fair idea,
though, and I really should work on adding the
AVR to my bag o' tricks.

Course should start in a few months, if I do it
at all.  I'm just trying to put together a broad
feasibility image for myself so when I go talk
to the people organizing the courses I can
have a better idea of what I'm looking at.  I
don't see many courses now that would give
their students the kind of stuff this would
entail, but the woodcarving class is $68, and
the Japanese language course I'm taking is
$50.  That kind of puts the squeeze on the
budget- obviously, the program gets a cut,
and then some rolls over to me, the teacher,
I think.

Actually, I think the best way to go would be
buying each student a PICKit2 low pin count
demo board for $24, and then building them
a Wisp628 on perfboard.  I should be able to
put together a Wisp628 for not much more
than $10-$15, if I'm buying bits 10 at a time.

I agree with the assessment that breadboards
and bootloaders are inappropriate for this venue.
Breadboards are pricey and can add a very
frustrating element to troubleshooting for a novice.
Bootloaders can be overwritten, require some
fancy footwork in coding (or at least, fancier than
the simplest blink-an-led code), and don't get
the student anywhere after the class is done, if
they decide they'd like to pursue more projects
on their own.

This class is aimed at getting the low-key
electronics hobbiest started using PICs.  I
suspect many of the attendees will be older men,
since the younger kids picked up these skills in
college.  There will probably be some younger
ones, too.

I'm also thinking about a general electronics primer-
voltage, current, power, basic circuit elements,
diodes, BJTs, maybe FETs, op-amps, timers, and
logic gates.  And a class on wireless networking for
the home.  I can't believe that no one is teaching
these classes.

Mike H.

2006\01\25@115923 by Harold Hallikainen

face picon face
This is an interesting discussion. I've been thinking of approaching the
local electronic parts retailer (we still have one!) about possibly doing
a PIC class in their store. It would draw people to their store (I hope)
who would buy the parts for the projects there.

Harold

--
FCC Rules Updated Daily at http://www.hallikainen.com

2006\01\25@121204 by David VanHorn

picon face
On 1/25/06, Mike Hord <RemoveMEmike.hordEraseMEspamEraseMEgmail.com> wrote:
>
> Wow.  Lots to comment on!
>
> First, the AVR concept.  In order to do this, I'll
> need to get my act together and learn to use
> relocatable code, either that or just start them
> out on an HLL



I'm wondering why you say that.
I've been writing AVR code for a long time.  There's nothing special about
relocating code, since we don't have "pages" and "banks" and holes in the
memory map. Tables can be any length, and located anywhere.

You can of course specifically put code at an address, if you want to, but
you NEVER have to, other than the ISR vectors of course. Vectored interrupts
require fixed addresses for the jump table.

2006\01\25@124735 by Jan-Erik Soderholm

face picon face
Mike Hord wrote :

> ...and then building them
> a Wisp628 on perfboard.  I should be able to
> put together a Wisp628 for not much more
> than $10-$15, if I'm buying bits 10 at a time...

May I also sugest that you ask Wouter what he asks
for, let's say, 10-20 Wisp628's in "bulk". That is,
all material but not packed into separate kits.

I buy my Wisp628's a sell in Sweden that way (sold
50 during Q3-Q4/05, and 6-7 so far this year). You'll
probably get another price per unit then the 1 unit
list price on his web page...

It's so much easier to build it on a real PCB then on
perfboard, and the end result is much nicer too, IMHO.

Jan-Erik.



2006\01\25@135139 by Byron A Jeff

face picon face
On Tue, Jan 24, 2006 at 07:42:56PM -0800, Shawn Wilton wrote:
> Don't forget about the FREE GCC AVR C compiler.
>
> (You never mention what previous level of knowledge, if any, you prefer your
> students to have.)
>
>
> On 1/24/06, Russell McMahon <RemoveMEapptechspam_OUTspamKILLspamparadise.net.nz> wrote:
> >
> > > I'm thinking about putting together a community ed
> > > class for the spring "semester" here in Minneapolis,
> > > and I'm wondering what everyone's thoughts are on
> > > the most cost effective method is to get my students
> > > set up with a programming/prototyping board that they
> > > could make good use of would be.
> >
> > If you are happy to stray from the fold then a close to zero cost
> > solution with vast utility can be achieved.

There's actually no need to stray from the PIC world in order to gain
this utility.

> >
> > The most basic AVR programmers operate from a parallel port (for those
> > who remember what that is) and typically a 74HC244 IC and a few parts.

Same for the PIC if an low voltage configuration is used. Even for high voltage
it's only a smidge more.

> > A typical circuit copyright Olimex 2002 can be found at
> > http://others.servebeer.com/temp/avrprog.jpg and, I imagine, on
> > Olimex's site.

My Trivial Low Voltage Programmer is about the same:

http://www.finitesite.com/d3jsys

I use a 74HCT573 for level shifting and because I like the part's pinout.

The page also points to the high voltage and ICSP capable versions.

One of my users finally solved the long cable issue. He found that grounding
the shield through a small value cap allows for cables over 10 feet to work
perfectly.

> Google will tell you about many others. So far material
> > cost is scrap or under $10. Using a(n Olimex?) PCB may be a good idea
> > but the keen could do it on vero/vector/... board.

Agreed. In fact even a breadboard can work for such a simple configuration.

Your bootloader idea I find to be a good one two. The one two punch of a
simple programmer plus a bootloader can simplify development issues for
novice and intermediate users.

> > Power supply costs as little as you wish with all the usual tricks.

I generally pull power from the PC. While shorting issues are possible, it's
cheap and effective.

{Quote hidden}

For pics JAL may also be a possibility.

> >
> > Add up cables, power etc and you get: Programmer, BASIC, IDE, ... all
> > for, with a little care, maybe $20.
> >
> > Maybe you can do the same with PIC, but the point is that people can
> > and do with AVRs.

Both are capable platforms.

BAJ

2006\01\25@140341 by Byron A Jeff

face picon face
On Wed, Jan 25, 2006 at 10:21:28AM -0600, Mike Hord wrote:
> Wow.  Lots to comment on!

So I'm going to snip some.

> Actually, I think the best way to go would be
> buying each student a PICKit2 low pin count
> demo board for $24, and then building them
> a Wisp628 on perfboard.  I should be able to
> put together a Wisp628 for not much more
> than $10-$15, if I'm buying bits 10 at a time.

I disagree. For some reason I seem to be one of the few folks
on the list who doesn't think that the development environment
is too particularly important.

> I agree with the assessment that breadboards
> and bootloaders are inappropriate for this venue.


> Breadboards are pricey and can add a very
> frustrating element to troubleshooting for a novice.

While they are certainly not a good target for permanent projects,
breadboards are a quick and effective way to get started without
having to spend a lot of time in the process of assembling hardware.
Soldering is an acquired skill. Soldering mistakes are rampant.

Truthfully I'm still a wire wrap guy for that reason. I have boards
that have been in operations from 5-10 years that I've wirewrapped.

> Bootloaders can be overwritten,

True. On the other hand you have control on exactly what features
it presents.

> require some
> fancy footwork in coding (or at least, fancier than
> the simplest blink-an-led code),

That's a design choice. Bootloaders like Wouter's WLoader is
virtually transparent to the target code. The only hoop is the
memory that the bootloader occupies. WLoader also protects itself
from being overwritten. And the single pin serial interface imposes
a minimal I/O budget.

An appropriate bootloader can be picked or engineered for the class.

> and don't get the student anywhere after the class is done, if
> they decide they'd like to pursue more projects
> on their own.

Why? While I agree that it may limit chip choices to those that
can be bootloaded, and that you need an initial bootstrap for a blank
chip, what other issues are there?

More later, I've got to run.

BAJ

2006\01\25@145810 by Wouter van Ooijen

face picon face
> This class is aimed at getting the low-key
> electronics hobbiest started using PICs.  I
> suspect many of the attendees will be older men,
> since the younger kids picked up these skills in
> college.  There will probably be some younger
> ones, too.

For a first-bit-of-PICs group you could consider using a bootloader. If
you port my ZPL over to a smaller 16F you can have a very cheap target
circuit. IMHO starting with a bootloader makes sense if (both)
- you must/want to buy the hardware
- there is a real chance that after this you will not continue using
PICs

So I ask again: what is your adience, aim, etc? You should reason from
there, not from a hardware choice.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\01\25@145810 by Wouter van Ooijen

face picon face
> That's a design choice. Bootloaders like Wouter's WLoader is
> virtually transparent to the target code. The only hoop is the
> memory that the bootloader occupies. WLoader also protects itself
> from being overwritten. And the single pin serial interface imposes
> a minimal I/O budget.

Note that WLoader and ZPL protect themselves from being overwritten by
the bootloading, but not from being overwritten by the running
application code itself! It is possible to achieve that (on PICs that
have memory sections that can be write-protected individually), but I
see no way to combine that with transparency.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\01\25@154459 by Mike Hord

picon face
> So I ask again: what is your adience, aim, etc? You should reason from
> there, not from a hardware choice.

Audience is whoever takes the class.  ;-)

I'll probably target it at people who are quite comfortable with electronics:
they know how to wire up a 555, maybe have done a few little projects
out of a Radio Shack project book, and have a reasonable idea of what
current, voltage, and wattage imply.  Maybe they've written a few odd
programs for their PC.

I'd like to introduce them to simple wait state loops first, then timers,
then maybe LCD driving, ADC, and maybe even serial port to the PC.

At the end of the class, I'd like them to feel comfortable ordering a PIC
or two from Digikey with a plan for it, and to have the toolkit necessary
to work with it.

Mike H.

2006\01\25@161348 by Chetan Bhargava

picon face
You can also use PICAXE. You get the functionality of a bootloader,
chip is not that expensive, use HLL (BASIC), nice tutorials on the
website!
http://www.rev-ed.co.uk/picaxe/

PH Anderson sells these chips.

my 2 cents.


On 1/25/06, Mike Hord <RemoveMEmike.hordTakeThisOuTspamspamgmail.com> wrote:
{Quote hidden}

--
Chetan Bhargava
Web: http://www.bhargavaz.net
Blog: http://microz.blogspot.com

2006\01\25@162121 by Chetan Bhargava

picon face
Overview of the PICAXE - The Tinkerers' Delight
http://www.phanderson.com/picaxe/picaxe_overview.html

His website also has lots of PICAXE apps.

--
Chetan Bhargava
Web: http://www.bhargavaz.net
Blog: http://microz.blogspot.com

2006\01\26@021426 by Wouter van Ooijen

face picon face
> > So I ask again: what is your adience, aim, etc? You should
> reason from
> > there, not from a hardware choice.
>
> Audience is whoever takes the class.  ;-)

No, it's not that easy. If you realy want to have a class for bot 8y old
illiteratates *and* retired electronics professors you are into an
interesting challenge.

> I'll probably target it at people who are quite comfortable
> with electronics:
> they know how to wire up a 555, maybe have done a few little projects
> out of a Radio Shack project book, and have a reasonable idea of what
> current, voltage, and wattage imply.  Maybe they've written a few odd
> programs for their PC.

That last part is more of a problem than the electronics knowledge: you
can teach (some) PIC programming to someone who knows nothing about
leectronics, but someone who knows no programming will be a problem. If
you realy want to target someone like that you will be very restricted
in your choice of languages. A feature-rich BASIC might be your only
option.

> I'd like to introduce them to simple wait state loops first,
> then timers,
> then maybe LCD driving, ADC, and maybe even serial port to the PC.

Sounds too much for people with no programming experience.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\01\26@043000 by Alan B. Pearce

face picon face
>> Bootloaders can be overwritten,
>
>True. On the other hand you have control on
>exactly what features it presents.

Also overwriting the bootloader, and having to take the chip over to the one
programmer that is in the class to repair the bootloader, may make them
think more about some of the constraints, especially if the bootloader
overwrite was done by running code.

It also causes them to consider what needs to be done to boot the chip up in
the first place - i.e. the equivalent of the BIOS in a PC. It is not
something that magically happens.

2006\01\26@053240 by Peter Todd

picon face
On Thu, Jan 26, 2006 at 09:29:55AM -0000, Alan B. Pearce wrote:
> >> Bootloaders can be overwritten,
> >
> >True. On the other hand you have control on
> >exactly what features it presents.
>
> Also overwriting the bootloader, and having to take the chip over to the one
> programmer that is in the class to repair the bootloader, may make them
> think more about some of the constraints, especially if the bootloader
> overwrite was done by running code.
>
> It also causes them to consider what needs to be done to boot the chip up in
> the first place - i.e. the equivalent of the BIOS in a PC. It is not
> something that magically happens.

Maybe I'm missing the point of this email... But you do know that PICs
have very effective code-protect features to make it impossible to
accidentally overwrite bootloaders? I've got a project I built right
next to me with 64 pic chips using bootloaders, and I tested the code
protection on every last one of them as part of my acceptance test
before assembled the boards in the main unit.


With regard to the rest of this thread... I go to an arts school, the
ontario collage of art and design. There we have electronics courses,
that I'm in, and everything involving microprocessors gets taught using
Basic Stamps. The teaching doesn't even begin to approach formal,
basically the profs let you do whatever the hell you want, (people have
been known to do *paintings* of electronics, and pass!) and the student
body are almost all from non-technical backgrounds. That said I see a
lot of people doing decent work with the stamps. It's all simple
sensor/action loops, like reading ADC's and doing PWM control of motors
based on simple arithmetic. But I think that's an appropriate kind of
start really, and these decidely non-technical people pick it up just
fine without much encouragment.

The biggest downside I see, is the damn things cost so much when you
accidentally blow one up. $30 each adds up, and that's for the cheap
rip-off versions.

--
EraseMEpetespamspamspamBeGonepetertodd.ca http://www.petertodd.ca

2006\01\26@061107 by Alan B. Pearce

face picon face
>Maybe I'm missing the point of this email... But you do
>know that PICs have very effective code-protect features
>to make it impossible to accidentally overwrite bootloaders?

Yeah, sure. I do appreciate that, and do wonder why the original person
didn't take that into account.

However sometimes the easiest way to teach people about some of these
protection features is to show them what can happen when they get it wrong -
the reason for checking then gets burnt in ;)))

2006\01\26@065136 by Wouter van Ooijen

face picon face
>>Maybe I'm missing the point of this email... But you do
>>know that PICs have very effective code-protect features
>>to make it impossible to accidentally overwrite bootloaders?
>
> Yeah, sure. I do appreciate that, and do wonder why the
> original person
> didn't take that into account.

As I see it you can choose:

- You can make a bootloader that is realy protected, but in that case
the application program must be aware that it will be run with the
bootloader, or

- You can make a bootloader that is (almost) transparent (that is: the
same application can run with the bootloader or with a bare chip), but
in that case you can't fully protect the bootloader from a malicious
application.

If I am wrong please show me how to combine the best of both worlds!

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\01\26@085057 by Gerhard Fiedler

picon face
David VanHorn wrote:

> On 1/25/06, Mike Hord wrote:
>>
>> First, the AVR concept.  In order to do this, I'll need to get my act
>> together and learn to use relocatable code, either that or just start
>> them out on an HLL
>
> I'm wondering why you say that.
> I've been writing AVR code for a long time.  There's nothing special about
> relocating code, [...]

I read that differently... Mike didn't seem to mean that he'd have to learn
about relocatable code specifically for the AVR, but that he'd have to do
it for the course. Then he continued that

>> If I use an AVR, I'd have to learn more about that, too, and for right
>> now I'd rather not.

So it's just that the AVR adds yet another thing to learn for the course --
if you're not already familiar with it.

Gerhard

2006\01\26@085958 by Gerhard Fiedler

picon face
Wouter van Ooijen wrote:

> As I see it you can choose:
>
> - You can make a bootloader that is realy protected, but in that case
> the application program must be aware that it will be run with the
> bootloader, or
>
> - You can make a bootloader that is (almost) transparent (that is: the
> same application can run with the bootloader or with a bare chip), but
> in that case you can't fully protect the bootloader from a malicious
> application.
>
> If I am wrong please show me how to combine the best of both worlds!

I'm not familiar with bootloaders on PICs. When I think about a transparent
bootloader, it seems to me that it has to sit at the top of the available
program memory and take control of the reset vector. So you'd make the top
page of the program memory read-only and re-route the program's reset
vector through the bootloader. In principle, the reset vector location
would be writable to the program, which means that it could take the
bootloader out of the loop by rewriting the boot vector.

If you don't write-protect the configuration registers, you could
write-protect the boot block in the bootloader after writing the
application code. Which would make it a two-step process for a "bad"
application to take the bootloader out: it would have to change the write
protection for the boot block in the configuration register, then take over
the boot vector by writing to it. Maybe that's good enough... at least good
enough against accidentally taking over?


Probably the only safe way is to put the bootloader in the boot block and
to write protect both the boot block and the configuration registers. But
this requires that the application is linked to start at an address above
the bootloader. (If there wasn't the issue with code pages, this would look
different :)


Is this what you meant?

Gerhard

2006\01\26@093846 by Sergey Dryga

face picon face
Mike Hord <mike.hord <at> gmail.com> writes:

{Quote hidden}

Mike, I would suggest setup from beaglerobotics.com, it has an expandable
protoboard and easy to use.
For example, setup with:
  PIC module (ICSP connector, crystal and other circuits necessary)
  Power supply (5V, 1A)
  Breadboard space
  LCD/4 button adapter
  40x2 LCD
will meet your requirements and will cost $69.80 (list price), but with
quantity/educational discount it will be $55.  There is an option to buy PIC
preprogrammed with any bootloader you want.

Looks like this setup will be sufficient for what you want to do with your
class and people can expand on it later if they want to.

You can contact me off-list if you would like to get a free sample to see how
it works for you.

Sergey Dryga
beaglerobotics.com






2006\01\26@094040 by Wouter van Ooijen

face picon face
> I'm not familiar with bootloaders on PICs. When I think about
> a transparent
> bootloader, it seems to me that it has to sit at the top of
> the available
> program memory and take control of the reset vector.

correct

> So you'd make the top
> page of the program memory read-only and re-route the program's reset
> vector through the bootloader.

correct

> In principle, the reset vector location
> would be writable to the program, which means that it could take the
> bootloader out of the loop by rewriting the boot vector.

correct

> If you don't write-protect the configuration registers

the relevant config bits can not be written by a PIC program

> you could
> write-protect the boot block in the bootloader after writing the
> application code.

can't do that: see above

Which would make it a two-step process for a "bad"

> Probably the only safe way is to put the bootloader in the
> boot block and to write protect both the boot block

That can be done, but I don't see a way to make that transparent to the
application program.

> But
> this requires that the application is linked to start at an
> address above
> the bootloader.

correct

>(If there wasn't the issue with code pages,
> this would look different :)

no, its would still be a problem unless all code references were
PC-relative.

> Is this what you meant?

It does not show how to combine robustness and transparency, if that is
the question you were trying to answer.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\01\26@100427 by olin piclist

face picon face
Gerhard Fiedler wrote:
> If you don't write-protect the configuration registers, you could
> write-protect the boot block in the bootloader after writing the
> application code. Which would make it a two-step process for a "bad"
> application to take the bootloader out: it would have to change the
> write protection for the boot block in the configuration register, then
> take over the boot vector by writing to it. Maybe that's good enough...
> at least good enough against accidentally taking over?
>
> Probably the only safe way is to put the bootloader in the boot block
> and to write protect both the boot block and the configuration
> registers. But this requires that the application is linked to start at
> an address above the bootloader. (If there wasn't the issue with code
> pages, this would look different :)

I think you are making this way to complicated.  In practise I've never seen
an application accidentally write over a bootloader on a PIC.  It can
theoretically happen, and probably has, but it is very rare.  How many
TBLWRT instructions does your app have?  Unless it's a bootloader, probably
none.  A few apps may modify an occasional table based on calibration data
or whatever, but this is a small minority of apps.  A buggy app could start
executing data as instructions, which could in theory write to program
memory, but this requires a very unusual alignment of quite a few stars.
The worst danger is from a buggy app that contains deliberate code for
writing to program memory.  This is not something a beginner would be doing.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\01\26@101606 by olin piclist

face picon face
Wouter van Ooijen wrote:
>> But
>> this requires that the application is linked to start at an
>> address above
>> the bootloader.
>
> correct

There are other restriction tradeoffs.  For example, the app could assume
execution starts at the reset vector with the restriction that the block of
code at 0-3 is relocatable and not contiguous with following code.  In
practise this means you can't have any entry points there.  This would allow
the boot loader and host program combination to move the instructions at 0-3
into a special area owned by the bootloader.  Then bootloader runs this code
to start the app.

Such a bootloader would have only two restrictions on the app that I can
think of, neither of which are difficult to deal with.

1 - No entry points at locations 0-3.  This is easy to guarantee by putting
explicit code there to fill all 4 locations.  That prevents the linker from
putting a subroutine there in case it might fit.  Making 0-3 a separate
linker section guarantees the code there won't be contiguous with the
following code (usually not the case since that's where the interrupt
routine goes anyway).

2 - The bootloader program memory is off limits.  This is easily done
removing the bootloader memory from the linker script or declaring it
protected.

This is a theoretical argument only.  My bootloaders don't work this way
since a fixed starting address or leaving the starting address in a known
place is not a big deal (I've done it both ways).


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\01\26@104333 by William Chops Westfield

face picon face

On Jan 25, 2006, at 11:16 PM, Wouter van Ooijen wrote:

>> Audience is whoever takes the class.  ;-)
>
> No, it's not that easy. If you realy want to have a class for bot
> 8y old illiteratates *and* retired electronics professors you are
> into an interesting challenge.

Welcome to "community education."  For those outside the US, this
comprises classes offered to the community at large: no prior
requirements, minimal facilities, and an audience that really
is as varied as Mike suggests...

BillW

2006\01\26@105233 by Wouter van Ooijen

face picon face
> I think you are making this way to complicated.  In practise
> I've never seen an application accidentally write over a
> bootloader on a PIC.

I would probably agree for a profesdsional environment. But do you have
experience with classes of students exploring all the strange corners of
this new chip they have in their hands?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\01\26@105233 by Wouter van Ooijen

face picon face
> > correct
>
> There are other restriction tradeoffs.  For example, the app
> could assume execution starts at the reset vector with the
> restriction that the block of code at 0-3 is relocatable and
> not contiguous with following code.
>
> This is a theoretical argument only.  My bootloaders don't
> work this way
> since a fixed starting address or leaving the starting
> address in a known
> place is not a big deal (I've done it both ways).

Two of bootloaders (WLoader and ZPL) do work this way. The weak point is
that you can't write-protect *only* locations 0..3.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2006\01\26@111655 by Alan B. Pearce

face picon face
>Two of bootloaders (WLoader and ZPL) do work this way. The
>weak point is that you can't write-protect *only* locations 0..3.

However surely the bootloader could detect that a write to those locations
is being attempted and instead put the data in the bootloader area reserved
for this code ?

2006\01\26@112823 by Wouter van Ooijen

face picon face
> >> Audience is whoever takes the class.  ;-)
> >
> > No, it's not that easy. If you realy want to have a class for bot
> > 8y old illiteratates *and* retired electronics professors you are
> > into an interesting challenge.
>
> Welcome to "community education."  For those outside the US, this
> comprises classes offered to the community at large: no prior
> requirements, minimal facilities, and an audience that really
> is as varied as Mike suggests...

You'd be surprised what I get in a 2nd year university C class :( :(

But it doesn't change what I said: you can't offer the same to both 8y
old illiterates and retired electronics professors. The one who defines
the course has to make decisions.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\01\26@115026 by Wouter van Ooijen

face picon face
>>Two of bootloaders (WLoader and ZPL) do work this way. The
>>weak point is that you can't write-protect *only* locations 0..3.
>
> However surely the bootloader could detect that a write to
> those locations
> is being attempted and instead put the data in the bootloader
> area reserved for this code ?

Yes, of course the bootloader protects itself in this way, but that does
not protect it from the application program executing a write to those
locations.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2006\01\26@122854 by olin piclist

face picon face
William Chops Westfield wrote:
> Welcome to "community education."  For those outside the US, this
> comprises classes offered to the community at large: no prior
> requirements, minimal facilities, and an audience that really
> is as varied as Mike suggests...

While anyone may attend for paying the fee, there is still a published
description so that attendees can tell whether the course is the right level
for them.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\01\26@122950 by olin piclist

face picon face
Wouter van Ooijen wrote:
> I would probably agree for a profesdsional environment. But do you have
> experience with classes of students exploring all the strange corners of
> this new chip they have in their hands?

No, but I imagine you do.  Have you ever seen this happen?

******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\01\26@130502 by Wouter van Ooijen

face picon face
> > I would probably agree for a profesdsional environment. But
> do you have
> > experience with classes of students exploring all the
> strange corners of
> > this new chip they have in their hands?
>
> No, but I imagine you do.  Have you ever seen this happen?

I have not exposed my students to a vulnerable bootloader, but I have
had all sorts of bootloader trouble with ZPL chips sold and used by
mainly (beginner) robotics enthusiasts. I suspect that at least part of
these troubles are because of power supply effects (overvoltage,
undervoltage, spikes, etc, those robot guys can create a lot of
trouble), but I think some were due to writes by the application.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\01\26@153659 by Gerhard Fiedler

picon face
Wouter van Ooijen wrote:

>> But this requires that the application is linked to start at an address
>> above the bootloader.
>
> correct
>
>> (If there wasn't the issue with code pages, this would look different :)
>
> no, its would still be a problem unless all code references were
> PC-relative.

In an architecture without code page instructions, it may be possible for
the bootloader without too much effort to relocate the code by adding
offsets to all absolute jumps.

>> Is this what you meant?
>
> It does not show how to combine robustness and transparency, if that is
> the question you were trying to answer.

What I meant was whether I got the restrictions right. I've never thought
about this, and your question made me think, and while thinking I already
had it written down -- so I wanted to know whether it's the same problems
you see.

Summary:
- To prevent taking over the boot vector, the boot block needs to be
read-only for the running application. Which means it's read-only for the
bootloader, too.
- This means that the application has to be written to leave the boot block
alone, which requires that the application is aware of the bootloader,
avoids the boot block memory range and uses an entry point as defined by
the bootloader.
- Possibly, just very possibly, the bootloader could change application
code linked for address 0 to start at a different address by
adding/modifying the appropriate code page and jump instructions. This
would probably be easiest if the new starting point were at the next page
boundary. It might be easier on the 18F devices, but then care must be
taken in any case with table read instructions. Maybe not such a good idea
after all... :)

Gerhard

2006\01\26@154116 by Gerhard Fiedler

picon face
Olin Lathrop wrote:

> I think you are making this way to complicated.  

I tend to agree with you, but I took this as some kind of thought
experiment -- is it possible to make a secure /and/ transparent bootloader?

After all, if it is, this would probably be something somebody would be
interested in :)

Gerhard

2006\01\26@155521 by Bob Axtell

face picon face
Gerhard Fiedler wrote:

>Olin Lathrop wrote:
>
>  
>
>>I think you are making this way to complicated.  
>>    
>>
>
>I tend to agree with you, but I took this as some kind of thought
>experiment -- is it possible to make a secure /and/ transparent bootloader?
>
>  
>
There is a way for some PIC16s.

But I am having car trouble now, I'll discuss this later tonight.

>After all, if it is, this would probably be something somebody would be
>interested in :)
>
>Gerhard
>
>  
>
--Bob

--
Note: To protect our network,
attachments must be sent to
RemoveMEattachKILLspamspamengineer.cotse.net .
1-520-850-1673 USA/Canada
http://beam.to/azengineer

2006\01\26@171728 by Wouter van Ooijen

face picon face
> In an architecture without code page instructions, it may be
> possible for
> the bootloader without too much effort to relocate the code by adding
> offsets to all absolute jumps.

But how is it to know whether a bit pattern is a jump instruction or
rom-stored fixed data?

> - Possibly, just very possibly (snip)
> Maybe not such a good idea after all... :)

Even relocating the first 2 or 3 or 4 instructions is tricky and not
always possible.

A minor problem with relocating only those instructions: where do you
put them? Not in a place that the application sees as its property, it
must be at the start of a memory page (2k for 14-bit cores). If it is
inside the booloader's memory that requires that memory to be writeable.
If it is in a block of its own that is another 2k 'wasted'.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\01\26@181040 by Gerhard Fiedler

picon face
Wouter van Ooijen wrote:

> But how is it to know whether a bit pattern is a jump instruction or
> rom-stored fixed data?

Right... I had a feeling that might not work :)

> Even relocating the first 2 or 3 or 4 instructions is tricky and not
> always possible.
>
> A minor problem with relocating only those instructions: where do you
> put them? Not in a place that the application sees as its property, it
> must be at the start of a memory page (2k for 14-bit cores). If it is
> inside the booloader's memory that requires that memory to be writeable.
> If it is in a block of its own that is another 2k 'wasted'.

Which makes me even more agree with Olin... Use a transparent bootloader
and control your flash write routines, or link your programs for your
bootloader.

If you can't do either, get a programmer :)

Gerhard

2006\01\27@022018 by Wouter van Ooijen

face picon face
> Which makes me even more agree with Olin... Use a transparent
> bootloader
> and control your flash write routines, or link your programs for your
> bootloader.
>
> If you can't do either, get a programmer :)

No, IMHO there are places and times when a bootloader is appropriate,
even if it can't fully protect itself. In a classroom for instance,
where re-installing the bootloader can be a matter of seconds. But not
when the students are supposed to work at home too.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\01\27@072130 by Gerhard Fiedler

picon face
Wouter van Ooijen wrote:

>> Which makes me even more agree with Olin... Use a transparent bootloader
>> and control your flash write routines, or link your programs for your
>> bootloader.
>>
>> If you can't do either, get a programmer :)
>
> No, IMHO there are places and times when a bootloader is appropriate,
> even if it can't fully protect itself. In a classroom for instance,
> where re-installing the bootloader can be a matter of seconds. But not
> when the students are supposed to work at home too.

But in that case you can choose to link the programs for running with a
(fully protected) bootloader. IMO there's no need to work with a
transparent bootloader in a classroom -- you control the environment. (And
if you, for some reason, think that a transparent bootloader is better,
then the students /have to/ control their flash write routines to not touch
the unprotected bootloader areas. That's just a simple fact -- the ones who
don't will need a programmer :)

So I still think this holds: Either use a transparent bootloader and
control your flash writes (so that you don't overwrite the reset vector and
the separate code area that your bootloader uses outside of its protected
memory area), or use a normal (fully protected) bootloader in the boot
block and link your programs for running with your bootloader (that is,
with an entry point and interrupt vectors above the boot block), or -- if
you can't or don't want to do either -- get a programmer :)

Gerhard

2006\01\27@073947 by Wouter van Ooijen

face picon face
> > No, IMHO there are places and times when a bootloader is
> appropriate,
> > even if it can't fully protect itself. In a classroom for instance,
> > where re-installing the bootloader can be a matter of
> seconds. But not
> > when the students are supposed to work at home too.
>
> But in that case you can choose to link the programs for
> running with a (fully protected) bootloader.

You can, but I don't want to. That's probably just the way I like it,
but I am the one who must run the course. I don't (and don't want to
use) use the (external) linker anyway.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\01\27@192020 by Peter Todd

picon face
On Fri, Jan 27, 2006 at 08:22:19AM +0100, Wouter van Ooijen wrote:
> No, IMHO there are places and times when a bootloader is appropriate,
> even if it can't fully protect itself. In a classroom for instance,
> where re-installing the bootloader can be a matter of seconds. But not
> when the students are supposed to work at home too.

Heck, I wrote a bootloader from scratch not too long ago to allow one
PIC to control an group of 64 smaller pics doing motor control.

Much easier, and less scary, to write a good heavilly tested bootloader
for the slave chips so I could mess around with the actual motor
controler algorithm all I wanted, confident that it would be easy to
reflash the memory of the slaves just by flipping a switch.

Well... That's the idea anyway, still screwed up twice with my
bootloader and had to reflash about 40 chips... But it was a good
thought!

Implementation wise I just put the bootloader in the first 512 bytes of
program memory and used org 0x200 as the first line of the slave code.
The interrupt vector at 0x04 or whatever was then set with goto 0x204
Worked just fine. I think there shouldn't really be much need for
transparency, even C code can be easilly relocated with all the
compilers I've heard of.

--
peteSTOPspamspamspam_OUTpetertodd.ca http://www.petertodd.ca

2006\01\28@034027 by Wouter van Ooijen

face picon face
> Much easier, and less scary, to write a good heavilly tested
> bootloader
> for the slave chips so I could mess around with the actual motor
> controler algorithm all I wanted, confident that it would be easy to
> reflash the memory of the slaves just by flipping a switch.
>
> Well... That's the idea anyway, still screwed up twice with my
> bootloader and had to reflash about 40 chips... But it was a good
> thought!

Did you find out what you did wrong? Or did you not use write protection
(you don't mention the chip).

I created a bootloader for a customer that used the first 1k of an
18F819. AFAIK it never failed in the field.

> I think there shouldn't really be much need for
> transparency, even C code can be easilly relocated with all the
> compilers I've heard of.

Maybe not when you write both bootloader and application, so you are
very much aware of the bootloader anyway. But for a student or other
newbie it would still be a new issue that can be avoided by a
transparent bootloader.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


More... (looser matching)
- Last day of these posts
- In 2006 , 2007 only
- Today
- New search...