With more and more expansionboards seeing the light (I now have 3
different ones on my desk) we need to find some agreement on hardware
are software points:
Hardware:
Ideally every expansionboard has an eeprom that contains some bits
that will let the kernel and uboot know which board is attached. If we
have a standard we could write a uboot method that sets up the mux
accordingly and/or a kernel module that does the same.
Software:
Adding devices to board-omap3beagle.c file isn't going to scale well
and I can foresee conflicts, so we need some form of buildtime and
runtime checks that will do the right thing for your expansion board(s).
I'm not a hardware guy nor a kernelhacker, so please point out the (in)
sanity of all this if you are one :)
regards,
Koen
Totally agree with this approach – Keep it as simple as absolutely possible in order for everyone to contribute as easily as possible J
Best regards – Looking forward to this J
Søren
Sorry for the stupid question, but please add this FAQ: "why add an
eeprom instead of putting the identifier table somewhere in the flash
memory? (last sectors, or inside mlo/uboot/etc...)"
Another stupid question to add to the Beagleboard FAQ: "why pinmux
config has to be in the uboot or kernel? a root-privileged
executable, at /etc/init.d time, could setup mux (it only has to
write some data on some precise physical memory address)"
Thank you.
alf
Another stupid question to add to the Beagleboard FAQ: "why pinmux
config has to be in the uboot or kernel? a root-privileged
executable, at /etc/init.d time, could setup mux (it only has to
write some data on some precise physical memory address)"
Which flash? The flash on the BeagleBoard can't know which expansion
board is connected. You need the information on the expansion board.
And from SW point of view (sorry HW guys ;) ) an EEPROM is something
like 'flash' on expansion board.
> Another stupid question to add to the Beagleboard FAQ: "why pinmux
> config has to be in the uboot or kernel?
Because you need pin mux as early as possible
- to be able to correctly access peripherals by drivers in U-Boot and
Kernel
- to make sure that wrong pin mux doesn't break anything
Best regards
Dirk
I ask about this because one might want an LCD expansion board and a Zippy or
similar board, for instance. Other expansion combinations might be possible
also, as more expansion boards are designed and made.
There might be expansion boards oriented towards areas such as robotics and
process control, for instance. It would be great to be able to have a board
like this be able to work along side a Zippy and an LCD board. Other area
specific expansion boards would also be possible.
Something like a TCT Breeder with a larger Atmega processer (Atmega1280 or
Atmega 2560) with nice 3 pin headers for connecting servos and sensors to, I2C
and SPI brought out to headers, and all UARTs on headers, would be nice. The
Atmega could handle all direct interfacing with the outside world (at
selectable 3.3V or 5V for I/Os in groups of 4 or 5 pins or per specific
header), and could be made compatible with the Arduino environment as well as
be programmed in the standard AVR environments. Interfacing with Beagle could
be done through different methods such as serial, I2C, SPI, or whatever is
appropriate for the given application. Basically this could be a super
Arduino (and more) on an expansion board. :) Maybe the only level shifting
that would be required would be on the I/Os used for inter processor (Beagle
<-> AVR) communication.
An expansion like this would find uses in robotics as well as general process
control and maybe work along with a Zippy and/or LCD expansion board. There
are many more uses for a board like this, besides just robotics. I mention the
Atmega1280 (128k) and Atmega2560 (256k) because they have lots of program
memory, 16 analog inputs, quite a few PWM outputs, several UARTs, etc. I only
focus on robotics specifically because this is the area I know most about and
am working with. :)
Am I just dreaming here? ;) I'm sure others here can come up with similar
combinations of expansions that would be desirable.
8-Dale
--
I can handle complexity. It's the simple things that confound me.
Open your mind, Read, Learn, Think, Apply. 73, from N7PKT!
http://www.thedynaplex.info - Blog
http://www.thedynaplex.org - Open Source
I definitely like this idea. I'm just not sure how it would be implemented. I
have to do some more thinking on this. This would allow a lot of flexibility,
and maybe would not add too much complexity for the implementation.
> An example would be robotics to where the UART, SPI, I2C, and GPIO would be
> defined and fixed for that bus. You can then have a number of boards on the
> bus that could have a EEPROM, specific adresses set for each board and the
> EEPROM, that are read by the application and configured accordingly.
If each platform has a specific I2C address for the EEPROM, how would it be
possible to have more than one board in the same platform connected at the
same time? Would each board of a platform have a master (with EEPROM enabled)
and slaves (EEPROM disabled) where the master has the set of addresses for all
boards on the bus? I know you can't have more than one I2C device with the
same address on a bus, so am wondering how this would all work.
I can see where boards of the same platform might have an inter-board
connection for daisy chaining them, but I am probably missing something you've
already figured out. I'd definitely like the ability to have a keypad/LCD board
and robotics board(s) connected to my Beagle. Yes, I am seriously dreaming
here. ;) I'm already getting ideas for software and how to make everything
work together.
8-Dale
--
I can handle complexity. It's the simple things that confound me.
Open your mind, Read, Learn, Think, Apply. 73, from N7PKT!
http://www.thedynaplex.info - Blog, Wiki, and Forums
I definitely like this idea. I'm just not sure how it would be implemented. I
On Saturday 24 October 2009 02:55:15 pm Gerald Coley wrote:
> I have been thinking on this some more. What if we have what we call
> "Platforms". In essence these platforms will be based on applications
> spaces, such as fanless computer, robotics, instrumentation, SDR, etc. We
> can have an infinite number of these platforms. What a platform means is
> that the pin muxing is fixed for that platform. The UBoot would configure
> the pin muxing based on the paltform type. Then you could create a bus
> architecture that would have support for multiple boards.
have to do some more thinking on this. This would allow a lot of flexibility,
and maybe would not add too much complexity for the implementation.
If each platform has a specific I2C address for the EEPROM, how would it be
> An example would be robotics to where the UART, SPI, I2C, and GPIO would be
> defined and fixed for that bus. You can then have a number of boards on the
> bus that could have a EEPROM, specific adresses set for each board and the
> EEPROM, that are read by the application and configured accordingly.
possible to have more than one board in the same platform connected at the
same time? Would each board of a platform have a master (with EEPROM enabled)
and slaves (EEPROM disabled) where the master has the set of addresses for all
boards on the bus? I know you can't have more than one I2C device with the
same address on a bus, so am wondering how this would all work.
I can see where boards of the same platform might have an inter-board
connection for daisy chaining them, but I am probably missing something you've
already figured out. I'd definitely like the ability to have a keypad/LCD board
and robotics board(s) connected to my Beagle. Yes, I am seriously dreaming
here. ;) I'm already getting ideas for software and how to make everything
work together.
> I have a suggestion. We have what are called "Projects" on beagleboard.org.
> You could set up a project, maybe even just a WIKI page to start, to get
> those that are interested in developing the "ROBBO BUS". Then everyone
> could help work out these issues. You could define a backplane/stack
> approach, connector, rules, etc. for this bus.
This is a great idea. I have my OpenID, and I already have an account on
eLinux.org, so maybe I will start a page there. I also have my own Wikis as
an option. I already have an idea on a connection scheme I think will work. I
just created the project on beagleboard.org.
You can't have more than one i2c address on the bus, but it is of
course always possible to have multiple buses.
Actually one can probably also use a multiplexer somewhere (e.g. a
PCA9544A: http://www.nxp.com/#/pip/pip=[pip=PCA9544A_4]|pp=[t=pip,i=PCA9544A_4])
or something like pca9548a like
http://focus.ti.com/docs/prod/folders/print/pca9548a.html)
softwarewise any pair of i/o pins can be turned into an i2c bus
>
>
> Each board would need it's own setting for the address. This could be done
> via a dipswitch or jumpers on each board. If there was a backplane approach,
> then some of the pins could assigned as address bits and could be different
> for each slot. This would mean the the "bus" would have extra pins added to
> it just to assign a different addres based on the slot the board was added
> to.
Not sure why this is needed. What about an approach where each board
has a fixed ID (like the vendor/product id in usb)
>>
>> I can see where boards of the same platform might have an
>> inter-board
>> connection for daisy chaining them, but I am probably missing something
>> you've
>> already figured out. I'd definitely like the ability to have a keypad/LCD
>> board
>> and robotics board(s) connected to my Beagle. Yes, I am seriously dreaming
>> here. ;) I'm already getting ideas for software and how to make everything
>> work together.
>>
>
> I have a suggestion. We have what are called "Projects" on beagleboard.org.
> You could set up a project, maybe even just a WIKI page to start, to get
> those that are interested in developing the "ROBBO BUS". Then everyone could
> help work out these issues. You could define a backplane/stack approach,
> connector, rules, etc. for this bus.
The idea is definitely great, but going back to the original question:
Why is there only one expansion board for beagle?
There are a number of different reasons:
hardwware development is much more expensive to get started with than
software. Gone are the days in which you could roll your own pcb, so
you need some external party to do that for you.
Also components like SMD's are not for everyone.
And in order to make an expansion board a successful commercial
product you need some volume.
I've no idea how much beagles are sold, but maybe one out of 100 would
be interested in an expansion board, which I guess makes the market
very thin which again makes that prices rising, further diminishing
interest.
Just my $ 0.02 sunday morning thoughts :-)
Frans
> There are a number of different reasons:
> hardwware development is much more expensive to get started with than
> software. Gone are the days in which you could roll your own pcb, so
> you need some external party to do that for you.
This is definitely true. Right now, I am limiting myself to through hole
components, which means I don't have easy access to a lot of parts I would
like to use unless I can find them on some sort of board I can use. I just
don't have the ability to work with QFP and other similar or larger packages.
I can probably manage SOIC, TSOP, and similar packages though.
> Also components like SMD's are not for everyone.
> And in order to make an expansion board a successful commercial
> product you need some volume.
I sure don't plan to be soldering any QFP or larger processors and
components. I can do through hole just fine, but the finer pitch components are
outside my ability. I can do schematics just fine, but am finding PCB design to
be something I really don't want to deal with. I'd have to partner with
somebody who does have the abilities and experience I lack. I highly respect
those who can hand solder these types of components.
> I've no idea how much beagles are sold, but maybe one out of 100 would
> be interested in an expansion board, which I guess makes the market
> very thin which again makes that prices rising, further diminishing
> interest.
Right now, it appears that many Beagle users are more focused on driver and
other software development, which is understandable. Having good drivers and
base software is important to applications. I think once the software is more
solid, more expansion boards will follow. The ZIPPY's time is definitely now.
:) The time for other expansions will follow as new applications appear.
Necessity is the mother of invention, so where there is no necessity, there
won't likely be any invention. I don't really think you can use the number of
Beagles sold as a valid indication of why there are not more expansion boards
available. Just because somebody owns a Beagle, doesn't mean they are actively
using it or building projects with it. I'd love to see a robotics oriented
expansion board for Beagle be created, but I am definitely not able to produce
it.
For instance, I own several different microcontroller boards, but I'm not
using most of them at this time. Some of them will just sit on a shelf
collecting dust, while others may find their way into projects at some point. I
am definitely looking forward to working more with Beagle as soon as I get a
new SD card reader and USB Hub for it. Right now, I am focusing on learning
my way around OpenEmbedded, which I am finding is not as difficult as I've been
told by various folks.
I bet I could find a use for something like this in my robotics projects.
> The idea of having a switch to change is where you have say a motor driver
> board that handles a motor. If you want four, you would not have to buy
> four different part numbers but just buy one and set the addresses for each
> board to a unique address.
This is one idea I am kicking around for the "Robotics Bus" project. I also
have other ideas I need to get up on my blog and wiki to share.
> Based on some of the
> boards we have received for repair, it seems that a lot of people forget to
> turn off the power before they start soldering and the more solder the
> better, even if it connects all the pins together. And, the fine pitch of
> the LCD header makes this even more difficult.
I wouldn't have any problem soldering the expansion header, but there is no
way I want to deal with the LCD headers. That's where I have to draw the line
for myself. Even if I never see my ideal robotics expansion board created,
I'll still have a place for Beagle on my robots as a main controller just
because of the powerful processor.
> We are working to solve a lot of these issues. The plan for the next big
> revision of Beagle will be to have the expansion headers already mounted at
> the factory. So, no soldering.
Oh yeah, this is what I like to hear! :) While I can solder pretty well (I
did medical electronics assembly for 4 years), I prefer not to solder more
than I have to. My eyes just aren't up to doing finer pitch soldering.
> I think the robotics area is one where the
> people are not afraid of HW, so they are prime for the expansion idea. But
> even there, there are limits to being able to create their own HW, most
> notably cost.
I'm still struggling with my first PCB design for a robotics oriented Arduino
Shield. I just really don't want to have to deal with PCB design, even though
this shield is all through hole stuff.
> That is why folks like Spark Fun have so many plug in boards
> for people to just plug and go. Even if you are not a true blue HW person,
> most people can handle connecting wires and plugging in boards. My hope it
> that we can get to the point where we have a few plug and go boards to make
SparkFun is one of my favorite parts sources! I think some of their breakout
boards are over priced, but SFE definitely makes it easier for folks like me to
get access to parts we wouldn't be able to use otherwise.
> Beagle better positioned in some of these applicaion spaces, including
> Robotics. Another idea would be to create adapters that would convert the
> expansion but to mate with some of these boards that are already out there.
I've started looking at existing boards, including ones like the Arduino MEGA
(Atmega1280 based). It would not be difficult to interface to boards like this
using serial, I2C, or SPI. I'm just starting to get back to tinkering with I2C
and working with communication between my Arduino (Atmega328p) and Sanguino
(Atmega644p) boards. I have no doubt I could extend this to Beagle also.
> With Spark Fun being a Beagle distributor, there is a good path to make
> this happen, assuming we can get some plug and go boards out there.
I'd love to see SFE jump on the Beagle Bandwagon and run with it. I am
already suggesting they add the Zippy to their Beagle line. An adapter that
brings the expansion pins to selectable 3.3V/5V headers would be a great idea.
Maybe the same could be done without too much difficulty for the LCD headers,
since there are other functions besides LCD pins on there also.
The one problem with OE is a lack of up to date information. Having
tried with openSUSE and discovering somewhat of a roadblock, I switched
to Fedora 12 running under VirtualBox, but even there I see differences
that I have yet to work through and I hope to have another good go at it
sometime this week.
As for soldering, it takes practice and there are good guides available,
e.g http://www.gamesx.com/misctech/solder1.htm,
http://www3.telus.net/chemelec/Soldering/Soldering.htm,
http://www.twyman.org.uk/PCB-Techniques/index-frame.htm and others.
Selection of the right tools for the job - right-sized soldering tips,
solder flux, solder wick, cleanliness, a magnified lamp/microscope,
great care and the patience to do the job once. A heat gun and solder
paste can greatly aid a good job on SMT components. Whoosh! that sounds
quite a steep learning curve if you are a total novice to soldering.
As an aside issue, I read that Spark Fun has been issued with a Cease &
Desist order on the grounds that the name is part of SPARC and their
products could easily be improperly associated with SPARC - my mental
agility doesn't stretch that far - having worked with SPARC over the
years, an UltraSPARC5 under my desk and an Enterprise Server E4500
downstairs - neither does my imagination allow me to think anyone would
associate the two, most not ever having come across SPARC or are likely
to on grounds of cost, development tools and easy availability.
Regards
Sid.
--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks
> The one problem with OE is a lack of up to date information. Having
> tried with openSUSE and discovering somewhat of a roadblock, I switched
> to Fedora 12 running under VirtualBox, but even there I see differences
> that I have yet to work through and I hope to have another good go at it
> sometime this week.
I have discovered a lack of information on OE in places. I've figured
everything out though. I had a working OE setup almost right from the start
and have build several images I'll start testing soon. I'm running under
Kubuntu 9.04 here. I have always been told that OE is very difficult to use, but
I have not found that to be true so far. Once it is setup, which really is
pretty easy to do, it's not any worse than any other development framework. OE
certainly has a very large selection of software, but at least some of the
recipes need work. I'm looking forward to starting to test the images I have
created for Beagle so far.
> As for soldering, it takes practice and there are good guides available,
> e.g http://www.gamesx.com/misctech/solder1.htm,
> http://www3.telus.net/chemelec/Soldering/Soldering.htm,
> http://www.twyman.org.uk/PCB-Techniques/index-frame.htm and others.
It's not that I can't learn to do the soldering. I just can't physically
manage to solder stuff like the LCD headers on the Beagle. My eyes are just not
up to doing it even though I do have a pretty decent magifier light to work
under. SMD/SMT is just something I can not deal with.
> Selection of the right tools for the job - right-sized soldering tips,
> solder flux, solder wick, cleanliness, a magnified lamp/microscope,
> great care and the patience to do the job once. A heat gun and solder
> paste can greatly aid a good job on SMT components. Whoosh! that sounds
> quite a steep learning curve if you are a total novice to soldering.
I am not a novice to soldering though. I did medical electronics building,
touchup, and rework for four years. I'd prefer to just concentrate on my
application and do as little hardware stuff as possible. SMT/SMD is just not
one of those things I am going to do. My soldering has always been all through
hole stuff.
> As an aside issue, I read that Spark Fun has been issued with a Cease &
> Desist order on the grounds that the name is part of SPARC and their
> products could easily be improperly associated with SPARC - my mental
> agility doesn't stretch that far - having worked with SPARC over the
> years, an UltraSPARC5 under my desk and an Enterprise Server E4500
> downstairs - neither does my imagination allow me to think anyone would
> associate the two, most not ever having come across SPARC or are likely
> to on grounds of cost, development tools and easy availability.
I just read about this today and am amazed at what level a company like SPARC
International will stoop to. There isn't any way most people would confuse the
two companies. Unfortunately, if SPARC International chooses to actually go to
court over this, they could essentially bury SparkFun with legal fees. That
would be a BAD THING for us, for sure. There is NO similarity in the company
names OR the products/services they sell.
8-Dale
--
I can handle complexity. It's the simple things that confound me.
Open your mind, Read, Learn, Think, Apply. 73, from N7PKT!
http://www.thedynaplex.info - Blog, Wiki, and Forums
http://www.thedynaplex.org - Open Source
http://www.thedynaplex.info/wiki/index.php/RoboticsBus - Robotics Bus
>> As for soldering, it takes practice and there are good guides available,
>> e.g http://www.gamesx.com/misctech/solder1.htm,
>> http://www3.telus.net/chemelec/Soldering/Soldering.htm,
>> http://www.twyman.org.uk/PCB-Techniques/index-frame.htm and others.
>
> It's not that I can't learn to do the soldering. I just can't physically
> manage to solder stuff like the LCD headers on the Beagle. My eyes are just not
> up to doing it even though I do have a pretty decent magifier light to work
> under. SMD/SMT is just something I can not deal with.
>
That's OK. My other passion is hamradio and Software Defined Radio (SDR)
and that largely involves SMT parts, so I have had quite a bit of
practice recently with total success. My goal is to run the SDR from the
beagleboard, some apps are already there in angstrom unstable. One
problem is getting wxGTK built and next wxPython. There is a problem
with the wxGTK sources as I get the same error building it on native
openSUSE 11.2 and on the beagleboard. The app that needs it builds on
beagleboard and on openSUSE the distro's wxGTK package works.
>> Selection of the right tools for the job - right-sized soldering tips,
>> solder flux, solder wick, cleanliness, a magnified lamp/microscope,
>> great care and the patience to do the job once. A heat gun and solder
>> paste can greatly aid a good job on SMT components. Whoosh! that sounds
>> quite a steep learning curve if you are a total novice to soldering.
>
> I am not a novice to soldering though. I did medical electronics building,
> touchup, and rework for four years. I'd prefer to just concentrate on my
> application and do as little hardware stuff as possible. SMT/SMD is just not
> one of those things I am going to do. My soldering has always been all through
> hole stuff.
>
OK, same platform, different goals in mind.
>> As an aside issue, I read that Spark Fun has been issued with a Cease &
>> Desist order on the grounds that the name is part of SPARC and their
>> products could easily be improperly associated with SPARC - my mental
>> agility doesn't stretch that far - having worked with SPARC over the
>> years, an UltraSPARC5 under my desk and an Enterprise Server E4500
>> downstairs - neither does my imagination allow me to think anyone would
>> associate the two, most not ever having come across SPARC or are likely
>> to on grounds of cost, development tools and easy availability.
>
> I just read about this today and am amazed at what level a company like SPARC
> International will stoop to. There isn't any way most people would confuse the
> two companies. Unfortunately, if SPARC International chooses to actually go to
> court over this, they could essentially bury SparkFun with legal fees. That
> would be a BAD THING for us, for sure. There is NO similarity in the company
> names OR the products/services they sell.
>
> 8-Dale
It's the modern affliction - a kind of madness. I wonder if a disclaimer
would satisfy - along the lines that SparkFun is in no way associated
with SPARC International, nor is it's products and services SPARC based
or uses SPARC technology/renaming to SparksFun.
There are many companies titled "Spark Electronics" around the globe,
you would think they would be better fish to go after.
73 ... Sid.
> That's OK. My other passion is hamradio and Software Defined Radio (SDR)
> and that largely involves SMT parts, so I have had quite a bit of
> practice recently with total success. My goal is to run the SDR from the
> beagleboard, some apps are already there in angstrom unstable. One
> problem is getting wxGTK built and next wxPython. There is a problem
> with the wxGTK sources as I get the same error building it on native
> openSUSE 11.2 and on the beagleboard. The app that needs it builds on
> beagleboard and on openSUSE the distro's wxGTK package works.
N7PKT here. :) If you use IRLP, maybe we'll talk sometime. I'm also
interested in SDR, but as a user not a developer. I enjoy using Python and am
planning to use it as the main language for my robot on Beagle. One thing I
want to see if I can build for Beagle is Player and Stage, which are both
required for Python Robotics. Some sort of wireless will also figure
prominently into my robot plans, and I am experimenting with ZigBee (XBee)
now.
I'd love to get a nice LCD for my Beagle, with a touch screen. Maybe it would
not be too difficult to get the Samsung LCD Gumstix sells to work with Beagle.
With my robot being able to roam around, it would be nice to have a touch
screen GUI for selecting parameters, etc.
> It's the modern affliction - a kind of madness. I wonder if a disclaimer
> would satisfy - along the lines that SparkFun is in no way associated
> with SPARC International, nor is it's products and services SPARC based
> or uses SPARC technology/renaming to SparksFun.
> There are many companies titled "Spark Electronics" around the globe,
> you would think they would be better fish to go after.
> 73 ... Sid.
I sincerely hope SparkFun does not have to fight this in court. I'm hoping
SPARC International will just wise up and back off once they see how much bad
publicity this will be.
8-Dale
--
I can handle complexity. It's the simple things that confound me.
Open your mind, Read, Learn, Think, Apply. 73, from N7PKT!
http://www.thedynaplex.info - Blog, Wiki, and Forums
http://www.thedynaplex.info/wiki/index.php/RoboticsBus - Robotics Bus
> I'd love to get a nice LCD for my Beagle, with a touch screen. Maybe it would
> not be too difficult to get the Samsung LCD Gumstix sells to work with Beagle.
> With my robot being able to roam around, it would be nice to have a touch
> screen GUI for selecting parameters, etc.
>
I have not looked closely at the robotics stuff, but sounds interesting
and costly if doing more than controlling a couple of motors.
IRLP is free if you have any local repeaters that have it installed. It's
essentially VoIP for us Hams. Some IRLP nodes are always connected to a
reflector, and others have to be connected to whatever node you want to talk
to. Our Western Reflector is node 9250, for instance.
> I am largely a user also. I have got as far as chapter 5 in the python
> tutorials, looks a not too difficult language to use.
I like Python because it has object oriented features, but you are not forced
to use them if not appropriate to what you are doing. You can use it just like
any other scripting language if you want to use it that way.
> Yesterday I read about PlayOnLinux, installed it and tried running some
> Windows progs, Winrad fires up, but I couldn't set it up, when I click a
> button, it just bleeps at me - may be I need the dreaded DLL,
> PowerSDR-sr40 issues an error when I try to start it. I thought I would
> just try it to see what happens.
I just stay away from stuff having to do with Windows as much as I can.
However, I'd rather run an application under its native OS than use emulators
or other methods.
> I have not looked closely at the robotics stuff, but sounds interesting
> and costly if doing more than controlling a couple of motors.
Robotics definitely is not an inexpensive hobby if you intend on doing
anything real, like building a fully autonomous robot like I tinker with. I've
probably sunk over $1k (over a three year period) into my robot, W.A.L.T.E.R.,
but it's what I enjoy and it's always interesting. I'm more excited now that
I have a Beagle and want to see what I can do with all that power. I've always
wanted to experiment with computer vision, but never had quite the right board
until now. Beagle definitely has the processing power and RAM for everything I
want to do now. I'm also working on a smaller robot that won't cost nearly
that much to build and make do interesting stuff.
>> I am largely a user also. I have got as far as chapter 5 in the python
>> tutorials, looks a not too difficult language to use.
>
> I like Python because it has object oriented features, but you are not forced
> to use them if not appropriate to what you are doing. You can use it just like
> any other scripting language if you want to use it that way.
>
That's the beauty. Until I got involved with SDR, I was thinking Ruby.
>> Yesterday I read about PlayOnLinux, installed it and tried running some
>> Windows progs, Winrad fires up, but I couldn't set it up, when I click a
>> button, it just bleeps at me - may be I need the dreaded DLL,
>> PowerSDR-sr40 issues an error when I try to start it. I thought I would
>> just try it to see what happens.
>
> I just stay away from stuff having to do with Windows as much as I can.
> However, I'd rather run an application under its native OS than use emulators
> or other methods.
>
Same here, just curiosity as I hadn't heard of it before.
>> I have not looked closely at the robotics stuff, but sounds interesting
>> and costly if doing more than controlling a couple of motors.
>
> Robotics definitely is not an inexpensive hobby if you intend on doing
> anything real, like building a fully autonomous robot like I tinker with. I've
> probably sunk over $1k (over a three year period) into my robot, W.A.L.T.E.R.,
> but it's what I enjoy and it's always interesting. I'm more excited now that
> I have a Beagle and want to see what I can do with all that power. I've always
> wanted to experiment with computer vision, but never had quite the right board
> until now. Beagle definitely has the processing power and RAM for everything I
> want to do now. I'm also working on a smaller robot that won't cost nearly
> that much to build and make do interesting stuff.
>
> 8-Dale
That's not too off the wall as far as costs go.
I got openembedded to at least try to do something in kubuntu, bitbake
eventually ends in a failure to find the toolchain - something to look
at tomorrow when I'm more awake.
NOTE: Creating tarball of git repository
NOTE: Creating tarball of git checkout
NOTE: Running task 124 of 215 (ID: 103,
/home/lancelot/OE/openembedded/recipes/u-boot/u-boot-mkimage-openmoko-native_oe.bb,
do_unpack)
NOTE: Unpacking
../../sources/git_git.denx.de.u-boot.git_9912121f7ed804ea58fd62f3f230b5dcfc357d88.tar.gz
to
../../tmp/work/x86_64-linux/u-boot-mkimage-openmoko-native-1.2.0+git9912121f7ed804ea58fd62f3f230b5dcfc357d88svn2238-r1/
NOTE: Running task 129 of 215 (ID: 81,
/home/lancelot/OE/openembedded/recipes/meta/external-toolchain.bb,
do_populate_staging)
ERROR: function do_stage failed
ERROR: log data follows
(/home/lancelot/OE/tmp/work/x86_64-armv7a-sdk-linux-gnueabi/external-toolchain-1.0-r2/temp/log.do_stage.18949)
| The external toolchain could not be found in /usr/local/angstrom/arm!
NOTE: Task failed:
/home/lancelot/OE/tmp/work/x86_64-armv7a-sdk-linux-gnueabi/external-toolchain-1.0-r2/temp/log.do_stage.18949
ERROR: TaskFailed event exception, aborting
ERROR: Build of
/home/lancelot/OE/openembedded/recipes/meta/external-toolchain.bb
do_populate_staging failed
ERROR: Task 81
(/home/lancelot/OE/openembedded/recipes/meta/external-toolchain.bb,
do_populate_staging) failed
NOTE: Tasks Summary: Attempted 128 tasks of which 77 didn't need to be
rerun and 1 failed.
ERROR:
'/home/lancelot/OE/openembedded/recipes/meta/external-toolchain.bb' failed
lancelot@lancelot-desktop:~/OE/openembedded/build$
[...]
> The one problem with OE is a lack of up to date information. Having
> tried with openSUSE and discovering somewhat of a roadblock, I switched
> to Fedora 12 running under VirtualBox, but even there I see differences
> that I have yet to work through and I hope to have another good go at it
> sometime this week.
What is your problem with OpenSuse and OE?
I am using OE with OpenSuse 11.1 and recently 11.2 without any problem.
Frans
I shall have to copy across local.conf, source-me.txt etc. from the
kubuntu VM and try again. I seem to remember it was a pre-req package
problem.
The current problem under kubuntu - I saw messages to the effect that
there were "multiple providers" and I reckon it is a configuration
problem in local.conf... I have
TARGET_ARCH = arm
MACHINE = "beagleboard"
DISTRO = "angstrom"
TARGET_OS = "linux-gnueabi"
NOTE: Handling BitBake files: / (6695/6695) [100 %]
NOTE: Parsing finished. 6407 cached, 0 parsed, 288 skipped, 0 masked.
NOTE: Cache is clean, not saving.
NOTE: Resolving any missing task queue dependencies
NOTE: multiple providers are available for virtual/libc
(external-toolchain, eglibc, glibc);
NOTE: consider defining PREFERRED_PROVIDER_virtual/libc
NOTE: multiple providers are available for
virtual/arm-linux-gnueabi-binutils (external-toolchain, binutils-cross);
NOTE: consider defining
PREFERRED_PROVIDER_virtual/arm-linux-gnueabi-binutils
NOTE: multiple providers are available for
virtual/arm-linux-gnueabi-libc-for-gcc (external-toolchain, eglibc, glibc);
NOTE: consider defining
PREFERRED_PROVIDER_virtual/arm-linux-gnueabi-libc-for-gcc
NOTE: multiple providers are available for linux-libc-headers
(linux-libc-headers, external-toolchain);
NOTE: consider defining PREFERRED_PROVIDER_linux-libc-headers
NOTE: multiple providers are available for
virtual/arm-linux-gnueabi-libc-initial (glibc-initial, eglibc-initial);
NOTE: consider defining
PREFERRED_PROVIDER_virtual/arm-linux-gnueabi-libc-initial
NOTE: Preparing runqueue
ERROR: Multiple .bb files are due to be built which each provide
virtual/arm-linux-gnueabi-gcc
(/home/lancelot/OE/openembedded/recipes/gcc/gcc-cross_csl-arm-2008q3.bb
/home/lancelot/OE/openembedded/recipes/meta/external-toolchain.bb).
This usually means one provides something the other doesn't and should.
NOTE: Executing runqueue
NOTE: Running task 57 of 215 (ID: 165,
/home/lancelot/OE/openembedded/recipes/zlib/zlib-native_1.2.3.bb,
do_setscene)
NOTE: Running task 58 of 215 (ID: 166,
/home/lancelot/OE/openembedded/recipes/zlib/zlib-native_1.2.3.bb, do_fetch)
NOTE: fetch http://www.zlib.net/zlib-1.2.3.tar.bz2
--2009-10-26 02:29:52-- http://www.zlib.net/zlib-1.2.3.tar.bz2
Resolving www.zlib.net... 69.73.181.135
Connecting to www.zlib.net|69.73.181.135|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 425209 (415K) [application/x-tar]
Saving to: `/home/lancelot/OE/sources/zlib-1.2.3.tar.bz2'
100%[======================================>] 425,209 174K/s in 2.4s
There is also a "ipkg-build" command not found.
NOTE: Running task 9 of 12 (ID: 11,
/home/lancelot/OE/openembedded/recipes/tasks/task-java-gtk.bb,
do_package_write_ipk)
sh: ipkg-build: command not found
NOTE: Task failed: ipkg-build execution failed
ERROR: TaskFailed event exception, aborting
ERROR: Build of
/home/lancelot/OE/openembedded/recipes/tasks/task-java-gtk.bb
do_package_write_ipk failed
Perhaps I could have a copy of your local.conf.
"ipkg-build" is in ./staging/i686-linux/usr/bin/ipkg-build
My conf file is attached
Nothing exciting in it, ofc you need to change paths and you might
want to re-enable the checksums check by removing the last line.
Feel free to ping me on irc if your problem persist (my nick is eFffeM)
Frans
Please don't put TARGET_ARCH and TARGET_OS in local.conf, http://www.angstrom-distribution.org/building-angstrom
doesn't tell you to do it, so don't do it. If there is a wiki out
there saying you should, kill it with fire.
regards,
Koen
Using unstable and I had complaints without local.conf having the lines
shown above.
Tried find, ipkg-build is missing.
If you need those lines then there is definitely something wrong with your tree.
I suggest start from scratch by discarding your tree and temp dir and
clone and build again with a local.conf like the one I attached.
Frans