[RFC] Expansionboards and mainline kernel support
Koen Kooi
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
Gerald Coley
Hunyue Yau
> The EEPROM that is on the Zippy board is the standard for the EEPROM. All
> boards will have this exact device and configuration on the expansion
> board. What needs to be determined is the data to be contained in the
> EEPROM from a Software perspective. Maybe a good format would be one that
> determineds what the Mux settings are for each pin and the default state.
> That way we do not require a central database based on Board and Supplier,
> but instead let the EEPROMM data tell the SW what to do. Obviously we cna
> also have other date in the EEPROM, like board name, revsion, supplier,
> etc.
>
> Gerald
reason is the pinmux is insufficient to tell software what drivers it needs.
And even if it is from the same vendor, the same functionality may be done
with different chips on different vendors. A week or so ago, sakoman and I
talked about this on IRC. I think the conclusion was he would try it out on
the Overo first.
On the kernel side, I agree that patching the board file would get out of
hand. But anything we decide on should also have the approval of our
upstream, the L-O folks. There is no reason to have different approaches for
the different boards. Off hand I can think of at least 2 other boards in a
similar situation - the Logic PD modules, and the Overo. I would like to
propose the following. Depending on the feedback here, I can post it on the
L-O list.
We create a directory in arch/arm/mach-omap2/add-ons to contain expansion
board code. This would be very similar to what is done in the current board
file (register I2C/SPI/etc, grab GPIOs, etc). Each of these files can be
included or excluded based on Kconfig. Keeping in line with the rest of the
tree, the files should not be mutually exclusive if possible.
The board file would then be patched to read the EEPROM and call the add on
board init function to do its thing. This patch would be basically an array
containing the {vendor id, product id, and function pointer to the init.}.
The board file would read the I2C EEPROM and attempt to match it with the
array. The array entries can be included or excluded based on kconfig. This
entire mechanism should be controllable via Kconfig entry. Most of this code
should probally be marked with __init unless we want to allow for hot
plugging.
Thoughts, comments?
>
> On Mon, Aug 31, 2009 at 10:28 AM, Koen Kooi <ko...@beagleboard.org> wrote:
> > Hi,
> >
> > 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
>
>
Hunyue Yau
http://www.hy-research.com/
Gerald Coley
Dirk Behme
> Just to be clear. I will not be the person responsible for granting and
> tracking vendor and product IDs, so you need to figure out how that is
> handled.
- What should be in the eeprom:
I'd like to learn from ARM's machine ID. That is, I think to have
"just a number" in eeprom is enough. If this number is composed by
vendor:product ([31:16] and [15:0] of the first 32bit of that
eeprom?) this is fine. Everything else can be done based on
(U-Boot/Kernel) software. Don't put to much stuff into the eeprom.
Most probably we will end with something like broken ACPI tables, then.
- How to deal with vendor:product IDs:
Again, learn from ARM's machine IDs and coordinate this by a simple
web page. Wouldn't it be sufficient to start with a wiki table?
Best regards
Dirk
Gerald Coley
Søren Steen Christensen
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
Dirk Behme
> A wiki page works for me. I would like to see us keep it as simple as
> possible.
http://elinux.org/BeagleBoardPinMux#Expansion_boards
It's a wiki, change, add or delete what you don't like or what is missing.
Gerald Coley
Dirk Behme
> Content looks good. I prefer that this be a dedicated Wiki page just for
> this information
move it to BeagleBoardExpansionBoards.
It's just a quick and dirty start proposal ;)
Dirk
Gerald Coley
Strontium
If you are going to standardise around an EEPROM identifier chip for add
on boards, there should be a simple schematic extract on that wiki
page, or another wiki page for developers, showing the technical details
so all boards are implemented in the same way.
It would be bad to have to probe different EEPROM types/connection
methods/I2C addresses etc.
Strontium
Gerald Coley wrote:
> Works for me!
>
> Gerald
>
>
>
> On Mon, Aug 31, 2009 at 3:34 PM, Dirk Behme <dirk....@googlemail.com
> <mailto:dirk....@googlemail.com>> wrote:
>
>
> Gerald Coley wrote:
> > Content looks good. I prefer that this be a dedicated Wiki page
> just for
> > this information
>
> Yes, I agree. When we found the final style and content, we can easily
> move it to BeagleBoardExpansionBoards.
>
> It's just a quick and dirty start proposal ;)
>
> Dirk
>
> > or at tlest move the boards toward the top. It could also
> > be a way to advertise the boards for those people who are
> looking for
> > boards. This gives them one spot to come and see what is there.
> >
> > Gerald
> >
> >
> >
> > On Mon, Aug 31, 2009 at 3:23 PM, Dirk Behme
> >> Gerald Coley wrote:
> >>> A wiki page works for me. I would like to see us keep it as
> simple as
> >>> possible.
> >> Just a proposal:
> >>
> >> http://elinux.org/BeagleBoardPinMux#Expansion_boards
> >>
> >> It's a wiki, change, add or delete what you don't like or what
> is missing.
> >>
> >> Dirk
> >>
> >>> On Mon, Aug 31, 2009 at 2:04 PM, Dirk Behme
Gerald Coley
Krishna Sagiraju
Thanks,
--Krishna/.
Dirk Behme
> Suggestion,
>
> If you are going to standardise around an EEPROM identifier chip for add
> on boards, there should be a simple schematic extract on that wiki
> page, or another wiki page for developers, showing the technical details
> so all boards are implemented in the same way.
http://elinux.org/BeagleBoardPinMux#Hardware_2
is intended for.
Anybody already with the schematic for this anywhere? Zippy schematic
is "coming soon".
Best regards
Dirk
Alfonso Martone
> on boards, there should be a
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
Ian Molton
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)"
There are no stupid questions.
Its ARM kernel policy IIRC. theres nothing stopping you redefining it in a script if you want to...
--
Automotive, Linux, and other hacking:
http://www.mnementh.co.uk/
Dirk Behme
>> are going to standardise around an EEPROM identifier chip for add
>> on boards, there should be a
>
>
> 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...)"
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
Dale Weber
connected to a Beagle? Or, is there an assumption that any expansion board
added to Beagle would be a combination board offering all necessary added
features? For multiple expansion boards, there would probably need to be a
different I2C address for the EEPROM on different boards.
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
Gerald Coley
Gerald Coley
Dale Weber
> 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.
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
Gerald Coley
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.
Dale Weber
> 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.
Gerald Coley
Frans Meulenbroeks
>>
>> 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.
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
Gerald Coley
Dale Weber
> 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.
Dale Weber
> Actually, you can have multiple addresses on I2C. I am in the process of
> getting a tester board working that has 8 PCF8574s and a a PCF8581 on it
> right now. SPI is limited to one per CS. You can also use the expander to
> switch the I2C to an almost unlimited number of I2C buses. Of course, there
> is a loading issue here, but you can adjust the pullups to help with this.
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.
Sid Boyce
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
Dale Weber
> 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
Sid Boyce
>
> On Sunday 25 October 2009 01:00:10 pm Sid Boyce wrote:
>
>> 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.
>
shall have a go at OE later tonight or tomorrow, it's something I
definitely must get going and familiar with.
>> 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.
Dale Weber
> 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
Sid Boyce
>
> On Sunday 25 October 2009 02:30:56 pm Sid Boyce wrote:
>
>> 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.
>
need to subscribe?
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. The dttsp and
sdr-shell packages are already in unstable and sdr-shell starts, I just
have to sort out some audio stuff, jack is installed, but jackconnect is
not part of the ipk packages. I have quisk running on my openSUSE box,
it also builds on beagleboard, just need to get wxGTK and wxPython built
and it should work.
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'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.
Dale Weber
> I've never used IRLP so I was just looking it up. What node and do I
> need to subscribe?
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.
Sid Boyce
>
> On Sunday 25 October 2009 05:10:57 pm Sid Boyce wrote:
>> I've never used IRLP so I was just looking it up. What node and do I
>> need to subscribe?
>
> 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.
>
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$
Frans Meulenbroeks
[...]
> 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
Koen Kooi
ago, the commit shortly after that fixes it. Try updating your OE tree.
regards,
Koen
Sid Boyce
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.
Sid Boyce
>
>
>> 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.
>
> The error below should only happen at a specific commit from 2 weeks
> ago, the commit shortly after that fixes it. Try updating your OE tree.
>
> regards,
>
> Koen
>
root@Kubice:/home/lancelot/OE/openembedded# git pull
remote: Counting objects: 92, done.
remote: Compressing objects: 100% (62/62), done.
remote: Total 65 (delta 46), reused 1 (delta 1)
Unpacking objects: 100% (65/65), done.
From git://git.openembedded.net/openembedded
+ 86d4fe6...5bc9028 koen/static-libs-rework ->
origin/koen/static-libs-rework(forced update)
3b408bf..66c4fef org.openembedded.dev -> origin/org.openembedded.dev
Already up-to-date.
root@Kubice:/home/lancelot/OE/openembedded#
Regards
Sid.
Frans Meulenbroeks
"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
Koen Kooi
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
Sid Boyce
Using unstable and I had complaints without local.conf having the lines
shown above.
Tried find, ipkg-build is missing.
Frans Meulenbroeks
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