Communication I2C, RS-232 and so
sigo
Posts: 3
Hello, this is my first post.· And I would like to ask for the communication skills of the Propeller.
First a little background bout me:
Hardware devellopement experience, robotics
8051 BASIC, a bit ASM
80196 ASM, a bit C
68000 PASCAL, BASIC, a bit ASM
all longer (10+years) ago
recently:
AVR 8Bit C, BASCOM, a bit ASM
I read the introduction of the Propeller manual
I think about usuing the Propeller in Robotic applications
Therefore I would need I2C Master and Slave mode communication.
Do I have to program it by myself in ASM or are there ready made communication routines availlable?
And how about hardware support? As far as I understand, I have to program everything on bitlevel, and would have to use one COG for each communication channel, which would be more or less busy..
Can I use the same I2C as the EEPROM?
How aboutt UART(s)? Is the UART a hardware uart accessible form all COGs?
So far I only understood that each CPU can use any pin in bit mode.
And that Video is fairly easy to realise.
Thanks in advance, for you kind reply,
Sigo
Germany
·
First a little background bout me:
Hardware devellopement experience, robotics
8051 BASIC, a bit ASM
80196 ASM, a bit C
68000 PASCAL, BASIC, a bit ASM
all longer (10+years) ago
recently:
AVR 8Bit C, BASCOM, a bit ASM
I read the introduction of the Propeller manual
I think about usuing the Propeller in Robotic applications
Therefore I would need I2C Master and Slave mode communication.
Do I have to program it by myself in ASM or are there ready made communication routines availlable?
And how about hardware support? As far as I understand, I have to program everything on bitlevel, and would have to use one COG for each communication channel, which would be more or less busy..
Can I use the same I2C as the EEPROM?
How aboutt UART(s)? Is the UART a hardware uart accessible form all COGs?
So far I only understood that each CPU can use any pin in bit mode.
And that Video is fairly easy to realise.
Thanks in advance, for you kind reply,
Sigo
Germany
·
Comments
I'm pretty new in Propeller world, but doing what you are looking for is quite easy : I did it after just a couple of days playing with the beast.
An I2C driver (sorry : "object") can be written in SPIN, and you can find some in the Propeller library. I've written mine, using these ones as a basis, since I needed only bare bone things, but also because I2C objects I found didn't include a serialization mechanism to prevent from I2C transactions overlap when the bus is used by code running in separate COGs. As a starting point, I've joined it to this message.
Note that I've declared crucial variables in DAT section (instead of VAR) so that their values can be shared between different instances of the object created by OBJ directives placed in different SPIN modules. As very well explained in deSilva excellent document (albeit dealing with writing ASM code for the Prop, it details inner mechanisms that are useful to be aware of even when writing SPIN code), DAT vars are in global scope while VAR are locals wrt object.
Based on this driver, I've successfully interfaces a LCD I2C display and a I2C compass (Devantech CMPS03). I've attached the LCD driver to illustrate how it is simple to write such things).
Be aware that these code samples are not intended to be bullet-proof ones, and that maybe they will make Propellers experts laugh at. At least I would have bring them some fun
Have fun
Best regards
Eric
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Eric
More about my robotics related activities on : www.pobot.org
Merci beaucoup for this quick response - and the code examples!!
This really makes it much more interresting to give the Propeller a trial. I am thinking about using the Propeller as a kind of coprocessor(s) for quick trigonometric calculations.. Not more than a thought, yet.
Best regards,
Ralf
btw: Impressing webiste, my Frech is not good enough to understand it all, but very sophisticated what you make
Glad to see it could help you. And thanks for the French words
I'd be curious to know about your experiment results. I have similar concerns too, trying to see if even while not having strong arithmetic capabilities, the Prop would be able to cope with real-time position and heading computation from odometry based on incremental encoders. I've two of these thingies (1024 steps SCANCON encoders) in the drawers and I've not yet tried them with the Prop.
Thanks for the kind words. We are trying to translate as much pages as possible in English, but it's quite an heavy task, knowing the number of pages our website has now. But since we get more and more hits from foreign visitors, this gives us some energy and motivation to endeavor the task.
Best regards.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Eric
More about my robotics related activities on : www.pobot.org
your apprehensions after reading the datasheet (or the first chapter of the manual) are well founded. In fact all this is the strong and the weak side of the Propeller.
The only "device" awareness the propeller has is the way NTSC and PAL do their color phase shifting.
Everything from fine control of PWM to I2C, SPI, RS232, CAN, USB has to be programmed by yourself. The Propeller has virtually no specific silicon, but masses of "unspecific" processing power in its COGs.
Many things have already been programmed.
Some things most likely cannot be programmed due to internal memory shortcommings.
SPIN is a slow interpretated language, without using machine code you can hardly exceed the 10kHz limit. But machine code is 1+ MHz, with a TRUE instruction time of 50ns for each 32 bit operation
And it is terrible fun to do all those things yourself
I guess that I now have got·at least enough understanding to check, if the Propeller could be a solution for my application (just hobby).
Eric, the ATtiny2313 is able to count the incremental encoder at up to 120.000 counts/s (@20MHz), doing the PID, Ramp generation, PWM countrol of the motordriver,RS232 communication. Perhaps this would be a nice "peripheral", that keeps the Propeller from these "basics". Which would be - to my actual understanding - difficult to realize. So that the propeller can do the higher level coordination and control tasks. The ATtiny-software, that I use is not by my own, but from here: http://elm-chan.org/works/smc/report_e.html·it's really excellent, like many other projects oh Chan.
I wonder, if the Propeller could do this in one COG, too?
Ralf
From rough estimations we've done for a 1 m/s max speed for the robot that the association is preparing for Eurobot 2008, it is not a problem as you mentioned, to have the task fulfilled by an ATtiny. The team is planing to use bigger chips (ATmega32 at the least) since all is done there, including high level supervision. Our Eurobot 2006 robot (4th rank at the French Eurobot 2006 edition) was controlled by 2 ATmega32, one of them being mostly devoted to the embedded CMUcam.
However, even if they will go with ATmegas for the moment, because we are starting to build a significant experience with these µC, I'm investigating with the Propeller for curiosity's sake. In fact I will not take part to the cup as a competitor, because I'm now for more than 1 year member of the organization team (member of the refereeing committee as one of the chief referees).
As far as I estimated the projection, I think this should not be a problem for the Prop to do the same, since we are relieved here from all multi-tasking stuff, thanks to the COGs. The main difficulty will be to overcome the 2k COG limitation which could be a problem for some of the processes. Besides, we have been used to code in C (WinAVR toolkit), and reverting to ASM could be a bit hard for some of the team members, more used to Java in their day to day life
Running all you mentioned in a single COG seems not really possible IMHO, since you need several different and independent time bases to handle proper encoder counting, PWM generation,... My direction would be to distribute all that must run in an independent manner in different COGs.
Best regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Eric
More about my robotics related activities on : www.pobot.org
Post Edited (RicE) : 9/16/2007 10:29:49 PM GMT
I should describe the difference between the Prop a AVR in this way:
The AVR has
1x USART
2x PWM
4x TImers
1x SPI
1 I2C
or whatever, I didn't look it up..
The Propeller has:
8 COGS with altogether 16 32-bit timer/counters.
YOU decide what to do with that!
A major problem can be: 8 is the limit
see page 9
Post Edited (Fred Hawkins) : 10/8/2007 1:51:10 AM GMT
works fine! Downloads the Lab. Is located where the other Labs are....
http://forums.parallax.com/attachment.php?attachmentid=47794 (for your convenience)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
> it's really excellent, like many other projects oh Chan.
Have you thought about the UHU? <http://www.uhu-servo.de/>
Still the wrong CPU.
I *think* that someone is developing a servo-controller on the Prop. I pointed that guy to the Propeller and a vew weeks later, he told me that he's using it in 3 projects.
For the QE-signals, there is some sample code (quadrature encoder) that is promisingly fast, will run circles around the Atmel. And what makes the Propeller an ideal platform is, that there are some sub-tasks that have to run in the background. Serial communication, error-tracking and correction, ...
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO