The TI ARM processor used in the BeagleBone Black has a couple of co-processors that seem to be designed for doing time-critical stuff. I'm sure somebody here has used them for such things. John
Writing to MCU flash
Started by ●January 24, 2019
Reply by ●January 26, 20192019-01-26
Reply by ●January 26, 20192019-01-26
On Saturday, January 26, 2019 at 3:44:19 AM UTC-5, 69883925...@nospam.org wrote:> John Larkin wrote > >On Thu, 24 Jan 2019 19:08:45 GMT, <698839253X6D445TD@nospam.org> > >wrote: > > > >>Lasse Langwadt Christensen wrote > >>>the update procedure does in some cases involve the host > >>>loading a flash programmer into RAM, so if you are the belt and suspenders > >>>type you avoid the small risk of having flash programming code in the product > >>>that could be triggered by accident > >> > >>I use the code protection feature of Microchip PICs when I do not want to show the code in some cases. > >>So releasing code memory update using that boot loader is out. > >>I agree with J Larkin that it is better to simply send a new chip (are on sockets for that reason anyways). > >>User settings and calibration are in EEPROM in the chip, or an external chip. > >>Having default settings in code is a nice idea (have not done that, EEPROMs are programmed to default when programming). > >>There is a small risk in using sockets, those can fail, good quality sockets are OK. > >>I am wondering about J.L's security (especially the companies that go to starbucks for coffee and updates), > >>WiFi has been completely hacked, > >>Theoretically you could simply pose as the manufacturer and send a fixed update etc etc. > >>Would be a no-no for me. > >> > >>Replacing chips on sockets is easy, just added some features to some project today... > >>however that also needed adding some hardware... Drone flight recorder > >>can record flight and then you can have it fly that again and again all by itself. > >>Saved as a text file, can edit it too. > >>lat lon alt speed heading.... other commands.... to / from SDcard... > >>Just for fun. > >> > >> > > > >Sometimes we use a socketed SD card instead of a plugin dip flash > >chip. The Zynq SOCs know how to boot off SD cards. > > In this case the SDcard only carries data, no code. > Not even a filesystem, 1 data record per sector, read exactly every 200 mS. > All the executable code is in w Microchip 18F14K22 PICs. > > I know you did some HUD display software hardware? long ago. > I have one 18F14K22 as auto--pilot reading from the SDcard, > http://panteltje.com/panteltje/quadcopter/index.html > and one driving a SAA5281 Ceefax chip to add data to the analog video from the drone: > http://panteltje.com/panteltje/quadcopter/hud.html > > Now to get the data after its seemed logical to read it back from the display memory from teh SAA5281, > call it re-using code :-) > That took exactly 134 lines of asm, and a serial to USB module (the hardware) to plug it from the remote into a PC > or whatever to record as text file. > > Again I was amazed how extremely powerful asm is!!! > You cannot do it on a raspberry or some other Linux box, because it is all time driven, all interrupts (gnuarm take note): > > main_loop: > clrwdt ; watchdog timer > bra main_loop > > > I wondered, all those big blobs of software, gigabyte speed multicore processors, are we going the wrong way? > Nature wants the simplest most powerful solution, natural selection, the whole thing needs a cleanup [1]. > > Loading hex file: > Program 4366 bytes at address 0x000000 > Config 14 bytes at address 0x300000 > EEPROM 0 bytes at address 0xf00000 > > So about 4 kB for the HUD and flight recorder. > > Loading hex file: > Program 4626 bytes at address 0x000000 > Config 14 bytes at address 0x300000 > EEPROM 0 bytes at address 0xf00000 > > and about 4 kB for the auto-pilot. > > And zero boot times :-) > > Sure gnuarm FPGA can also do that, but these micros already have a lot on board for peripherals. > > Dinos are dead.Not sure what a Dino is, but your idea of dedicating a sector per data record is poor in the extreme. Sectors on Flash are not very reliable. It is a good idea to have a flash file system to manage the good/bad blocks for you. I guess you can do that yourself, but are you thinking of that? Rick C. -- Get 6 months of free supercharging -- Tesla referral code - https://ts.la/richard11209
Reply by ●January 26, 20192019-01-26
On Saturday, January 26, 2019 at 2:10:36 PM UTC-5, 69883925...@nospam.org wrote:> John Larkin wrote > >On Sat, 26 Jan 2019 08:44:11 GMT, <698839253X6D445TD@nospam.org> > >wrote: > > > >>John Larkin wrote > >>>On Thu, 24 Jan 2019 19:08:45 GMT, <698839253X6D445TD@nospam.org> > >>>wrote: > >>> > >>>>Lasse Langwadt Christensen wrote > >>>>>the update procedure does in some cases involve the host > >>>>>loading a flash programmer into RAM, so if you are the belt and suspenders > >>>>>type you avoid the small risk of having flash programming code in the product > >>>>>that could be triggered by accident > >>>> > >>>>I use the code protection feature of Microchip PICs when I do not want to show the code in some cases. > >>>>So releasing code memory update using that boot loader is out. > >>>>I agree with J Larkin that it is better to simply send a new chip (are on sockets for that reason anyways). > >>>>User settings and calibration are in EEPROM in the chip, or an external chip. > >>>>Having default settings in code is a nice idea (have not done that, EEPROMs are programmed to default when programming). > >>>>There is a small risk in using sockets, those can fail, good quality sockets are OK. > >>>>I am wondering about J.L's security (especially the companies that go to starbucks for coffee and updates), > >>>>WiFi has been completely hacked, > >>>>Theoretically you could simply pose as the manufacturer and send a fixed update etc etc. > >>>>Would be a no-no for me. > >>>> > >>>>Replacing chips on sockets is easy, just added some features to some project today... > >>>>however that also needed adding some hardware... Drone flight recorder > >>>>can record flight and then you can have it fly that again and again all by itself. > >>>>Saved as a text file, can edit it too. > >>>>lat lon alt speed heading.... other commands.... to / from SDcard... > >>>>Just for fun. > >>>> > >>>> > >>> > >>>Sometimes we use a socketed SD card instead of a plugin dip flash > >>>chip. The Zynq SOCs know how to boot off SD cards. > >> > >>In this case the SDcard only carries data, no code. > >>Not even a filesystem, 1 data record per sector, read exactly every 200 mS. > >>All the executable code is in w Microchip 18F14K22 PICs. > >> > >>I know you did some HUD display software hardware? long ago. > >>I have one 18F14K22 as auto--pilot reading from the SDcard, > >> http://panteltje.com/panteltje/quadcopter/index.html > >>and one driving a SAA5281 Ceefax chip to add data to the analog video from the drone: > >> http://panteltje.com/panteltje/quadcopter/hud.html > >> > >>Now to get the data after its seemed logical to read it back from the display memory from teh SAA5281, > >>call it re-using code :-) > >>That took exactly 134 lines of asm, and a serial to USB module (the hardware) to plug it from the remote into a PC > >>or whatever to record as text file. > >> > >>Again I was amazed how extremely powerful asm is!!! > >>You cannot do it on a raspberry or some other Linux box, because it is all time driven, all interrupts (gnuarm take note): > >> > >>main_loop: > >> clrwdt ; watchdog timer > >> bra main_loop > >> > >> > >>I wondered, all those big blobs of software, gigabyte speed multicore processors, are we going the wrong way? > >>Nature wants the simplest most powerful solution, natural selection, the whole thing needs a cleanup [1]. > > > >We've done a few boxes that use a Zync chip (FPGA and two ARM cores) > >with the full FPGA config and Linux and the whole file system on the > >SD card, external DRAM, running all the standard Linux utilities and > >stacks, and our applications in c. All that sounds complex but it > >works fine. The serial i/o and USB and Ethernet and file system were > >free. You might not want to do all that in assembly. > > > >We did a few products using a microZed > > > >https://www.dropbox.com/s/vibkpjgaozyva5o/AMSS_1.JPG?dl=0 > > > >(which runs Linux out of the box and allows users access to waveform > >files using standard Linux tools) > > > >and a couple with the Zynq on our board. > > > >https://www.dropbox.com/s/istk1nq8zu4wjit/P5A_10-layer.jpg?dl=0 > > > > > >All that sounds complex, and it is, but it just works. > > > >It might be interesting to do things like this using Linux and Python. > > > > > >We also do bare-metal c apps on single-chip ARM systems. LPC1750 > >series cpu's. > > > >https://www.dropbox.com/s/j7vlg6p8fku1ir0/T2_CPU.jpg?dl=0 > > > >Everything, including the cal table, is in on-chip flash. We program > >the chip over the jtag connector and cal over the USB port. > > > > > >I don't like programming c, but I have a couple of whiz-kids who do. > > All very nice stuff, and having an FPGA with Linux running is in a way the best of both worlds. > I have never used Zync, have an older Xilinx FPGA development board. > C is OK, but not for time critical cases, it then simply puts an extra layer between you and the hardware. > That is my view anyways. > How is the boot-time of that Zync thing?The thread is about low level control of hardware. I'm not sure why anyone would want to complicate that with some humongous iron running Linux when a simple MCU or even a roll your own CPU in the FPGA would do the trick! Why do people want to complicate things so much? In many respects, just running C code on an MCU is a tremendous waste of time, both processor and development. Rick C. -+ Get 6 months of free supercharging -+ Tesla referral code - https://ts.la/richard11209
Reply by ●January 27, 20192019-01-27
gnuarm wrote>Not sure what a Dino is,https://en.wikipedia.org/wiki/Dinosaur dinosaur are extinct The story goes, because those were so big, that if one was bitten in the tail it took almost a second for the nerve signal to reach the brain and be processed, making those an easy victim for other animals and human hunters.>but your idea of dedicating a sector per data record >is poor in the extreme. Sectors on Flash are not very reliable. It is a >good idea to have a flash file system to manage the good/bad blocks for you. > I guess you can do that yourself, but are you thinking of that?No, bad sector handling is done by the SDcard firmware we are talking about SDcards for data storage.
Reply by ●January 27, 20192019-01-27
On 26/01/2019 00:24, gnuarm.deletethisbit@gmail.com wrote:> On Friday, January 25, 2019 at 2:12:13 AM UTC-5, David Brown wrote: >> On 25/01/2019 02:47, Phil Hobbs wrote: >>> On 1/24/19 3:59 PM, speff wrote: >>>> On Thursday, 24 January 2019 10:25:20 UTC-5, Phil Hobbs wrote: >>>>> So we've got this custom product that includes a voltage-controlled >>>>> amplifier. >>>>> >>>>> VCA chips as used in ultrasound and so on have nice low noise at the >>>>> highest gains, but at low gain they stink on ice. The same is true of >>>>> all transconductance-based VCAs unless you use a zillion stages. >>>>> >>>>> Sooo, we're faking it with a dpot, an op amp with a mux-controlled >>>>> resistor ladder, and an LPC804 Cortex M0+. >>>>> >>>>> The resistor ladder is made out of standard-value Susumu 25-ppm >>>>> resistors, so it's better than the dpot except that the switchable gains >>>>> aren't exactly powers of two. >>>>> >>>>> The simple way of handling this is to have the thing self-calibrate. >>>>> That could be done at power-up and the cal table kept in RAM, or at test >>>>> time with the table in flash. >>>>> >>>>> There's some lore on the net that having the firmware write to the MCU >>>>> flash is a bad idea. >>>>> >>>>> Experiences? Opinions? >>>>> >>>>> Cheers >>>>> >>>>> Phil Hobbs >>>>> >>>> >>>> There's EEPROM emulation code out there for that MCU. It should work >>>> okay, >>>> provided you don't need smooth functioning to continue during the >>>> write and >>>> are not too tight on the code space so that granularity matters. >>>> >>>> I also note the endurance is claimed to be 200K for that part, which >>>> is not >>>> terrible (typically it's 1,000,000 for a serial EEPROM). >>>> >>>> On the other hand, I think I'd at least consider laying out the PCB >>>> for an I2C >>>> EEPROM such as the AT24xx series. If even one piece of product gets >>>> bricked >>>> that would pay for a lot of 15 cent EEPROMs. >>> >>> Not a bad idea at all. In this case the cal will be pretty stable--the >>> dpot only has 256 steps--so we can avoid that problem by doing the cal >>> once at test time. >>> >> >> Putting a little EEPROM on the board is often the simplest solution. It >> is entirely /possible/ to store configuration data along with program >> code on most microcontrollers, but it can be complicated. You typically >> have to pause processing while programming, and you might not be able to >> erase the segment for the configuration without also erasing the main >> program. >> >> Keep the program flash for programs, and write it when you are updating >> the software. Use a small data EEPROM for the data. It keeps >> everything clear and neat - saving significantly on development costs >> for the price of a tiny chip. > > This is why I like FPGAs. Real time in FPGAs is "REAL TIME" and you don't even need to think much about it. Trying to simulate real time functions on an MCU with interrupts is a PITA. With FPGAs you can just focus on the problem, rather that the limitations of the solution. > > Rick C. >FPGAs and MCUs have their advantages and disadvantages. He has a microcontroller for a few dollars and maybe a cm² of board space, and adding an EEPROM means perhaps twenty cents, six mm², and a 100 lines of code. How would changing this to an FPGA affect board complexity, price, development time? Let's assume - to be realistic - that the OP or his group are happy with microcontroller development but inexperienced with FPGAs. Sometimes FPGAs /are/ the right answer. And for some things, either FPGAs or microcontrollers are good choices, so you use the solutions you are familiar with. But this is not a case for an FPGA.
Reply by ●January 27, 20192019-01-27
On Sun, 27 Jan 2019 08:25:35 GMT, <698839253X6D445TD@nospam.org> wrote:>gnuarm wrote >>Not sure what a Dino is, > > https://en.wikipedia.org/wiki/Dinosaur >dinosaur are extinct >The story goes, because those were so big, that if one was bitten in the tail it took >almost a second for the nerve signal to reach the brain and be processed, >making those an easy victim for other animals and human hunters. > > >>but your idea of dedicating a sector per data record >>is poor in the extreme. Sectors on Flash are not very reliable. It is a >>good idea to have a flash file system to manage the good/bad blocks for you. >> I guess you can do that yourself, but are you thinking of that? > >No, bad sector handling is done by the SDcard firmware >we are talking about SDcards for data storage.Flash is so cheap, write a few copies of everything and use whichever has a good checksum. -- John Larkin Highland Technology, Inc lunatic fringe electronics
Reply by ●January 27, 20192019-01-27
On Sun, 27 Jan 2019 15:27:12 +0100, David Brown <david.brown@hesbynett.no> wrote:>On 26/01/2019 00:24, gnuarm.deletethisbit@gmail.com wrote: >> On Friday, January 25, 2019 at 2:12:13 AM UTC-5, David Brown wrote: >>> On 25/01/2019 02:47, Phil Hobbs wrote: >>>> On 1/24/19 3:59 PM, speff wrote: >>>>> On Thursday, 24 January 2019 10:25:20 UTC-5, Phil Hobbs� wrote: >>>>>> So we've got this custom product that includes a voltage-controlled >>>>>> amplifier. >>>>>> >>>>>> VCA chips as used in ultrasound and so on have nice low noise at the >>>>>> highest gains, but at low gain they stink on ice.� The same is true of >>>>>> all transconductance-based VCAs unless you use a zillion stages. >>>>>> >>>>>> Sooo, we're faking it with a dpot, an op amp with a mux-controlled >>>>>> resistor ladder, and an LPC804 Cortex M0+. >>>>>> >>>>>> The resistor ladder is made out of standard-value Susumu 25-ppm >>>>>> resistors, so it's better than the dpot except that the switchable gains >>>>>> aren't exactly powers of two. >>>>>> >>>>>> The simple way of handling this is to have the thing self-calibrate. >>>>>> That could be done at power-up and the cal table kept in RAM, or at test >>>>>> time with the table in flash. >>>>>> >>>>>> There's some lore on the net that having the firmware write to the MCU >>>>>> flash is a bad idea. >>>>>> >>>>>> Experiences? Opinions? >>>>>> >>>>>> Cheers >>>>>> >>>>>> Phil Hobbs >>>>>> >>>>> >>>>> There's EEPROM emulation code out there for that MCU. It should work >>>>> okay, >>>>> provided you don't need smooth functioning to continue during the >>>>> write and >>>>> are not too tight on the code space so that granularity matters. >>>>> >>>>> I also note the endurance is claimed to be 200K for that part, which >>>>> is not >>>>> terrible (typically it's 1,000,000 for a serial EEPROM). >>>>> >>>>> On the other hand, I think I'd at least consider laying out the PCB >>>>> for an I2C >>>>> EEPROM such as the AT24xx series. If even one piece of product gets >>>>> bricked >>>>> that would pay for a lot of 15 cent EEPROMs. >>>> >>>> Not a bad idea at all.� In this case the cal will be pretty stable--the >>>> dpot only has 256 steps--so we can avoid that problem by doing the cal >>>> once at test time. >>>> >>> >>> Putting a little EEPROM on the board is often the simplest solution. It >>> is entirely /possible/ to store configuration data along with program >>> code on most microcontrollers, but it can be complicated. You typically >>> have to pause processing while programming, and you might not be able to >>> erase the segment for the configuration without also erasing the main >>> program. >>> >>> Keep the program flash for programs, and write it when you are updating >>> the software. Use a small data EEPROM for the data. It keeps >>> everything clear and neat - saving significantly on development costs >>> for the price of a tiny chip. >> >> This is why I like FPGAs. Real time in FPGAs is "REAL TIME" and you don't even need to think much about it. Trying to simulate real time functions on an MCU with interrupts is a PITA. With FPGAs you can just focus on the problem, rather that the limitations of the solution. >> >> Rick C. >> > >FPGAs and MCUs have their advantages and disadvantages. > >He has a microcontroller for a few dollars and maybe a cm� of board >space, and adding an EEPROM means perhaps twenty cents, six mm�, and a >100 lines of code. How would changing this to an FPGA affect board >complexity, price, development time? Let's assume - to be realistic - >that the OP or his group are happy with microcontroller development but >inexperienced with FPGAs. > >Sometimes FPGAs /are/ the right answer. And for some things, either >FPGAs or microcontrollers are good choices, so you use the solutions you >are familiar with. But this is not a case for an FPGA. >We have advocates for running soft-core low-performance 8-bit CPUs inside FPGAs, microBlaze and such, but it doesn't make sense to me. It would take a new infrastructure (compilers, libraries, debug). RAM is expensive inside an FPGA, external DRAM is a big deal, and separete ARM chips are cheap. The advantage of an internal CPU is that one (might maybe) save pins and (might maybe) do a synchronous interface from uP to fabric. External ARM to FPGA interfaces tend to be async, which is emotionally distasteful but not a big deal in real life. One could even go SPI. SOCs, an FPGA with a hard ARM core or two, are getting cheap. Embedded c and VHDL are sort of different cultures. -- John Larkin Highland Technology, Inc lunatic fringe electronics
Reply by ●January 27, 20192019-01-27
On 27/01/2019 16:52, John Larkin wrote:> On Sun, 27 Jan 2019 15:27:12 +0100, David Brown > <david.brown@hesbynett.no> wrote: > >> On 26/01/2019 00:24, gnuarm.deletethisbit@gmail.com wrote: >>> On Friday, January 25, 2019 at 2:12:13 AM UTC-5, David Brown wrote: >>>> On 25/01/2019 02:47, Phil Hobbs wrote: >>>>> On 1/24/19 3:59 PM, speff wrote: >>>>>> On Thursday, 24 January 2019 10:25:20 UTC-5, Phil Hobbs wrote: >>>>>>> So we've got this custom product that includes a voltage-controlled >>>>>>> amplifier. >>>>>>> >>>>>>> VCA chips as used in ultrasound and so on have nice low noise at the >>>>>>> highest gains, but at low gain they stink on ice. The same is true of >>>>>>> all transconductance-based VCAs unless you use a zillion stages. >>>>>>> >>>>>>> Sooo, we're faking it with a dpot, an op amp with a mux-controlled >>>>>>> resistor ladder, and an LPC804 Cortex M0+. >>>>>>> >>>>>>> The resistor ladder is made out of standard-value Susumu 25-ppm >>>>>>> resistors, so it's better than the dpot except that the switchable gains >>>>>>> aren't exactly powers of two. >>>>>>> >>>>>>> The simple way of handling this is to have the thing self-calibrate. >>>>>>> That could be done at power-up and the cal table kept in RAM, or at test >>>>>>> time with the table in flash. >>>>>>> >>>>>>> There's some lore on the net that having the firmware write to the MCU >>>>>>> flash is a bad idea. >>>>>>> >>>>>>> Experiences? Opinions? >>>>>>> >>>>>>> Cheers >>>>>>> >>>>>>> Phil Hobbs >>>>>>> >>>>>> >>>>>> There's EEPROM emulation code out there for that MCU. It should work >>>>>> okay, >>>>>> provided you don't need smooth functioning to continue during the >>>>>> write and >>>>>> are not too tight on the code space so that granularity matters. >>>>>> >>>>>> I also note the endurance is claimed to be 200K for that part, which >>>>>> is not >>>>>> terrible (typically it's 1,000,000 for a serial EEPROM). >>>>>> >>>>>> On the other hand, I think I'd at least consider laying out the PCB >>>>>> for an I2C >>>>>> EEPROM such as the AT24xx series. If even one piece of product gets >>>>>> bricked >>>>>> that would pay for a lot of 15 cent EEPROMs. >>>>> >>>>> Not a bad idea at all. In this case the cal will be pretty stable--the >>>>> dpot only has 256 steps--so we can avoid that problem by doing the cal >>>>> once at test time. >>>>> >>>> >>>> Putting a little EEPROM on the board is often the simplest solution. It >>>> is entirely /possible/ to store configuration data along with program >>>> code on most microcontrollers, but it can be complicated. You typically >>>> have to pause processing while programming, and you might not be able to >>>> erase the segment for the configuration without also erasing the main >>>> program. >>>> >>>> Keep the program flash for programs, and write it when you are updating >>>> the software. Use a small data EEPROM for the data. It keeps >>>> everything clear and neat - saving significantly on development costs >>>> for the price of a tiny chip. >>> >>> This is why I like FPGAs. Real time in FPGAs is "REAL TIME" and you don't even need to think much about it. Trying to simulate real time functions on an MCU with interrupts is a PITA. With FPGAs you can just focus on the problem, rather that the limitations of the solution. >>> >>> Rick C. >>> >> >> FPGAs and MCUs have their advantages and disadvantages. >> >> He has a microcontroller for a few dollars and maybe a cm² of board >> space, and adding an EEPROM means perhaps twenty cents, six mm², and a >> 100 lines of code. How would changing this to an FPGA affect board >> complexity, price, development time? Let's assume - to be realistic - >> that the OP or his group are happy with microcontroller development but >> inexperienced with FPGAs. >> >> Sometimes FPGAs /are/ the right answer. And for some things, either >> FPGAs or microcontrollers are good choices, so you use the solutions you >> are familiar with. But this is not a case for an FPGA. >> > > We have advocates for running soft-core low-performance 8-bit CPUs > inside FPGAs, microBlaze and such, but it doesn't make sense to me. It > would take a new infrastructure (compilers, libraries, debug). RAM is > expensive inside an FPGA, external DRAM is a big deal, and separete > ARM chips are cheap. >Agreed. I don't think cpus on an FPGA make any sense unless you need the FPGA anyway, and even then it is usually simpler and cheaper to use an external microcontroller. As you say, development of microcontroller stuff and FPGA stuff is mostly a different culture, and the whole project will be simpler to do and easier to manage if they are mostly separate. It's a different matter if you have special requirements for the integration - FPGA acceleration of cpu instructions, tightly coupled peripherals, etc.> The advantage of an internal CPU is that one (might maybe) save pins > and (might maybe) do a synchronous interface from uP to fabric. > External ARM to FPGA interfaces tend to be async, which is emotionally > distasteful but not a big deal in real life. One could even go SPI. > > SOCs, an FPGA with a hard ARM core or two, are getting cheap. > > Embedded c and VHDL are sort of different cultures. > > > >
Reply by ●January 27, 20192019-01-27
søndag den 27. januar 2019 kl. 18.00.53 UTC+1 skrev David Brown:> On 27/01/2019 16:52, John Larkin wrote: > > On Sun, 27 Jan 2019 15:27:12 +0100, David Brown > > <david.brown@hesbynett.no> wrote: > > > >> On 26/01/2019 00:24, gnuarm.deletethisbit@gmail.com wrote: > >>> On Friday, January 25, 2019 at 2:12:13 AM UTC-5, David Brown wrote: > >>>> On 25/01/2019 02:47, Phil Hobbs wrote: > >>>>> On 1/24/19 3:59 PM, speff wrote: > >>>>>> On Thursday, 24 January 2019 10:25:20 UTC-5, Phil Hobbs wrote: > >>>>>>> So we've got this custom product that includes a voltage-controlled > >>>>>>> amplifier. > >>>>>>> > >>>>>>> VCA chips as used in ultrasound and so on have nice low noise at the > >>>>>>> highest gains, but at low gain they stink on ice. The same is true of > >>>>>>> all transconductance-based VCAs unless you use a zillion stages. > >>>>>>> > >>>>>>> Sooo, we're faking it with a dpot, an op amp with a mux-controlled > >>>>>>> resistor ladder, and an LPC804 Cortex M0+. > >>>>>>> > >>>>>>> The resistor ladder is made out of standard-value Susumu 25-ppm > >>>>>>> resistors, so it's better than the dpot except that the switchable gains > >>>>>>> aren't exactly powers of two. > >>>>>>> > >>>>>>> The simple way of handling this is to have the thing self-calibrate. > >>>>>>> That could be done at power-up and the cal table kept in RAM, or at test > >>>>>>> time with the table in flash. > >>>>>>> > >>>>>>> There's some lore on the net that having the firmware write to the MCU > >>>>>>> flash is a bad idea. > >>>>>>> > >>>>>>> Experiences? Opinions? > >>>>>>> > >>>>>>> Cheers > >>>>>>> > >>>>>>> Phil Hobbs > >>>>>>> > >>>>>> > >>>>>> There's EEPROM emulation code out there for that MCU. It should work > >>>>>> okay, > >>>>>> provided you don't need smooth functioning to continue during the > >>>>>> write and > >>>>>> are not too tight on the code space so that granularity matters. > >>>>>> > >>>>>> I also note the endurance is claimed to be 200K for that part, which > >>>>>> is not > >>>>>> terrible (typically it's 1,000,000 for a serial EEPROM). > >>>>>> > >>>>>> On the other hand, I think I'd at least consider laying out the PCB > >>>>>> for an I2C > >>>>>> EEPROM such as the AT24xx series. If even one piece of product gets > >>>>>> bricked > >>>>>> that would pay for a lot of 15 cent EEPROMs. > >>>>> > >>>>> Not a bad idea at all. In this case the cal will be pretty stable--the > >>>>> dpot only has 256 steps--so we can avoid that problem by doing the cal > >>>>> once at test time. > >>>>> > >>>> > >>>> Putting a little EEPROM on the board is often the simplest solution. It > >>>> is entirely /possible/ to store configuration data along with program > >>>> code on most microcontrollers, but it can be complicated. You typically > >>>> have to pause processing while programming, and you might not be able to > >>>> erase the segment for the configuration without also erasing the main > >>>> program. > >>>> > >>>> Keep the program flash for programs, and write it when you are updating > >>>> the software. Use a small data EEPROM for the data. It keeps > >>>> everything clear and neat - saving significantly on development costs > >>>> for the price of a tiny chip. > >>> > >>> This is why I like FPGAs. Real time in FPGAs is "REAL TIME" and you don't even need to think much about it. Trying to simulate real time functions on an MCU with interrupts is a PITA. With FPGAs you can just focus on the problem, rather that the limitations of the solution. > >>> > >>> Rick C. > >>> > >> > >> FPGAs and MCUs have their advantages and disadvantages. > >> > >> He has a microcontroller for a few dollars and maybe a cm² of board > >> space, and adding an EEPROM means perhaps twenty cents, six mm², and a > >> 100 lines of code. How would changing this to an FPGA affect board > >> complexity, price, development time? Let's assume - to be realistic - > >> that the OP or his group are happy with microcontroller development but > >> inexperienced with FPGAs. > >> > >> Sometimes FPGAs /are/ the right answer. And for some things, either > >> FPGAs or microcontrollers are good choices, so you use the solutions you > >> are familiar with. But this is not a case for an FPGA. > >> > > > > We have advocates for running soft-core low-performance 8-bit CPUs > > inside FPGAs, microBlaze and such, but it doesn't make sense to me. It > > would take a new infrastructure (compilers, libraries, debug). RAM is > > expensive inside an FPGA, external DRAM is a big deal, and separete > > ARM chips are cheap. > > > > Agreed. I don't think cpus on an FPGA make any sense unless you need > the FPGA anyway, and even then it is usually simpler and cheaper to use > an external microcontroller. As you say, development of microcontroller > stuff and FPGA stuff is mostly a different culture, and the whole > project will be simpler to do and easier to manage if they are mostly > separate. It's a different matter if you have special requirements for > the integration - FPGA acceleration of cpu instructions, tightly coupled > peripherals, etc. >one case where it might make sense is if you have slowish state machines for something like setup and want it to be easy to chance by someone who only knows c
Reply by ●January 27, 20192019-01-27
On Sun, 27 Jan 2019 18:00:48 +0100, David Brown <david.brown@hesbynett.no> wrote:>On 27/01/2019 16:52, John Larkin wrote: >> On Sun, 27 Jan 2019 15:27:12 +0100, David Brown >> <david.brown@hesbynett.no> wrote: >> >>> On 26/01/2019 00:24, gnuarm.deletethisbit@gmail.com wrote: >>>> On Friday, January 25, 2019 at 2:12:13 AM UTC-5, David Brown wrote: >>>>> On 25/01/2019 02:47, Phil Hobbs wrote: >>>>>> On 1/24/19 3:59 PM, speff wrote: >>>>>>> On Thursday, 24 January 2019 10:25:20 UTC-5, Phil Hobbs� wrote: >>>>>>>> So we've got this custom product that includes a voltage-controlled >>>>>>>> amplifier. >>>>>>>> >>>>>>>> VCA chips as used in ultrasound and so on have nice low noise at the >>>>>>>> highest gains, but at low gain they stink on ice.� The same is true of >>>>>>>> all transconductance-based VCAs unless you use a zillion stages. >>>>>>>> >>>>>>>> Sooo, we're faking it with a dpot, an op amp with a mux-controlled >>>>>>>> resistor ladder, and an LPC804 Cortex M0+. >>>>>>>> >>>>>>>> The resistor ladder is made out of standard-value Susumu 25-ppm >>>>>>>> resistors, so it's better than the dpot except that the switchable gains >>>>>>>> aren't exactly powers of two. >>>>>>>> >>>>>>>> The simple way of handling this is to have the thing self-calibrate. >>>>>>>> That could be done at power-up and the cal table kept in RAM, or at test >>>>>>>> time with the table in flash. >>>>>>>> >>>>>>>> There's some lore on the net that having the firmware write to the MCU >>>>>>>> flash is a bad idea. >>>>>>>> >>>>>>>> Experiences? Opinions? >>>>>>>> >>>>>>>> Cheers >>>>>>>> >>>>>>>> Phil Hobbs >>>>>>>> >>>>>>> >>>>>>> There's EEPROM emulation code out there for that MCU. It should work >>>>>>> okay, >>>>>>> provided you don't need smooth functioning to continue during the >>>>>>> write and >>>>>>> are not too tight on the code space so that granularity matters. >>>>>>> >>>>>>> I also note the endurance is claimed to be 200K for that part, which >>>>>>> is not >>>>>>> terrible (typically it's 1,000,000 for a serial EEPROM). >>>>>>> >>>>>>> On the other hand, I think I'd at least consider laying out the PCB >>>>>>> for an I2C >>>>>>> EEPROM such as the AT24xx series. If even one piece of product gets >>>>>>> bricked >>>>>>> that would pay for a lot of 15 cent EEPROMs. >>>>>> >>>>>> Not a bad idea at all.� In this case the cal will be pretty stable--the >>>>>> dpot only has 256 steps--so we can avoid that problem by doing the cal >>>>>> once at test time. >>>>>> >>>>> >>>>> Putting a little EEPROM on the board is often the simplest solution. It >>>>> is entirely /possible/ to store configuration data along with program >>>>> code on most microcontrollers, but it can be complicated. You typically >>>>> have to pause processing while programming, and you might not be able to >>>>> erase the segment for the configuration without also erasing the main >>>>> program. >>>>> >>>>> Keep the program flash for programs, and write it when you are updating >>>>> the software. Use a small data EEPROM for the data. It keeps >>>>> everything clear and neat - saving significantly on development costs >>>>> for the price of a tiny chip. >>>> >>>> This is why I like FPGAs. Real time in FPGAs is "REAL TIME" and you don't even need to think much about it. Trying to simulate real time functions on an MCU with interrupts is a PITA. With FPGAs you can just focus on the problem, rather that the limitations of the solution. >>>> >>>> Rick C. >>>> >>> >>> FPGAs and MCUs have their advantages and disadvantages. >>> >>> He has a microcontroller for a few dollars and maybe a cm� of board >>> space, and adding an EEPROM means perhaps twenty cents, six mm�, and a >>> 100 lines of code. How would changing this to an FPGA affect board >>> complexity, price, development time? Let's assume - to be realistic - >>> that the OP or his group are happy with microcontroller development but >>> inexperienced with FPGAs. >>> >>> Sometimes FPGAs /are/ the right answer. And for some things, either >>> FPGAs or microcontrollers are good choices, so you use the solutions you >>> are familiar with. But this is not a case for an FPGA. >>> >> >> We have advocates for running soft-core low-performance 8-bit CPUs >> inside FPGAs, microBlaze and such, but it doesn't make sense to me. It >> would take a new infrastructure (compilers, libraries, debug). RAM is >> expensive inside an FPGA, external DRAM is a big deal, and separete >> ARM chips are cheap. >> > >Agreed. I don't think cpus on an FPGA make any sense unless you need >the FPGA anyway, and even then it is usually simpler and cheaper to use >an external microcontroller. As you say, development of microcontroller >stuff and FPGA stuff is mostly a different culture, and the whole >project will be simpler to do and easier to manage if they are mostly >separate. It's a different matter if you have special requirements for >the integration - FPGA acceleration of cpu instructions, tightly coupled >peripherals, etc. >We often move the boundary between hardware/VHDL and c code. Like on one recent project, we want to report RMS voltage, based on samples from a unipolar ADC. Part of the math (subtract the DC baseline, square, sum a bunch of squares) is done in the FPGA. Some (compute the offset, process the sum of squares, scale and calibrate) is c. That was whiteboard negotiated. There are some synchronous detectors that work about the same way, part hardware and part code. I would have moved the offset calculation into the FPGA. We haven't done any floats in an FPGA, but people tell me it can be done. Our preferred ARM has hardware vector FP. Actually, I think the sum-of-squares is floated by the FPGA before it's presented to the ARM. -- John Larkin Highland Technology, Inc lunatic fringe electronics
