fredag den 25. januar 2019 kl. 02.47.41 UTC+1 skrev Phil Hobbs:> 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. >if you only need it at test time you could just patch hex file and reprogram once you know the right values
Writing to MCU flash
Started by ●January 24, 2019
Reply by ●January 24, 20192019-01-24
Reply by ●January 25, 20192019-01-25
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.
Reply by ●January 25, 20192019-01-25
On 1/24/19 9:40 PM, Lasse Langwadt Christensen wrote:> fredag den 25. januar 2019 kl. 02.47.41 UTC+1 skrev Phil Hobbs: >> 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. >> > > if you only need it at test time you could just patch hex file and reprogram > once you know the right valuesThat's too much like work. There's space in the flash for the calibration code and the table (the basic program is pretty simple--read the control voltage from the ADC, do a table interpolation to get the gain, write to the dpot and mux. Lather rinse repeat. There's a power-up offset check and a gain calibration, which are both done in firmware. Thanks 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 25, 20192019-01-25
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. + Get 6 months of free supercharging + Tesla referral code - https://ts.la/richard11209
Reply by ●January 26, 20192019-01-26
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.
Reply by ●January 26, 20192019-01-26
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.> >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.-- John Larkin Highland Technology, Inc lunatic fringe electronics
Reply by ●January 26, 20192019-01-26
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?
Reply by ●January 26, 20192019-01-26
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. -- John Larkin Highland Technology, Inc lunatic fringe electronics
Reply by ●January 26, 20192019-01-26
John Larkin wrote>On Sat, 26 Jan 2019 19:10:26 GMT, <698839253X6D445TD@nospam.org> >wrote: >>How is the boot-time of that Zync thing? > >I seem to recall a console prompt in a second or two.That is very very good, my core i5 laptop running slackware linux takes so long you can get coffee in that time. It can be better old eeePC with Linux in FLASH boots in maybe 30 seconds.>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.20 us?? or 20 ms??? Task switch normally causes ms size interrupts, depends on what is running of course, Linux is not a real time OS. That big wallclock I have running on a raspberry http://panteltje.com/panteltje/raspberry_pi_FDS132_matrix_display_driver/index.html starts flickering if I run any other task a the same time, and even if I just ssh to it.>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.Yes, way to go.
Reply by ●January 26, 20192019-01-26
On Sat, 26 Jan 2019 19:52:33 GMT, <698839253X6D445TD@nospam.org> wrote:>John Larkin wrote >>On Sat, 26 Jan 2019 19:10:26 GMT, <698839253X6D445TD@nospam.org> >>wrote: >>>How is the boot-time of that Zync thing? >> >>I seem to recall a console prompt in a second or two. > >That is very very good, my core i5 laptop running slackware linux >takes so long you can get coffee in that time. >It can be better old eeePC with Linux in FLASH boots in maybe 30 seconds. > >>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. > >20 us?? or 20 ms???Microseconds. The wiggled port, seen on a scope, would sometimes hang high or low for that long; usually for less. And that was when we were bashing a lot of ethernet traffic. I was impressed.>Task switch normally causes ms size interrupts, >depends on what is running of course, Linux is not a real time OS.It does (I've been told) allow one to politely suggest that some processes be run on one CPU core or the other, but the assignamt isn't absolute. We did what we could on the Zynq test.>That big wallclock I have running on a raspberry > http://panteltje.com/panteltje/raspberry_pi_FDS132_matrix_display_driver/index.html >starts flickering if I run any other task a the same time, >and even if I just ssh to it. > > >>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. > >Yes, way to go.-- John Larkin Highland Technology, Inc lunatic fringe electronics
