Friday IRC Chat w/Ken Gracey
SavageCircuits
Posts: 267
Hey everyone, just wanted to drop an invite to join us on January 21st in the Savage Circuits IRC channel with Special Guest Ken Gracey who will be available to talk about his hobbies, robots, technology, future of Parallax, etc. Set your reminders now! Details can be found here.
Comments
Its little things like this that makes Parallax a step above the rest.
I hope you will join us again.
We officially chat the 1st and 3rd Friday of each month, but usually people chat every Friday, please stop in anytime.
During the chat I promised to follow-up on some questions that I wasn't able to answer:
1. Simultaneous use of WiFi and USB on the PropBOE - is it possible or can we enable this with the use of a jumper? Will reply Monday on this thread.
2. Prop2 debugging capabilities? They will be the same as Prop1 - limited to serial I/O back to a terminal program. Question answered - if you have more specific requests on this please post them in their own thread.
3. PASM resources. Will reply Monday on this thread.
We certainly resolved the remaining Penguin distribution. Forum member JohnR will be leading the effort and I expect to see a thread from him early this week.
Thank you again for the invitation to be part of the chat - I'll join again as a regular guest.
Ken Gracey
Al
What you see is basically correct - a shortage of PASM resources, which is why are you are asking for more PASM support. Potatohead has a beginner PASM tutorial, and there is another from deSilva on the key thread sticky index. I'll come back with more on the potatohead link, but here's the one from DeSilva:
http://forums.parallax.com/showthread.php?96594-Machine-Language-Tutorial!&p=668559
Internally, the only resources are the Propeller Manual. There's not a lot planned in this way, but we hear the request and will consider producing more PASM resources.
Ken Gracey
Edited - added link to potatohead's resources which are here http://forums.parallax.com/showthread.php?96594-Machine-Language-Tutorial!&p=668563&viewfull=1#post668563
The PropBOE has a 2x4 socket for using the WiFi module to program the Propeller. This socket uses the same programming pins as the USB port (30/31). If USB is connected, power is disconnected from the WiFi Module socket (through a FET). When you plug in USB, the program that was talking over WiFi is now talking over USB and vice versa. Only one of the devices can be used at a time for programming the Propeller. However, if you want to use the two devices concurrently - as in one being a programming link and the other being for serial I/O - then you need to be able to connect other I/Os to the WiFi Module socket.
We have two options as I see it. First, the WiFi socket could have a selectable set of I/O choices so that you could use the WiFi-serial link with any I/O pins. We'd remove the exclusive power circuitry, too, and allow the I/Os to be jumpered to the WiFi socket. Or, we could make a 2x4 to 300 mil adapter so that the WiFi could span the breadboard trough and you could connect it to anything you desire. If a customer used the breadboard approach he wouldn't be able to program via 30/31 unless we brought those pins out for access. Thinking out loud here - share your ideas.
If your real goal is only for a serial link, and not programming, then you could probably buy an off-the-shelf module from WizNet for less than $40. Much of the value of the Parallax design is that it programs our chips and modules over WiFi, which requires that a co-processor load the program into the BASIC Stamp or Propeller.
JohnR, the issue is not closed internally. We will discuss it at our next meeting. I appreciate all that the Friday night chat crew brought up relative to this product. We'll find an answer that makes you happy. In the meantime, JohnR, I'd like to know your intended use of the device - are you primarily interested in the WiFi-serial over a telnet link?
Thanks,
Ken Gracey
An archive of the chat will be available but I don't think it has been made available yet.
So if I understand correctly, your WiFi module has some extra stuff on it to make it possible to program the Prop/BS2? Making it a little more expensive? Will you be offering a module without that extra stuff that can be used for general purpose WiFi interfacing? It would be helpful if we knew more about the WiFi module itself. I gather it has a 2x4 pin connector (does it use all 8 pins?), would it be possible to make that a 1x8 to be breadboard friendly? I suppose your idea of an adapter to make it breadboard friendly would work too.
On the PropBOE:
I like the idea of having the WiFi able to be used for programming instead of USB (like you have now), but I also think it should be possible to use a WiFi module as a general purpose WiFi connection for whatever the user wants. I think the simplest solution would be to have the current 2x4 port work as described already, and then have another port that would allow a WiFi module for general use. Then you could even have both features if you buy two modules. Perhaps the multipurpose port could work for that? Maybe the Xbee port (with an adapter)?
Sorry I answered with a bunch more questions.
John Abshier
First, don't get me wrong, the ability to program over WiFi has some interesting implications. It is a great option, and would come in real handy when trying to work with something like GPS navigation that you can't easily do indoors. Send the robot outside, and go through the code/burn/oh shucks! cycle from the comfort of your air conditioned/heated office/lab/workshop.
For the most part, I see WiFi filling a different purpose, and this communication with a "finished" product. This might be a robot for Command and Control, data acquisition, or even to replaces/augment something like PINK or Spinnerette, where you have the ability via a web page (or Telent) to interact with a device.
With IPv6 coming out and being adopted (slowly...), We should all be able to have about everything in our position on "The Net", and be able to access it from anywhere. Need a temp sensor on the far end of the house? How about a way to turn the darned garage lights off that the kids forgot about? Do you really want to run some type of network wire all over the place?
Certainly, there are devices available that can do this (WiZNet, etc.), but they do not carry the Parallax name, and hence it's level of support.
I'm involved with this stuff as a hobbyist and educator (4H Robotics), and, if I'm really lucky, maybe some small scale commercial stuff. While I have the ability to grab a data sheet, and figure most things out, that doesn't mean I have the time or desire to do so. The Parallax support is a BIG deal.
Also, not being a "pro", having the ability to have the WiFi and USB both hooked up, using the USB to program, and the WiFi for communication with another application (or another device(s)) is key to my development cycle. Quite frankly, I'm not good enough to be able to get everything right the first time, and need to do some debugging. If the sole method of communication is a choice between WiFi and USB, how do I debug a WiFi application that's not responding the way it should?
Two specific WiFi applications come to mind for me:
Robotic Communication: This would include command and control, as well as potentially audio and video. Many of the projects I've done and am working on are as much "tele-presence" as "robot", and are controlled by a PC based application. My current "preferred" method of communication is using a high end IP Camera (e.g. > $1000) with a serial port, and adding a WiFi Access point on the robot. I get audio/video via the camera, and "piggyback" to the Propeller via the serial port on the camera. While the high end cameras are nice, I could probably do as much, or in some cases more, with a smaller, lighter camera.
The other application is remote sensing and control. I am working on a modular monitoring and control system for "fish rooms". Think not about a couple fish tanks in the den, but someone with 20 - 100 (or more) fish tanks, that may be in one room, or may be in a couple locations throughout the house (or thing of a fish store). You have groups of tanks that are close together, and need to monitor things like temp, pH, Hardness, and other properties, and control things like lights, heaters, pumps, etc. Connecting a few sensors/controllers to a "hub" of some type makes sense, but you really don't want to run all the sensor signals, and all the control signals back to one location. TCP/IP (or UDP, etc.) is the most logical choice. Being able to swap out an RJ45 module for a WiFi would be an ideal solution.
See this thread: http://forums.parallax.com/showthread.php?129018-The-March-of-the-Penguins! for instructions on how to snag a pair of Penguins.
Ken's assessment on Propeller II is accurate. The Test-Die results achieved a great milestone. A few hiccups, but all and all everything came up and is alive. I've seen test chips that were completely dead, so this is a big deal for the first pass of Propeller II.
Hanno
Sounds good :
Can you clarify this comment of Ken's :
2. Prop2 debugging capabilities? They will be the same as Prop1 - limited to serial I/O back to a terminal program.
That sounds very primitive - is there really no hardware debug support ?
Even tiny (way under $1) chips these days have some Debug HW, and it does not need to be complex.
{ Top end embedded devices have multiple HW breakpoint, and even memory-access HW breakpoints built in }
I'd rank features something like
i) A crash-free method of reading each PC
ii) A means to set a break point; if vectoring is too hard, even sticky flags on a couple of PC-Value-compare registers is very useful.
This acts like a femto-logic analyser.
iii) A means to communicate via debug-channel.
iv) A means to load code over Debug-channel
v) Dual port like memory reading. (having this solves iii)
vi) A hardware cycle timer, with Clr&Start, Stop&Capture PC values
Done right, this can speed chip testing ?
To answer your question, I'm not sure, however most of the hardware debugging that I have seen is actually done on the software end through the IDE. breakpoints set by providing a 'hook' in software during compilation that can be monitored on the PC end.
There are several ways to communicate and debug to the Propeller I or Propeller II , starting with just wiggling a pin and making an LED go on or off, to audio feedback, to looking at a scope, to sending serial data, to providing Video or VGA output.... it depends on what your debug level needs are.
Thanks, however all those schemes are intrusive, need additional equipment and/or consume resource.
They are also highly designer-variable, and need a project change to support.
Being that resource frugal has its trade offs....
Given the die size of the Prop2, and complexity, I was expecting some included hardware pathways and registers for Debug, as were many others.
Another unrelated question: Do you know if hardware opcode fetch from QuadSPI will be supported in the Prop2 silicon ?
"Given the die size of the Prop2, and complexity, I was expecting some included hardware pathways and registers for Debug, as were many others." - And this still could be true, I don't know for sure. Those details need to come from Chip himself. I'll try to remember to ask him on Monday.