PBP Book

[schu4647]

I agree with Melanie except for the completeness of the PBP manual. I think there are a lot of holes. A couple examples:

1)I posted a question on here about pulsin. Lets say I want to check the pulse length of a high signal. The book doesn't say if it waits for a leading edge, or if it will just start counting when the instruction starts and the pin is high. I never got an answer. I ended up puting an if then statement to start this command when the pin is low.

2)For LCDout you need to put a $FE for commands. The manual does not explain why this is. Someone in here told me that $FE makes the enable bit high while leaving it out lets the enable bit go low.

These are both things that you would have to either find in the manual or have developed PBP to know. I don't think that anyone but MELABS could write a book that explains this.

[Luciano]

Hi Bruce,

I have a title for your second book.

============================

Teaching math!

My pupils are:

Parallax Basic Stamp I
Parallax Basic Stamp II
MELabs PICBASIC Compiler
MELabs PICBASIC Pro Compiler

============================

* * *

To the user schu4647:

A great source of information is the Parallax Basic Stamp 2 manual and
the Parallax web site. Many of the Parallax Basic Stamp commands are
supported by the MELabs Compiler.

Example: Pulsin
See PDF page 97 and 98 of the link below:
http://www.pond.ie/pdf/BStamp.pdf

Best regards,

Luciano

[nedtron]

"Hello nedtron it appears that you have not posted on our forums in several weeks, why not take a few moments to ask a question, help provide a solution or just engage in a conversation with another member in any one of our forums?"

OK You asked for it . . .

Rehashing command syntax and data sheets seems redundant.

A book of good practical "real world" examples with code, concise explanation and "real" schematics would probably be useful and helpful.

I don't mean "Hello World" nor half baked Myke Predko projects.

Something more on the order of Don Lancaster's TTL Cookbook might work.

Perhaps a PIC Heathkit on steroids would do the trick?

Good practical examples provide a solid foundation and may communicate nuisances either to subtle or to verbose for logistic text.

Perhaps "PIC Micros for Dummies" would work?

Every programming text that I have seen neglects the very effective and infamous Bill Gates approach to programming "The Art of Stealing Other Peoples Code and Compiling It".

Personally, I can always steal and compile faster.

The Internet has made steal n' compile technology a reality.

I have seen countless engineers searching the Internet for drivers, active controls and source code.

GNU public domain code is the cat's meow!

A federal court found that the Pentium II had stolen embedded Cyrix code and inadvertently included the Cyrix trademark statement! (dumb)

National Semiconductor bought Cyrix and collected the big bucks from Intel. (smart)

Now I know that their are prima donnas who think that every byte of PIC Basic code that that they compile is a virgin holy creation of the highest order deserving Code Protect, Serialization and encryption techniques not yet devised by lowly Microchip.

However, I see it as the PIC game.

Parker Brothers gave us Monopoly and Microchip gave us PIC.

Both are great games allowing players to devise their individual strategies.

There are other great games such as Visual Basic, C++, FORTRAN and Assembly.

However, at the end of the day, Parker Brothers (Hasbro), Microsoft, Borland and Microchip are the real winners!

And yes, we were well entertained . . .

Or it least I was . . .

I kind of like this title “Steal This Code & Give the Bucks to Charity”.

Perhaps, I have over elaborated and the title "RTFM" might just work after all?

Got to go, there's some USB HID code looking awfully good!

Ned

[air1kdf]

I would spend a chapter on the bootloader, and just putting some code on a chip. Basically talking to the chip, and flash an LED. Great start, minimal code.

I would ignore writing anything on each command, as a search or reading the manual will work everytime.

Keep in mind that a chip is all about IO. Spend a lot of time on this (like the rest of the book). Digital input, analog input (linear and logarithmic). Maybe a temperature sensor (thermisistor). Bluetooth, 802.11a/b/g, ethernet, RS232 (both internal and Max232a, etc). Output to LED, LCD, Touch screen, data logger on chip and external stuff like SD card, eeprom, X10, etc.

If you had projects like home automation, and logging, maybe a thermostat, you will sell a bunch of books, and I'd buy one. If you went into commands I'm out, a waste of my time and money. Don't teach logic, that can be obtained anywhere. Fundamental circuits are OK though because there are way more programmers than there are circuit designers.

Always explain why you are selecting a command over another one, or a specific circuit.

[malc-c]

If you had projects like home automation, and logging, maybe a thermostat, you will sell a bunch of books, and I'd buy one. If you went into commands I'm out, a waste of my time and money.

But then it becomes just another "project" book which would also require the reader to have extensive knowledge on how to build what could turn out to be complicate CCt's or PCB's if they want to use them. The other option would be to simply have a subroutine that does one of these functions with a simple diagram on how to connect each sensor / relay / etc rather than a full blown program.

The thing is, looking back on this thread, it originated in 2003.. it's now 2006 and Bruce has not added any comments since April of this year... so the book may be a long time in coming ???

[Luciano]

Originally Posted by malc-c

The thing is, looking back on this thread, it originated in 2003.. it's now 2006 and Bruce has not added any comments since April of this year... so the book may be a long time in coming ???

Wrong!

This thread was started on 14th April 2006, 21:44.

Best regards,

Luciano

[malc-c]

Whoops - I looked at Bruce's joining date - sorry !!!!!

[air1kdf]

But then it becomes just another "project" book which would also require the reader to have extensive knowledge on how to build what could turn out to be complicate CCt's or PCB's if they want to use them. The other option would be to simply have a subroutine that does one of these functions with a simple diagram on how to connect each sensor / relay / etc rather than a full blown program.

The thing is, looking back on this thread, it originated in 2003.. it's now 2006 and Bruce has not added any comments since April of this year... so the book may be a long time in coming ???

I think that we are talking about the same thing. I didn't mention nor imply anything complicated. Unless you consider a logarithmic type of sensor, which are simple to connect, but a quick search on this forum shows no results on how to implement the conversion in code.

I would also like to add power supplies, since every project needs one.

[Urmish Mehta]

Bruce:
It would be nice if a book is written with an intent you have outlined in your first e-mail.
All I can say is, I would go for it.
Urmish

[mtripoli]

I agree with Melanie except for the completeness of the PBP manual. I think there are a lot of holes. A couple examples:

1)I posted a question on here about pulsin. Lets say I want to check the pulse length of a high signal. The book doesn't say if it waits for a leading edge, or if it will just start counting when the instruction starts and the pin is high. I never got an answer. I ended up puting an if then statement to start this command when the pin is low.

2)For LCDout you need to put a $FE for commands. The manual does not explain why this is. Someone in here told me that $FE makes the enable bit high while leaving it out lets the enable bit go low.

These are both things that you would have to either find in the manual or have developed PBP to know. I don't think that anyone but MELABS could write a book that explains this.

There's more to these statements than it appears on the surface (and why I applaud anyone that writes a book, does tech support, etc). I see many posts referring to commands from the PBP manual like #1 here, but if you look in the manual they just don't hold up. This is a good example: "The book doesn't say if it waits for a leading edge,"...
Read the first paragraph from the manual (I broke it out into "steps"):
1.) Measures pulse width on Pin (ok, good, that's what we want).
2.) If State is zero (0), the width of a low pulse is measured (measured width placed in Var)
3.) If State is one (1), the width of a high pulse is measured (measured width stored in Var).
4.) If the pulse edge never happens...Var is set to zero (0).
Skipping ahead...
5.) PULSIN normally waits a maximum of 65535 counts before it determines there is no pulse ( which can be adjusted via a DEFINE).

So, the manual does in fact tell you exactly what it is doing. How much more information needs to be contained in the explanation for it to be clear what's going on? Is there a different manual than the one I have (I've bought PBP for myself many years ago, as well as for three different companies I've done consulting work for and got the same manual). Or, as is so often the case, has someone assumed that they "knew" what the command did?

On the second statement about the LCDOUT command I ask (and this kind of goes to what Melanie said) "How much information is enough"? The first paragraph clearly says "PBP supports LCD modules with a Hitachi 44780 controller or equivalent". To me, this means more than RTFM; it means read ALL the data for ALL the components used in a design. I have a copy of the 44780 data sheet and understand what all the commands are doing and why. This goes to what I refer to the current state of "Lego electronics"; plug stuff together and assume it will work. When it doesn't do what you "thought" blame the module, code "example", compiler - everyone but yourself.

No one book is a panacea. No one reference can tell you everything.

Mike Tripoli