On 27/01/2019 18:41, John Larkin wrote:> 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.You want to move something that is one line of C code, into FPGA hardware? Unless you are doing sampling at megaherz, that's crazy. Doing /any/ of RMS calculations in hardware is crazy. It is symptomatic of a company dominated by hardware folk and FPGA folk who have always done it this way - starting 20 or 30 years ago when it made sense, and failing to follow with the times since then. (Unless, as I say, you are talking about very high frequency signals.)> > 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. > > > > > >
Writing to MCU flash
Started by ●January 24, 2019
Reply by ●January 27, 20192019-01-27
Reply by ●January 27, 20192019-01-27
On Sun, 27 Jan 2019 09:17:09 -0800 (PST), Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:>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 cThe c is usually much easier to change than recompiling the FPGA. We have avoided some interesting FPGA families because we couldn't even get the demo tools to run. FPGA tools are usually tangled in FlexLM horrors, whereas the c suite is public domain. c builds take seconds, and FPGA builds take hours. c builds are command-line driven, whereas most FPGA tools are click driven. It's hard to archive clicks. -- John Larkin Highland Technology, Inc lunatic fringe electronics
Reply by ●January 27, 20192019-01-27
On Sun, 27 Jan 2019 18:47:59 +0100, David Brown <david.brown@hesbynett.no> wrote:>On 27/01/2019 18:41, John Larkin wrote: >> 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. > >You want to move something that is one line of C code, into FPGA >hardware? Unless you are doing sampling at megaherz, that's crazy.The two relevant products have 12 and 24 each of 16-bit ADCs, each ADC sampling at 500 KHz. 12 million subtract-square-accumulates per second might be done on the ARM, but that would dominate things. My c guy doesn't like pushing realtime cpu performance to the limits, which is a reasonable attitude.>Doing /any/ of RMS calculations in hardware is crazy.It's not crazy, and it works. My FPGA guys tell me that there are reasonable provisions in modern FPGAs to do math in floats. So far, the only one we have done is the huge-fixed-accumulator-to-float conversion, which was apparently trivial to implement. It is symptomatic>of a company dominated by hardware folk and FPGA folk who have always >done it this way - starting 20 or 30 years ago when it made sense, and >failing to follow with the times since then. (Unless, as I say, you are >talking about very high frequency signals.)I design the architectures and the hardware. We meet and negotiate between PCB hardware, FPGA functions, and what the ARM will do. It's fun and it works. c hasn't changed much in decades. FPGAs sure have.> >> >> 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
Reply by ●January 27, 20192019-01-27
John Larkin>The c is usually much easier to change than recompiling the FPGA. We >have avoided some interesting FPGA families because we couldn't even >get the demo tools to run. FPGA tools are usually tangled in FlexLM >horrors, whereas the c suite is public domain. > >c builds take seconds, and FPGA builds take hours. > >c builds are command-line driven, whereas most FPGA tools are click >driven. It's hard to archive clicks.Yes, although... I have used iverilog (Icarus Verilog command line verilog compiler) for Xilinx, http://iverilog.icarus.com/ and verilog 'style' is much like C It has been a while but I did that xilinx thing on Linux from the command line too: http://panteltje.com/panteltje/fpga/index.html a very very long time ago...
Reply by ●January 27, 20192019-01-27
David Brown wrote>You want to move something that is one line of C code, into FPGA >hardware? Unless you are doing sampling at megaherz, that's crazy. >Doing /any/ of RMS calculations in hardware is crazy. It is symptomatic >of a company dominated by hardware folk and FPGA folk who have always >done it this way - starting 20 or 30 years ago when it made sense, and >failing to follow with the times since then. (Unless, as I say, you are >talking about very high frequency signals.)No it is often a much better way. The problem with your 'one line of C code' is that you have no clue about the underlying hardware and bringing in whole libraries and tons of code with their bugs and unknowns to do something that can be done in a few lines of asm / verilog / whatever hdl, THERE is exactly the current problem with bloat. And cluelessness build on cluelessness until we have the CEO using the 'I want' app say a food company CEO now in control of an airplane manufacturing plant dictating his latest brainfart and there you have it, It won't fly. Or a reality show host .. well you guessed it. Freaking hell a 32 bit square root in PIC asm is only a few lines man. Your freaking compiler of whatever kind can _never_ do better.
Reply by ●January 27, 20192019-01-27
søndag den 27. januar 2019 kl. 19.35.06 UTC+1 skrev 69883925...@nospam.org:> John Larkin > >The c is usually much easier to change than recompiling the FPGA. We > >have avoided some interesting FPGA families because we couldn't even > >get the demo tools to run. FPGA tools are usually tangled in FlexLM > >horrors, whereas the c suite is public domain. > > > >c builds take seconds, and FPGA builds take hours. > > > >c builds are command-line driven, whereas most FPGA tools are click > >driven. It's hard to archive clicks. > > Yes, although... > > I have used iverilog (Icarus Verilog command line verilog compiler) for Xilinx, > http://iverilog.icarus.com/it is pretty much only for simulation> and verilog 'style' is much like Cbut you have to think very differently> It has been a while but I did that xilinx thing on Linux from the command line too: > http://panteltje.com/panteltje/fpga/index.html > a very very long time ago...you can still run the Xilinx tools from a command line if you want to
Reply by ●January 27, 20192019-01-27
On Sun, 27 Jan 2019 10:44:10 -0800 (PST), Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:>s�ndag den 27. januar 2019 kl. 19.35.06 UTC+1 skrev 69883925...@nospam.org: >> John Larkin >> >The c is usually much easier to change than recompiling the FPGA. We >> >have avoided some interesting FPGA families because we couldn't even >> >get the demo tools to run. FPGA tools are usually tangled in FlexLM >> >horrors, whereas the c suite is public domain. >> > >> >c builds take seconds, and FPGA builds take hours. >> > >> >c builds are command-line driven, whereas most FPGA tools are click >> >driven. It's hard to archive clicks. >> >> Yes, although... >> >> I have used iverilog (Icarus Verilog command line verilog compiler) for Xilinx, >> http://iverilog.icarus.com/ > >it is pretty much only for simulation > >> and verilog 'style' is much like C > >but you have to think very differently > >> It has been a while but I did that xilinx thing on Linux from the command line too: >> http://panteltje.com/panteltje/fpga/index.html >> a very very long time ago... > >you can still run the Xilinx tools from a command line if you want toWe do, and I'm told that it's difficult. -- John Larkin Highland Technology, Inc lunatic fringe electronics
Reply by ●January 27, 20192019-01-27
On 1/26/19 2:38 PM, John Larkin wrote:> On Sat, 26 Jan 2019 19:10:26 GMT, <698839253X6D445TD@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? > > I seem to recall a console prompt in a second or two. > > We did some tests to see how much a tight loop (wiggling a port pin) > might be suspended by Linux system interrupts. On the dual-core Zynq > chip, we never saw a timeout over 20 us. > > It's possible to run Linux on one core and bare metal on the other. > But we just move time-critical stuff into FPGA fabric. > >In the minimalist world of my original post, the LPC804 has a useful number of CPLD macrocells available for simple stuff that needs hardware timing. We haven't used it for anything yet. Super nice little chip altogether. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
Reply by ●January 27, 20192019-01-27
Lasse Langwadt Christensen <f412e2c3-a514-4be9-abfc-c83f19ca69b2@googlegroups.com>:>s=C3=B8ndag den 27. januar 2019 kl. 19.35.06 UTC+1 skrev 69883925...@nospam.org: >> I have used iverilog (Icarus Verilog command line verilog compiler) for Xilinx, >> > http://iverilog.icarus.com/ > >it is pretty much only for simulationIIRC he did output for impact, but it was many years ago, not sure he followed up on tha tfor the later FPGAs>> and verilog 'style' is much like C > >but you have to think very differentlyI still think whatever I like, its a free world up there ;-)>> It has been a while but I did that xilinx thing on Linux from the command >line too: >> http://panteltje.com/panteltje/fpga/index.html >> a very very long time ago... > >you can still run the Xilinx tools from a command line if you want toGood.
Reply by ●January 27, 20192019-01-27
On 1/27/19 10:41 AM, John Larkin wrote:> 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. > >We're looking into littleFS for data logging on a system whose power can be disconnected at any time. It's a fire detection/suppression system for cotton harvesters, and we're facing large, rapidly fluctuating background signals due e.g. to sunlight bouncing off rapidly moving cotton and machinery, so we need to do a bunch of data logging and data mining and stuff to develop good algorithms. (The actual fire detection algorithm relies on MWIR detectors and is rock-solid--it's the SWIR spark detection technique that's more difficult.) Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
