Hi,
I'm writing regarding a job I posted at oDesk (I would have posted here,
but was unsure of the etiquette for job postings in this group).
I'm working with an LPC2129 for a remote telematics project. I use a cell
module with an encapsulated serial port that can cut in and out, but the module
also has FTP commands (Telit GM862).
The LPC2129 has a connected SD card running a FAT filesystem. I want to download
a file - using FTP, or using TFTP/some other resumable solution using the
encapsulated serial port (in case we change cell modules and our new hardware
doesn't support FTP by AT command).
I want to download a new compiled firmware to the SD card, remotely reboot the
device, and reflash it with the updated software (this would require versioning
and checksum validation). If the flash is corrupted, I want to reflash using a
"known good" version loaded to the SD card at the factory, but otherwise a
typical boot should run through the primary bootloader, and if all is good (i.e.
no new firmware present), enter the typical runtime code.
Essentially, I want a secondary bootloader to load code off an SD card. I took
over this project and am not an embedded coder, but it seems we might be able to
save (either through linking or some other way) the SPI driver and FAT code the
previous developer wrote.
How much should a project like this cost? Maybe it's the naive mechanical
engineer in me, but it doesn't seem like this project is really
groundbreaking and it shouldn't be that expensive. I have one quote for
$5,000 in four weeks, which seems like a lot. I have a feeling that a lot of
that money is paying someone to learn a technology with which they are not
familiar.
Any suggestions on where else I might find a developer? This is a part of a
research project that might turn into a company - so we're on a shoestring
budget, and won't be trading (potential, future) equity for this.
Thank you for your suggestions. I really just need a gut check here.
How much should it cost to develop a secondary bootloader?
Started by ●May 10, 2012
Reply by ●May 10, 20122012-05-10
> How much should a project like this cost? Maybe
it's the naive mechanical
> engineer in me, but it doesn't seem like this project is really
> groundbreaking and it shouldn't be that expensive. I have one quote for
> $5,000 in four weeks, which seems like a lot. I have a feeling that a lot
> of that money is paying someone to learn a technology with which they are
> not familiar.
$5k and 4 weeks? So, that's ~$1k / week which is peanuts. Developing a
bulletproof bootloader from scratch takes some time (let others chime in
here about how amazing/disasterous this has been for them). Having just
completed such an undertaking, it will take you longer than you ever expect.
In my case, I already had my own FAT file system code and all the necessary
drivers to read/write files from microSD. I needed to compile the app
separately, and then prepare the app for downloading by writing some extra
tools to add a firmware label block and CRC, and then encrypt it. I needed
to write the bootloader to verify the installed firmware and start a reflash
if it is defective. The bootloader verified the downloaded firmware which
entails decrypting it, checking the CRC, then checking the firmware label to
ensure that the firmware is intended for the target. Once all integrity and
compatibility checks pass, and only then, does it reflash things.
All in all, starting from nowhere-near ground zero took a couple of
all-nighters to 5am and 7 days of hard work. (I would add that the upgrade
firmware happens to be collected from a server over the Internet using our
existing TCP/IP stack, and that firmware acquisition code was also
constructed during that time).
So, $5k and 4 weeks? To me this sounds tight on time, but then I don't know
anything about the specification or qualification of the engineer
undertaking this task. What would say that is ABSOLUTELY BARGAIN BASEMENT,
nowhere near expensive. The proviso would be that you don't know what
you're going to end up with.
> Any suggestions on where else I might find a developer? This is a part of
> a research project that might turn into a company - so we're on a
> shoestring budget, and won't be trading (potential, future) equity for
> this.
Why find a developer? Why not take a COTS solution? Segger do one.
http://shop-us.segger.com/BootLoader_s/34.htm
This reduces your risk and raises your chances of success, but for a price.
Regards,
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore running Defender... http://www.vimeo.com/25709426
> engineer in me, but it doesn't seem like this project is really
> groundbreaking and it shouldn't be that expensive. I have one quote for
> $5,000 in four weeks, which seems like a lot. I have a feeling that a lot
> of that money is paying someone to learn a technology with which they are
> not familiar.
$5k and 4 weeks? So, that's ~$1k / week which is peanuts. Developing a
bulletproof bootloader from scratch takes some time (let others chime in
here about how amazing/disasterous this has been for them). Having just
completed such an undertaking, it will take you longer than you ever expect.
In my case, I already had my own FAT file system code and all the necessary
drivers to read/write files from microSD. I needed to compile the app
separately, and then prepare the app for downloading by writing some extra
tools to add a firmware label block and CRC, and then encrypt it. I needed
to write the bootloader to verify the installed firmware and start a reflash
if it is defective. The bootloader verified the downloaded firmware which
entails decrypting it, checking the CRC, then checking the firmware label to
ensure that the firmware is intended for the target. Once all integrity and
compatibility checks pass, and only then, does it reflash things.
All in all, starting from nowhere-near ground zero took a couple of
all-nighters to 5am and 7 days of hard work. (I would add that the upgrade
firmware happens to be collected from a server over the Internet using our
existing TCP/IP stack, and that firmware acquisition code was also
constructed during that time).
So, $5k and 4 weeks? To me this sounds tight on time, but then I don't know
anything about the specification or qualification of the engineer
undertaking this task. What would say that is ABSOLUTELY BARGAIN BASEMENT,
nowhere near expensive. The proviso would be that you don't know what
you're going to end up with.
> Any suggestions on where else I might find a developer? This is a part of
> a research project that might turn into a company - so we're on a
> shoestring budget, and won't be trading (potential, future) equity for
> this.
Why find a developer? Why not take a COTS solution? Segger do one.
http://shop-us.segger.com/BootLoader_s/34.htm
This reduces your risk and raises your chances of success, but for a price.
Regards,
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore running Defender... http://www.vimeo.com/25709426
Reply by ●May 10, 20122012-05-10
...oh, and just a quickie, this is what the firmware upgrade looks like:
Welcome to CoreBASIC on the SolderCore.
Copyright (c) 2004-2012 Rowley Associates Limited.
63,480 bytes free. Core at 80 MHz. Firmware 0.8.
> firmware run
Connecting to www.soldercore.com (50.116.85.1)...
Requesting /firmware/soldercore-v1/core.fw...
Downloaded 491,520 bytes of 491,520 (100%)...
Verifying integrity of upgrade firmware...
Verified 491,520 bytes of 491,520 (100%)...with good CRC.
Upgrade firmware is verified to work on soldercore-v1.
Installed firmware is 0.8; upgrade firmware is 0.9.
Installed firmware differs from upgrade firmware.
FIRMWARE UPGRADE STARTED
This network connection will be closed, the
SolderCore will reset and the dowloaded firmware
will be programmed into the SolderCore's flash.
If you have problems with firmware replacement,
please visit the support forums.
Closing connection now.
Connection to host lost.
The firmware upgrade checks the downloaded firmware before starting the
bootloader, but the bootloader doesn't trust what's on the SD card to be
correct, so it *also* verifies the integrity and conformance of the firmware
before committing to a reflash. This makes sure that there is no way you
should be able to manually brick the part by downloading duff firmware and
forcing a firmware reflash.
Just $0.02 from my recent work...
Regards,
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore running Defender... http://www.vimeo.com/25709426
> -----Original Message-----
> From: l... [mailto:l...] On Behalf
> Of Paul Curtis
> Sent: 10 May 2012 16:07
> To: l...
> Subject: RE: [lpc2000] How much should it cost to develop a secondary
> bootloader?
>
> > How much should a project like this cost? Maybe it's the naive
> > mechanical engineer in me, but it doesn't seem like this project is
> > really groundbreaking and it shouldn't be that expensive. I have one
> > quote for
> > $5,000 in four weeks, which seems like a lot. I have a feeling that a
> > lot of that money is paying someone to learn a technology with which
> > they are not familiar.
>
> $5k and 4 weeks? So, that's ~$1k / week which is peanuts. Developing a
> bulletproof bootloader from scratch takes some time (let others chime in
> here about how amazing/disasterous this has been for them). Having just
> completed such an undertaking, it will take you longer than you ever
> expect.
>
> In my case, I already had my own FAT file system code and all the
> necessary drivers to read/write files from microSD. I needed to compile
> the app separately, and then prepare the app for downloading by writing
> some extra tools to add a firmware label block and CRC, and then encrypt
> it. I needed to write the bootloader to verify the installed firmware and
> start a reflash if it is defective. The bootloader verified the
> downloaded firmware which entails decrypting it, checking the CRC, then
> checking the firmware label to ensure that the firmware is intended for
> the target. Once all integrity and compatibility checks pass, and only
> then, does it reflash things.
>
> All in all, starting from nowhere-near ground zero took a couple of all-
> nighters to 5am and 7 days of hard work. (I would add that the upgrade
> firmware happens to be collected from a server over the Internet using our
> existing TCP/IP stack, and that firmware acquisition code was also
> constructed during that time).
>
> So, $5k and 4 weeks? To me this sounds tight on time, but then I don't
> know anything about the specification or qualification of the engineer
> undertaking this task. What would say that is ABSOLUTELY BARGAIN
> BASEMENT, nowhere near expensive. The proviso would be that you don't
> know what you're going to end up with.
>
> > Any suggestions on where else I might find a developer? This is a part
> > of a research project that might turn into a company - so we're on a
> > shoestring budget, and won't be trading (potential, future) equity for
> > this.
>
> Why find a developer? Why not take a COTS solution? Segger do one.
>
> http://shop-us.segger.com/BootLoader_s/34.htm
>
> This reduces your risk and raises your chances of success, but for a
> price.
>
> Regards,
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> SolderCore running Defender... http://www.vimeo.com/25709426
>
>
>
>
>
>
>
>
>
>
Welcome to CoreBASIC on the SolderCore.
Copyright (c) 2004-2012 Rowley Associates Limited.
63,480 bytes free. Core at 80 MHz. Firmware 0.8.
> firmware run
Connecting to www.soldercore.com (50.116.85.1)...
Requesting /firmware/soldercore-v1/core.fw...
Downloaded 491,520 bytes of 491,520 (100%)...
Verifying integrity of upgrade firmware...
Verified 491,520 bytes of 491,520 (100%)...with good CRC.
Upgrade firmware is verified to work on soldercore-v1.
Installed firmware is 0.8; upgrade firmware is 0.9.
Installed firmware differs from upgrade firmware.
FIRMWARE UPGRADE STARTED
This network connection will be closed, the
SolderCore will reset and the dowloaded firmware
will be programmed into the SolderCore's flash.
If you have problems with firmware replacement,
please visit the support forums.
Closing connection now.
Connection to host lost.
The firmware upgrade checks the downloaded firmware before starting the
bootloader, but the bootloader doesn't trust what's on the SD card to be
correct, so it *also* verifies the integrity and conformance of the firmware
before committing to a reflash. This makes sure that there is no way you
should be able to manually brick the part by downloading duff firmware and
forcing a firmware reflash.
Just $0.02 from my recent work...
Regards,
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore running Defender... http://www.vimeo.com/25709426
> -----Original Message-----
> From: l... [mailto:l...] On Behalf
> Of Paul Curtis
> Sent: 10 May 2012 16:07
> To: l...
> Subject: RE: [lpc2000] How much should it cost to develop a secondary
> bootloader?
>
> > How much should a project like this cost? Maybe it's the naive
> > mechanical engineer in me, but it doesn't seem like this project is
> > really groundbreaking and it shouldn't be that expensive. I have one
> > quote for
> > $5,000 in four weeks, which seems like a lot. I have a feeling that a
> > lot of that money is paying someone to learn a technology with which
> > they are not familiar.
>
> $5k and 4 weeks? So, that's ~$1k / week which is peanuts. Developing a
> bulletproof bootloader from scratch takes some time (let others chime in
> here about how amazing/disasterous this has been for them). Having just
> completed such an undertaking, it will take you longer than you ever
> expect.
>
> In my case, I already had my own FAT file system code and all the
> necessary drivers to read/write files from microSD. I needed to compile
> the app separately, and then prepare the app for downloading by writing
> some extra tools to add a firmware label block and CRC, and then encrypt
> it. I needed to write the bootloader to verify the installed firmware and
> start a reflash if it is defective. The bootloader verified the
> downloaded firmware which entails decrypting it, checking the CRC, then
> checking the firmware label to ensure that the firmware is intended for
> the target. Once all integrity and compatibility checks pass, and only
> then, does it reflash things.
>
> All in all, starting from nowhere-near ground zero took a couple of all-
> nighters to 5am and 7 days of hard work. (I would add that the upgrade
> firmware happens to be collected from a server over the Internet using our
> existing TCP/IP stack, and that firmware acquisition code was also
> constructed during that time).
>
> So, $5k and 4 weeks? To me this sounds tight on time, but then I don't
> know anything about the specification or qualification of the engineer
> undertaking this task. What would say that is ABSOLUTELY BARGAIN
> BASEMENT, nowhere near expensive. The proviso would be that you don't
> know what you're going to end up with.
>
> > Any suggestions on where else I might find a developer? This is a part
> > of a research project that might turn into a company - so we're on a
> > shoestring budget, and won't be trading (potential, future) equity for
> > this.
>
> Why find a developer? Why not take a COTS solution? Segger do one.
>
> http://shop-us.segger.com/BootLoader_s/34.htm
>
> This reduces your risk and raises your chances of success, but for a
> price.
>
> Regards,
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> SolderCore running Defender... http://www.vimeo.com/25709426
>
>
>
>
>
>
>
>
>
>
Reply by ●May 10, 20122012-05-10
--- In l..., "tc_lawabider" wrote:
>
> Hi,
> How much should a project like this cost? Maybe it's the naive mechanical engineer in me, but it doesn't seem like this project is really groundbreaking and it shouldn't be that expensive. I have one quote for $5,000 in four weeks, which seems like a lot. I have a feeling that a lot of that money is paying someone to learn a technology with which they are not familiar.
>
The $5k number doesn't surprise me. It would only buy about 50 hours worth of time ($100/hr). The 4 weeks seems like a hedge in case the work takes longer than anticipated. Or, somebody is working for $30/hr and that seems light.
There are SD based secondary bootloaders all over the place. It seems every programmer buys an ARM chip, blinks an LED and immediately wants to write a secondary loader. Some of them actually work. I think NXP has one in their library; I don't know if it works for your chip.
Working with an obscure approach to grabbing the file via FTP could take a bit of work. It could be as ugly as writing the FTP protocol, the TCP protocol and the SLIP protocol.
Paul Curtis has given you a far better response than mine. In my view, your projected cost is light. Nobody should be writing production code for $30/hr so if the time estimate is even close, the cost should be closer to $20k. I wouldn't count on the time estimate either.
Estimates for software work are notoriously wrong. This is probably not the answer you wanted.
Richard
>
> Hi,
> How much should a project like this cost? Maybe it's the naive mechanical engineer in me, but it doesn't seem like this project is really groundbreaking and it shouldn't be that expensive. I have one quote for $5,000 in four weeks, which seems like a lot. I have a feeling that a lot of that money is paying someone to learn a technology with which they are not familiar.
>
The $5k number doesn't surprise me. It would only buy about 50 hours worth of time ($100/hr). The 4 weeks seems like a hedge in case the work takes longer than anticipated. Or, somebody is working for $30/hr and that seems light.
There are SD based secondary bootloaders all over the place. It seems every programmer buys an ARM chip, blinks an LED and immediately wants to write a secondary loader. Some of them actually work. I think NXP has one in their library; I don't know if it works for your chip.
Working with an obscure approach to grabbing the file via FTP could take a bit of work. It could be as ugly as writing the FTP protocol, the TCP protocol and the SLIP protocol.
Paul Curtis has given you a far better response than mine. In my view, your projected cost is light. Nobody should be writing production code for $30/hr so if the time estimate is even close, the cost should be closer to $20k. I wouldn't count on the time estimate either.
Estimates for software work are notoriously wrong. This is probably not the answer you wanted.
Richard
Reply by ●May 10, 20122012-05-10
--- In l..., "tc_lawabider" wrote:
> The LPC2129 has a connected SD card running a FAT filesystem. I want to download a file - using FTP, or using TFTP/some other resumable solution using the encapsulated serial port (in case we change cell modules and our new hardware doesn't support FTP by AT command).
Since you may ultimately want to use modem-like commands (AT commands), you need to implement all of the following protocols: FTP -> TCP -> IP -> PPP. It may even be better to just skip over the cell phone implementation of FTP as, ultimately, it may go away and it just complicates the project. If the cell phone accepts AT commands, you are good to go.
There are a number of open source implementations of the TCP/IP stack but the licensing may be problematic when the stuff is used in a commercial product. And, of course, porting it may be an even bigger problem.
Keil has a full TCP/IP stack including PPP in their ARM MDK Professional toolchain. I am pretty sure there wouldn't be any licensing restrictions on the resulting binaries but the toolchain costs a little over $9k. Just for the tools, not the brains to drive them. The good news is that the stack is complete all the way down to the serial port.
If you want to see how ugly licensing can get, look into the Oracle lawsuit against Google. We're talking billions of dollars.
Years ago, Microsoft wanted to walk away from Java. My guess is that they will soon start running. What used to be an opensource language is, all of a sudden, a license-required language. After hundreds of millions of lines of code have been written.
http://www.zdnet.com/blog/open-source/the-muddled-mess-of-the-oracle-vs-google-trial/10907
BTW, TFTP is based on UDP which is not a reliable transport protocol. It doesn't matter which application layer protocol you use (FTP, HTTP), it should be one that relies on TCP, not UDP.
If I were building anything commercial, I would be looking for commercial toolchains and libraries. I would want to KNOW that I owned the resulting binaries without restriction.
BTW, one reason for buying a commercial toolchain is support. Your programmers may come and go (and they will!) but the toolchain and libraries will be around forever.
Richard
> The LPC2129 has a connected SD card running a FAT filesystem. I want to download a file - using FTP, or using TFTP/some other resumable solution using the encapsulated serial port (in case we change cell modules and our new hardware doesn't support FTP by AT command).
Since you may ultimately want to use modem-like commands (AT commands), you need to implement all of the following protocols: FTP -> TCP -> IP -> PPP. It may even be better to just skip over the cell phone implementation of FTP as, ultimately, it may go away and it just complicates the project. If the cell phone accepts AT commands, you are good to go.
There are a number of open source implementations of the TCP/IP stack but the licensing may be problematic when the stuff is used in a commercial product. And, of course, porting it may be an even bigger problem.
Keil has a full TCP/IP stack including PPP in their ARM MDK Professional toolchain. I am pretty sure there wouldn't be any licensing restrictions on the resulting binaries but the toolchain costs a little over $9k. Just for the tools, not the brains to drive them. The good news is that the stack is complete all the way down to the serial port.
If you want to see how ugly licensing can get, look into the Oracle lawsuit against Google. We're talking billions of dollars.
Years ago, Microsoft wanted to walk away from Java. My guess is that they will soon start running. What used to be an opensource language is, all of a sudden, a license-required language. After hundreds of millions of lines of code have been written.
http://www.zdnet.com/blog/open-source/the-muddled-mess-of-the-oracle-vs-google-trial/10907
BTW, TFTP is based on UDP which is not a reliable transport protocol. It doesn't matter which application layer protocol you use (FTP, HTTP), it should be one that relies on TCP, not UDP.
If I were building anything commercial, I would be looking for commercial toolchains and libraries. I would want to KNOW that I owned the resulting binaries without restriction.
BTW, one reason for buying a commercial toolchain is support. Your programmers may come and go (and they will!) but the toolchain and libraries will be around forever.
Richard
Reply by ●May 10, 20122012-05-10
> If you want to see how ugly licensing can get, look
into the Oracle
> lawsuit against Google. We're talking billions of dollars.
No; it's low hundreds of thousands, if that now. Oracle shouted billions,
but for all their huff and puff, nothing will come of it.
> Years ago, Microsoft wanted to walk away from Java. My guess is that they
> will soon start running. What used to be an opensource language is, all
> of a sudden, a license-required language. After hundreds of millions of
> lines of code have been written.
>
> http://www.zdnet.com/blog/open-source/the-muddled-mess-of-the-oracle-vs-
> google-trial/10907
This is a terribly bad article. It states "but the jury did decide that
APIs can be copyrighted." Balderdash! They jury were instructed, by the
judge, to *assume* that APIs could be copyrighted and then decide whether
Google had infringed under this assumption. The judge has reserved the
decision on whether APIs can be copyrighted for himself, and he has not yet
ruled on that to my knowledge.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore running Defender... http://www.vimeo.com/25709426
> lawsuit against Google. We're talking billions of dollars.
No; it's low hundreds of thousands, if that now. Oracle shouted billions,
but for all their huff and puff, nothing will come of it.
> Years ago, Microsoft wanted to walk away from Java. My guess is that they
> will soon start running. What used to be an opensource language is, all
> of a sudden, a license-required language. After hundreds of millions of
> lines of code have been written.
>
> http://www.zdnet.com/blog/open-source/the-muddled-mess-of-the-oracle-vs-
> google-trial/10907
This is a terribly bad article. It states "but the jury did decide that
APIs can be copyrighted." Balderdash! They jury were instructed, by the
judge, to *assume* that APIs could be copyrighted and then decide whether
Google had infringed under this assumption. The judge has reserved the
decision on whether APIs can be copyrighted for himself, and he has not yet
ruled on that to my knowledge.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore running Defender... http://www.vimeo.com/25709426
Reply by ●May 10, 20122012-05-10
FTP sounds like a simple approach but, if you want to maintain
compatibility in the future, I would go for a server-client architecture
downloading packets. FTP requires to support 2 TCP ports in parallel,
which may not be trivial with the most basic modems (I'm talking about
those that include the TCP/IP stack) whereas a client-server approach
uses only 1.
On the other hand, I would leave the TCP/IP stack to the modem to ease
the development, unless you desperately need to lower your cost by $10
per unit and want to source your modem in China.
Note on UDP transmission: it can significantly lower the communication
cost if you transmit small packets. I would not discard the option from
the beginning as you can implement the acknowledge at the application
level - let alone that the application needs an ACK mechanism anyway.
You would be surprised of how common it is in GPRS applications.
Cheers
Olivier
rtstofer wrote:
>
> --- In l... ,
> "tc_lawabider" wrote:
>
> > The LPC2129 has a connected SD card running a FAT filesystem. I want
> to download a file - using FTP, or using TFTP/some other resumable
> solution using the encapsulated serial port (in case we change cell
> modules and our new hardware doesn't support FTP by AT command).
>
> Since you may ultimately want to use modem-like commands (AT
> commands), you need to implement all of the following protocols: FTP
> -> TCP -> IP -> PPP. It may even be better to just skip over the cell
> phone implementation of FTP as, ultimately, it may go away and it just
> complicates the project. If the cell phone accepts AT commands, you
> are good to go.
>
> There are a number of open source implementations of the TCP/IP stack
> but the licensing may be problematic when the stuff is used in a
> commercial product. And, of course, porting it may be an even bigger
> problem.
>
> Keil has a full TCP/IP stack including PPP in their ARM MDK
> Professional toolchain. I am pretty sure there wouldn't be any
> licensing restrictions on the resulting binaries but the toolchain
> costs a little over $9k. Just for the tools, not the brains to drive
> them. The good news is that the stack is complete all the way down to
> the serial port.
>
> If you want to see how ugly licensing can get, look into the Oracle
> lawsuit against Google. We're talking billions of dollars.
>
> Years ago, Microsoft wanted to walk away from Java. My guess is that
> they will soon start running. What used to be an opensource language
> is, all of a sudden, a license-required language. After hundreds of
> millions of lines of code have been written.
>
> http://www.zdnet.com/blog/open-source/the-muddled-mess-of-the-oracle-vs-google-trial/10907
>
> BTW, TFTP is based on UDP which is not a reliable transport protocol.
> It doesn't matter which application layer protocol you use (FTP,
> HTTP), it should be one that relies on TCP, not UDP.
>
> If I were building anything commercial, I would be looking for
> commercial toolchains and libraries. I would want to KNOW that I owned
> the resulting binaries without restriction.
>
> BTW, one reason for buying a commercial toolchain is support. Your
> programmers may come and go (and they will!) but the toolchain and
> libraries will be around forever.
>
> Richard
--
Olivier Gautherot
*Email:* o...@gautherot.net
*Cel:* +56 98 730 9361
*Web:* www.gautherot.net
*LinkedIn:* http://www.linkedin.com/in/ogautherot
compatibility in the future, I would go for a server-client architecture
downloading packets. FTP requires to support 2 TCP ports in parallel,
which may not be trivial with the most basic modems (I'm talking about
those that include the TCP/IP stack) whereas a client-server approach
uses only 1.
On the other hand, I would leave the TCP/IP stack to the modem to ease
the development, unless you desperately need to lower your cost by $10
per unit and want to source your modem in China.
Note on UDP transmission: it can significantly lower the communication
cost if you transmit small packets. I would not discard the option from
the beginning as you can implement the acknowledge at the application
level - let alone that the application needs an ACK mechanism anyway.
You would be surprised of how common it is in GPRS applications.
Cheers
Olivier
rtstofer wrote:
>
> --- In l... ,
> "tc_lawabider" wrote:
>
> > The LPC2129 has a connected SD card running a FAT filesystem. I want
> to download a file - using FTP, or using TFTP/some other resumable
> solution using the encapsulated serial port (in case we change cell
> modules and our new hardware doesn't support FTP by AT command).
>
> Since you may ultimately want to use modem-like commands (AT
> commands), you need to implement all of the following protocols: FTP
> -> TCP -> IP -> PPP. It may even be better to just skip over the cell
> phone implementation of FTP as, ultimately, it may go away and it just
> complicates the project. If the cell phone accepts AT commands, you
> are good to go.
>
> There are a number of open source implementations of the TCP/IP stack
> but the licensing may be problematic when the stuff is used in a
> commercial product. And, of course, porting it may be an even bigger
> problem.
>
> Keil has a full TCP/IP stack including PPP in their ARM MDK
> Professional toolchain. I am pretty sure there wouldn't be any
> licensing restrictions on the resulting binaries but the toolchain
> costs a little over $9k. Just for the tools, not the brains to drive
> them. The good news is that the stack is complete all the way down to
> the serial port.
>
> If you want to see how ugly licensing can get, look into the Oracle
> lawsuit against Google. We're talking billions of dollars.
>
> Years ago, Microsoft wanted to walk away from Java. My guess is that
> they will soon start running. What used to be an opensource language
> is, all of a sudden, a license-required language. After hundreds of
> millions of lines of code have been written.
>
> http://www.zdnet.com/blog/open-source/the-muddled-mess-of-the-oracle-vs-google-trial/10907
>
> BTW, TFTP is based on UDP which is not a reliable transport protocol.
> It doesn't matter which application layer protocol you use (FTP,
> HTTP), it should be one that relies on TCP, not UDP.
>
> If I were building anything commercial, I would be looking for
> commercial toolchains and libraries. I would want to KNOW that I owned
> the resulting binaries without restriction.
>
> BTW, one reason for buying a commercial toolchain is support. Your
> programmers may come and go (and they will!) but the toolchain and
> libraries will be around forever.
>
> Richard
--
Olivier Gautherot
*Email:* o...@gautherot.net
*Cel:* +56 98 730 9361
*Web:* www.gautherot.net
*LinkedIn:* http://www.linkedin.com/in/ogautherot
Reply by ●May 10, 20122012-05-10
--- In l..., "Paul Curtis" wrote:
> This is a terribly bad article. It states "but the jury did decide that
> APIs can be copyrighted." Balderdash! They jury were instructed, by the
> judge, to *assume* that APIs could be copyrighted and then decide whether
> Google had infringed under this assumption. The judge has reserved the
> decision on whether APIs can be copyrighted for himself, and he has not yet
> ruled on that to my knowledge.
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> SolderCore running Defender... http://www.vimeo.com/25709426
The problem with our courts is that you just never know how it's going to come out or how long it will take before the dust settles. This lawsuit could cloud the software business for years and years what with appeals to higher and higher courts.
Richard
> This is a terribly bad article. It states "but the jury did decide that
> APIs can be copyrighted." Balderdash! They jury were instructed, by the
> judge, to *assume* that APIs could be copyrighted and then decide whether
> Google had infringed under this assumption. The judge has reserved the
> decision on whether APIs can be copyrighted for himself, and he has not yet
> ruled on that to my knowledge.
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> SolderCore running Defender... http://www.vimeo.com/25709426
The problem with our courts is that you just never know how it's going to come out or how long it will take before the dust settles. This lawsuit could cloud the software business for years and years what with appeals to higher and higher courts.
Richard
Reply by ●May 10, 20122012-05-10
> The problem with our courts is that you just never
know how it's going to
> come out or how long it will take before the dust settles. This lawsuit
> could cloud the software business for years and years what with appeals to
> higher and higher courts.
Whatever the judgement, there will be an appeal. Google have already called
for a mistrial on one point.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore running Defender... http://www.vimeo.com/25709426
> come out or how long it will take before the dust settles. This lawsuit
> could cloud the software business for years and years what with appeals to
> higher and higher courts.
Whatever the judgement, there will be an appeal. Google have already called
for a mistrial on one point.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore running Defender... http://www.vimeo.com/25709426
Reply by ●May 10, 20122012-05-10
Oracle Vs Apple
Apple Vs Samsung (even though Samsung are a big Apple supplier)
Samsung Vs Apple (go figure)
Motorola Vs Apple (anything to do with Google's acquisition of Motorola!)
Etc.
The layers are have a ball, and getting very rich, fine tooth combing
tiny dubious patents that will stand up to scrutiny in some courts and
be completely invalid in others (apparently). There is no end so long
as there are fortunes to be made and lost.
Patents were supposed to protect and motivate the small guy, but do the
opposite. No matter who is in the right or wrong, the person who will
win is the person with the deepest pockets - and that is not the small
guy. The layers don't care about anything as long as they get paid.
The layers make a fortune, but I don't care because I can laugh at how
dull and boring their lives are compared to mine. They can sit in their
dark rooms and count there money if it makes them feel valued ;o)
I went to an innovation seminar once where they were proud of the fact
that, as a business in its own right, they took out patents on things
they never intended to actually make. Really silly things, like "a
piece of card that makes your toffee crispier when you microwave it",
just in case anybody actually made it one day. Highly immoral, but they
make more money than me too...unfortunately.
Regards,
Richard.
+ http://www.FreeRTOS.org
Designed for microcontrollers. More than 7000 downloads per month.
+ http://www.FreeRTOS.org/trace
15 interconnected trace views. An indispensable productivity tool.
On 10/05/2012 19:19, Paul Curtis wrote:
>
>
>> The problem with our courts is that you just never know how it's going to
>> come out or how long it will take before the dust settles. This lawsuit
>> could cloud the software business for years and years what with appeals to
>> higher and higher courts.
>
> Whatever the judgement, there will be an appeal. Google have already called
> for a mistrial on one point.
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> SolderCore running Defender... http://www.vimeo.com/25709426
Apple Vs Samsung (even though Samsung are a big Apple supplier)
Samsung Vs Apple (go figure)
Motorola Vs Apple (anything to do with Google's acquisition of Motorola!)
Etc.
The layers are have a ball, and getting very rich, fine tooth combing
tiny dubious patents that will stand up to scrutiny in some courts and
be completely invalid in others (apparently). There is no end so long
as there are fortunes to be made and lost.
Patents were supposed to protect and motivate the small guy, but do the
opposite. No matter who is in the right or wrong, the person who will
win is the person with the deepest pockets - and that is not the small
guy. The layers don't care about anything as long as they get paid.
The layers make a fortune, but I don't care because I can laugh at how
dull and boring their lives are compared to mine. They can sit in their
dark rooms and count there money if it makes them feel valued ;o)
I went to an innovation seminar once where they were proud of the fact
that, as a business in its own right, they took out patents on things
they never intended to actually make. Really silly things, like "a
piece of card that makes your toffee crispier when you microwave it",
just in case anybody actually made it one day. Highly immoral, but they
make more money than me too...unfortunately.
Regards,
Richard.
+ http://www.FreeRTOS.org
Designed for microcontrollers. More than 7000 downloads per month.
+ http://www.FreeRTOS.org/trace
15 interconnected trace views. An indispensable productivity tool.
On 10/05/2012 19:19, Paul Curtis wrote:
>
>
>> The problem with our courts is that you just never know how it's going to
>> come out or how long it will take before the dust settles. This lawsuit
>> could cloud the software business for years and years what with appeals to
>> higher and higher courts.
>
> Whatever the judgement, there will be an appeal. Google have already called
> for a mistrial on one point.
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> SolderCore running Defender... http://www.vimeo.com/25709426
