On 28/01/2019 09:27, Tom Gardner wrote:> On 28/01/19 06:30, David Brown wrote: >> People who write C code professionally usually know what their lines >> of code do. > > Older people in the embedded world, yes. Younger people > in other fields - sometimes :( >We are talking about a single subtraction in this case. Most C programmers will know what that does. I agree that many programmers don't know all the details of what they are doing, and especially they don't know about everything that happens underneath. That is the whole point of abstraction layers - and it means people can do their work without knowing /everything/. (I am the kind of person that /does/ like to know everything, which is one reason I like small systems embedded programming. But I also appreciate when it doesn't matter - my PC programming is mostly in Python.)> I've seen too many that only have a vague concept of > what a cache is. And even getting them to outline what > a processor does during an unoptimised subroutine call > can be like pulling teeth. > > PEBCAK in a stark form. > > >> /Anything/ is better than doing PIC assembly. > > I once looked at a PIC's assembler, and thought > "life is too short". >I have programmed PIC assembly. Your conclusion is correct.
Writing to MCU flash
Started by ●January 24, 2019
Reply by ●January 28, 20192019-01-28
Reply by ●January 28, 20192019-01-28
David Brown wondered>>>>> On 27/01/2019 19:34, 698839253X6D445TD@nospam.org wrote:>>> David Brown wrote >> Make a positive contribution to 'tronics publish some code and projects, I have always done that, >> even this newsreader, written in C, you could actually learn some basic programming principles from.------------^^^^^^^^^^>> The list is endless and there are many projects on my site, many need updating but I am busy now with new stuff. >> > >What newsletter?I hope your C reading skills are better than your text reading skills? http://panteltje.com/panteltje/newsflex/index.html very old code, but sort of maintained used everyday, see headers.>What site? I am highly sceptical to the idea that >your site could teach me any "basic programming principles", but I will >reserve final judgement until seeing it.http://panteltje.com/index1.html>> Have fun. >> >> PS I have a little challenge for you on a PIC 18F14K22 if >> you think you are so good in embedded (use any language you like) >> ? >> But it must work (mine does) OK? > >Challenge not accepted. It would be like challenging someone to a rally >race and saying they can use any car they want, as long as it is a Model >T Ford.Pussy. I really think you should look up an 18F14K22 datasheet. :-) http://panteltje.com/panteltje/newsflex/download.html http://panteltje.com/panteltje/pic/index.html Your turn.
Reply by ●January 28, 20192019-01-28
On 28/01/2019 10:56, 698839253X6D445TD@nospam.org wrote:> David Brown wondered >>>>>> On 27/01/2019 19:34, 698839253X6D445TD@nospam.org wrote:>>> David Brown wrote >>> Make a positive contribution to 'tronics publish some code and projects, I have always done that, >>> even this newsreader, written in C, you could actually learn some basic programming principles from. > ------------^^^^^^^^^^ >>> The list is endless and there are many projects on my site, many need updating but I am busy now with new stuff. >>> >> >> What newsletter? > I hope your C reading skills are better than your text reading skills?You did not include such a link in any of the posts in this thread. Do you expect me to dig through old posts to try to find it?> http://panteltje.com/panteltje/newsflex/index.html > very old code, but sort of maintained used everyday, see headers.I have had a quick glance at a couple of files. No, I have nothing to learn here - the style is horrendous. (It is not the worst I have seen, of course.) There was never a time when code written like that was good style, no matter how old it is.> >> What site? I am highly sceptical to the idea that >> your site could teach me any "basic programming principles", but I will >> reserve final judgement until seeing it. > http://panteltje.com/index1.html > > >>> Have fun. >>> >>> PS I have a little challenge for you on a PIC 18F14K22 if >>> you think you are so good in embedded (use any language you like) >>> ? >>> But it must work (mine does) OK? >> >> Challenge not accepted. It would be like challenging someone to a rally >> race and saying they can use any car they want, as long as it is a Model >> T Ford. > > Pussy. > > I really think you should look up an 18F14K22 datasheet. > > :-)I have read the datasheets of other PIC devices, including the 18xx families. I am very glad that I don't have to program those monstrosities. (There are many nice things about some of the PIC devices - they can, for example, be extraordinarily robust and reliable. But they are not nice for programming.)> > http://panteltje.com/panteltje/newsflex/download.html > http://panteltje.com/panteltje/pic/index.html > > Your turn. >Nope.
Reply by ●January 28, 20192019-01-28
David Brown uttered>On 28/01/2019 10:56, 698839253X6D445TD@nospam.org wrote: >> David Brown wondered >>>>>>> On 27/01/2019 19:34, 698839253X6D445TD@nospam.org wrote:>>> David Brown wrote >>>> Make a positive contribution to 'tronics publish some code and projects, I have always done that, >>>> even this newsreader, written in C, you could actually learn some basic programming principles from. >> ------------^^^^^^^^^^ >>>> The list is endless and there are many projects on my site, many need updating but I am busy now with new stuff. >>>> >>> >>> What newsletter? >> I hope your C reading skills are better than your text reading skills? > >You did not include such a link in any of the posts in this thread. Do >you expect me to dig through old posts to try to find it?Man you are confused, newsreader versus newsletter ?>> http://panteltje.com/panteltje/newsflex/index.html >> very old code, but sort of maintained used everyday, see headers. > >I have had a quick glance at a couple of files. No, I have nothing to >learn here - the style is horrendous. (It is not the worst I have seen, >of course.) There was never a time when code written like that was good >style, no matter how old it is.Well I can understand it is a bit overwhelming for a starter. Usually takes me some minutes to read up too when I want to modify things..>>>> PS I have a little challenge for you on a PIC 18F14K22 if >>>> you think you are so good in embedded (use any language you like) >>>> ? >>>> But it must work (mine does) OK? >>> >>> Challenge not accepted. It would be like challenging someone to a rally >>> race and saying they can use any car they want, as long as it is a Model >>> T Ford. >> >> Pussy. >> >> I really think you should look up an 18F14K22 datasheet. >> >> :-) > >I have read the datasheets of other PIC devices, including the 18xx >families. I am very glad that I don't have to program those monstrosities. > >(There are many nice things about some of the PIC devices - they can, >for example, be extraordinarily robust and reliable. But they are not >nice for programming.)*Your* view of programming I presume. PICs are simple, those older ones had banks, but so did 8051 etc, making things a bit more complicated perhaps. The instruction set is very efficient, and a lot more instructions than C while case if else some pointers etc ... what more do you want? Z80 was nice too with many instructions some undocumented at that. An old saying over here in this country goes something like: 'what the farmer does not know he does not eat'. Tronics and all those micros is a life long study, walking with keeping your eyes shut is not a smart thing to do.>> Your turn. >> > >Nope.As expected.
Reply by ●January 28, 20192019-01-28
On 1/28/19 1:08 AM, David Brown wrote:> On 27/01/2019 19:44, Lasse Langwadt Christensen 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 >> > > People who say that Verilog is like C (and/or that VHDL is like Ada) > usually have very little experience of either language, and certainly > not of both.Verilog is like C in that it's concise, whereas VHDL is verbose like COBOL. (I think VHDL source looks hideous.) 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 https://hobbs-eo.com
Reply by ●January 28, 20192019-01-28
On 28/01/2019 15:38, 698839253X6D445TD@nospam.org wrote:> David Brown uttered >> On 28/01/2019 10:56, 698839253X6D445TD@nospam.org wrote: >>> David Brown wondered >>>>>>>> On 27/01/2019 19:34, 698839253X6D445TD@nospam.org wrote:>>> David Brown wrote >>>>> Make a positive contribution to 'tronics publish some code and projects, I have always done that, >>>>> even this newsreader, written in C, you could actually learn some basic programming principles from. >>> ------------^^^^^^^^^^ >>>>> The list is endless and there are many projects on my site, many need updating but I am busy now with new stuff. >>>>> >>>> >>>> What newsletter? >>> I hope your C reading skills are better than your text reading skills? >> >> You did not include such a link in any of the posts in this thread. Do >> you expect me to dig through old posts to try to find it? > > Man you are confused, newsreader versus newsletter ?Yes, I misread "newsreader" for "newsletter". I had assumed that you were talking about a "newsletter" of some kind discussing programming.> >>> http://panteltje.com/panteltje/newsflex/index.html >>> very old code, but sort of maintained used everyday, see headers. >> >> I have had a quick glance at a couple of files. No, I have nothing to >> learn here - the style is horrendous. (It is not the worst I have seen, >> of course.) There was never a time when code written like that was good >> style, no matter how old it is. > > Well I can understand it is a bit overwhelming for a starter. > Usually takes me some minutes to read up too when I want to modify things.. >I am not a beginner at programming - but I can see that you hadn't learned much about reliable coding before writing that jumble. You should learn a little about interfaces and implementations, and how to write them in C.> > >>>>> PS I have a little challenge for you on a PIC 18F14K22 if >>>>> you think you are so good in embedded (use any language you like) >>>>> ? >>>>> But it must work (mine does) OK? >>>> >>>> Challenge not accepted. It would be like challenging someone to a rally >>>> race and saying they can use any car they want, as long as it is a Model >>>> T Ford. >>> >>> Pussy. >>> >>> I really think you should look up an 18F14K22 datasheet. >>> >>> :-) >> >> I have read the datasheets of other PIC devices, including the 18xx >> families. I am very glad that I don't have to program those monstrosities. >> >> (There are many nice things about some of the PIC devices - they can, >> for example, be extraordinarily robust and reliable. But they are not >> nice for programming.) > > *Your* view of programming I presume. > PICs are simple, those older ones had banks, but so did 8051 etc, > making things a bit more complicated perhaps.The 8051 is braindead too. That does not make the PIC nice.> The instruction set is very efficient, and a lot more instructions > than C while case if else some pointers etc ... > what more do you want? > Z80 was nice too with many instructions some undocumented at that.The Z80 was a great deal more programmer friendly than the PIC or the 8051. (To be fair on the PIC's, the 18xxx series is a big improvement over the 16xxx.)> An old saying over here in this country goes something like: > 'what the farmer does not know he does not eat'. > Tronics and all those micros is a life long study, > walking with keeping your eyes shut is not a smart thing to do. >I'd recommend you open your eyes and see what has happened in the industry in the last 30 years or so. I agree that not all of it is good, but many things have moved forward.>>> Your turn. >>> >> >> Nope. > > As expected. >I write embedded code for a living, not just toys for fun. I don't get to publish my clients' code. But I'd be embarrassed to have something like that newsreader code published in my name.
Reply by ●January 28, 20192019-01-28
David Brown <david.brown@hesbynett.no> wrote:> On 28/01/2019 09:56, 698839253X6D445TD@nospam.org wrote: >> David Brown imagined >>> On 28/01/2019 08:23, 698839253X6D445TD@nospam.org wrote: >>>> David Brown opiniated<snip>>>>>>> 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. >>>>>> >>>>> >>>>> /Anything/ is better than doing PIC assembly. >>>> >>>> That statement proves my point. >>>> >>> >>> It proves that you are stuck in the 80's. >> >> Remarks like that show you should really look for an other job and be easier on humanity, >> >> You know, I spend much of the weekend writing PIC asm, and C code for on the PC. > > No professional developer writes assembly on PICs any more.Careful there. Olin Lathrop's a professional PIC developer who advocates MPASM over C. http://www.embedinc.com/embed.htm>> PS I have a little challenge for you on a PIC 18F14K22 ifInteresting chip. Thank you, -- Don Kuenz KB7RPU There was a young lady named Bright Whose speed was far faster than light; She set out one day In a relative way And returned on the previous night.
Reply by ●January 28, 20192019-01-28
On 28/01/2019 15:59, Phil Hobbs wrote:> On 1/28/19 1:08 AM, David Brown wrote: >> On 27/01/2019 19:44, Lasse Langwadt Christensen 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 >>> >> >> People who say that Verilog is like C (and/or that VHDL is like Ada) >> usually have very little experience of either language, and certainly >> not of both. > > Verilog is like C in that it's concise, whereas VHDL is verbose like > COBOL. (I think VHDL source looks hideous.) >That is at most very vaguely true. Compared to VHDL, Verilog is concise. Compared to other HDL's, it involves swaths of unnecessary extra code and verbose coding. Compared to Ada or COBOL, C can be concise - compared to other languages, it requires lots of extra work.
Reply by ●January 28, 20192019-01-28
On 28/01/2019 16:21, Don Kuenz wrote:> David Brown <david.brown@hesbynett.no> wrote: >> On 28/01/2019 09:56, 698839253X6D445TD@nospam.org wrote: >>> David Brown imagined >>>> On 28/01/2019 08:23, 698839253X6D445TD@nospam.org wrote: >>>>> David Brown opiniated > > <snip> > >>>>>>> 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. >>>>>>> >>>>>> >>>>>> /Anything/ is better than doing PIC assembly. >>>>> >>>>> That statement proves my point. >>>>> >>>> >>>> It proves that you are stuck in the 80's. >>> >>> Remarks like that show you should really look for an other job and be easier on humanity, >>> >>> You know, I spend much of the weekend writing PIC asm, and C code for on the PC. >> >> No professional developer writes assembly on PICs any more. > > Careful there. Olin Lathrop's a professional PIC developer who advocates > MPASM over C. http://www.embedinc.com/embed.htmSo there is a developer who has specialised in PIC assembly, and is stuck with it - or he must admit that his company development model is outdated and playing catch-up with others. OK, virtually no professional developer writes assembly on PICs. Better? People who develop software professionally need to get a sensible return in terms of code development time. They need to write code that is maintainable, comprehensible, and can be transferred to others. You don't get that with assembly. What you get is longer development times (except perhaps for very simple projects) with code that is bound tightly to particular devices, and bound tightly to particular developers. That's okay if you are doing it all for your own fun - you don't care what other people think. But if a customer is paying you to do development, they need to be able to take that code and work further with it, even if you can't or won't do future maintenance work.> > >>> PS I have a little challenge for you on a PIC 18F14K22 if > > Interesting chip. > > > Thank you, >
Reply by ●January 28, 20192019-01-28
On Mon, 28 Jan 2019 07:24:27 +0100, David Brown <david.brown@hesbynett.no> wrote:>On 27/01/2019 19:12, John Larkin wrote: >> 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. > >At that speed, you have justification for using an FPGA (you are doing >12 megasamples/sec). To do it with cpus, you'd need quite a bit one >(Cortex-A, PPC, etc.) rather than a microcontroller. And you'd need to >know what you are doing. (Alternatively, you could go for a big DSP - >but that's almost as ugly as an FPGA.) > >It's hard to get this rate of throughput on a single processor - and be >sure that you are getting everything, all the time (caches give you fast >throughput, but make it really difficult to get real-time guarantees). > >I have no idea about the rest of the design, but my first thoughts here >would be to modularise and handle the channels separately. Handling >/one/ channel with a small Cortex-M4 device should be simple, and give >you easy separation of the analogue signals as well.We did one board that used a uP per channel, partly because each channel had to be electrically isolated. There are 13 CPUs and one FPGA for the VME interface. https://www.dropbox.com/s/ltn64180by6szsw/V220_4.jpg?dl=0 The dinky little channel CPUs each run an ADC-filter-PID-DAC loop at 200 KHz. -- John Larkin Highland Technology, Inc lunatic fringe electronics
