my company has an entire department dedicated to firmware design and one for
firmware verification. We made a big processor change and the firmware team
is pushing the hardware guys to write drivers to allow them to move up
higher in the abstraction layer. It also helps with adoption if drivers are
already written. We have things in place regarding test frameworks and other
infrastructure... but its dated (think early 80s) and very closed source. I
was hoping to deliver something a little closer to the 21st century.
It is just me and another guy, but hopefully, it will be the platform for
many projects in the future.
I am very interested in comparing notes. The author seemed responsive on the
forum.
Eric
On Wed, Aug 18, 2010 at 9:11 PM, Alan Dayley <
adayley@gmail.com> wrote:
> That sounds like a fun project!
>
> I think your first questions to answer are more architectural rather
> than programming practice. If your company has done this sort of
> thing before, they probably have expectations as to what the drive
> interface will look like, performance, delivery, test frameworks and
> so on. If not, you need to create all that with the help of the
> people who will be using your driver.
>
> Is it just you working on this as part of a larger project?
>
> Alan
>
> On Tue, Aug 17, 2010 at 8:51 PM, Eric Cope <eric.cope@gmail.com> wrote:
> > My application is slightly different. I am the hardware engineer
> designing
> > the embedded chip. I am tasked with writing the sample driver source code
> > for others within my company. The platform is a microcontroller similar
> to
> > Qualcomm's Snapdragon sans the CMDA engine. That book does look
> appealing.
> >
> > Thanks,
> > Eric
> >
> > On Tue, Aug 17, 2010 at 8:01 PM, Alan Dayley <adayley@gmail.com> wrote:
> >>
> >> There are books, volumes even, written about embedded development and
> >> drivers specifically. An appropriate response is not possible without
> >> more details of you project.
> >>
> >> Also, most chip makers provide sample driver source code, etc. that
> >> can be used as a basis for your own code. Or, at least, they have
> >> extensive command specifications, etc. I don't think you'll really
> >> need to write drivers for _everything_.
> >>
> >> I'm currently reading this excellent book on the subject, from a TDD
> >> perspective:
> >>
> >>
> >>
> http://www.pragprog.com/titles/jgade/test-driven-development-for-embedded-c
> >>
> >> If you want more answer than this, please describe your goals and
> >> hardware with more detail.
> >>
> >> Alan
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)