Phil Hobbs wrote>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 HobbsI do a lot of backup either to harddisk, SDcards, or optical disks (Blu-ray). Usually use 'dd', that does a sector by sector copy. But always in the case of sdcards or optical I compare the resulting image. You can do that in Linux with 'diff' but I use something I wrote: dvdimagecmp, as it shows the errors and write speed; http://panteltje.com/panteltje/dvd/dvdimagecmp-0.3.tgz Optical does show read-back errors sometimes, SDcards the same, harddisks never. If you are sort of paranoid you can read back a sector written, compare to the original, retry if you like, but remember in case of a sdcard the real physical sector on the card is not the same as the sector number you wrote. As to cards, their internals, goods and bads, this is worth reading: https://wiki.linaro.org/WorkingGroups/KernelArchived/Projects/FlashCardSurvey?action=show&redirect=WorkingGroups%2FKernel%2FProjects%2FFlashCardSurvey for me that boils down to using a good card, and as the discussion was, writing random sectors is OK, when you get a write error the card is defective as simple as that, the card's micro should map the logical sector number to a physical sector number and show an error if no free physical sector is available, else try the write to an other free sector if it fails internally and update the translation table. For data logging when there is only one source, writing sector by sector without using a filesystem is simpler. There is a lot that can go in a 512 byte sector, I put latitude, longitude, altitude, speed, heading and a few more things in those 512 bytes and have plenty space left. last sector always starts with a 0 byte. Reading back is simple because in Unix a memory device is a file, so use fseek() to the sector, well example code is on my site. Simplicity.
Writing to MCU flash
Started by ●January 24, 2019
Reply by ●January 27, 20192019-01-27
Reply by ●January 28, 20192019-01-28
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.> 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 to >
Reply by ●January 28, 20192019-01-28
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.> >> Doing /any/ of RMS calculations in hardware is crazy. > > It's not crazy, and it works.I did make it clear that megasamples rates were a different matter.> > 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.Sure, it can all be done in an FPGA. I am not questioning if this is possible in an FPGA, merely if it is the sensible way to handle it.> > > > 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.What you can /do/ with C has changed rapidly, especially in the embedded world. The tools have changed dramatically. The language hasn't changed much (it has changed a bit). Kind of like Verilog and VHDL, really.> > >> >>> >>> 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. > > >
Reply by ●January 28, 20192019-01-28
On 27/01/2019 19:34, 698839253X6D445TD@nospam.org wrote:> 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, >You must be thinking of a completely different language - certainly a completely different type of development. People who write C code professionally usually know what their lines of code do.> 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. >Perhaps that all made sense to you when you wrote it - it makes no sense to me.> 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.
Reply by ●January 28, 20192019-01-28
David Brown opiniated>On 27/01/2019 19:34, 698839253X6D445TD@nospam.org wrote: >> 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, >> > >You must be thinking of a completely different language - certainly a >completely different type of development.No>People who write C code professionally usually know what their lines of >code do.No.>> 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. >> > >Perhaps that all made sense to you when you wrote it - it makes no sense >to me.That is possibly where the problem is. I see no 'tronics from you, you almost sound like a sales person for some bloatware that blinds people from the inner working of things,>> 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.
Reply by ●January 28, 20192019-01-28
David Brown opiniated>What you can /do/ with C has changed rapidly, especially in the embedded >world. The tools have changed dramatically. The language hasn't >changed much (it has changed a bit). Kind of like Verilog and VHDL, really.I was thinking all the nonsense written by people like you, as to C (language) the few statements it has, and the many many instructions in for example a PIC (something else you have zero experience with) micro, bit oriented operations, what an idiot one would be to do that in C and then having no clue what the compiler does with it make very inefficient use of the hardware,
Reply by ●January 28, 20192019-01-28
On 28/01/2019 08:23, 698839253X6D445TD@nospam.org wrote:> David Brown opiniated >> On 27/01/2019 19:34, 698839253X6D445TD@nospam.org wrote:>>> David Brown wrote<snip>>> Perhaps that all made sense to you when you wrote it - it makes no sense >> to me. > > > That is possibly where the problem is.It is where your problem is, yes - you write things that have no connection with the discussion and make no sense.> I see no 'tronics from you, you almost sound like a sales person for some bloatware that blinds > people from the inner working of things,I am an embedded programmer, not an electronics designer. (I've done a fair bit of digital electronics design in the past - I have very little experience of anything analogue beyond ADC's and DAC's.)> > >>> 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.
Reply by ●January 28, 20192019-01-28
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 :( 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".
Reply by ●January 28, 20192019-01-28
David Brown imagined>On 28/01/2019 08:23, 698839253X6D445TD@nospam.org wrote: >> David Brown opiniated >>> On 27/01/2019 19:34, 698839253X6D445TD@nospam.org wrote:>>> David Brown wrote ><snip> > >>> Perhaps that all made sense to you when you wrote it - it makes no sense >>> to me. >> >> >> That is possibly where the problem is. > >It is where your problem is, yes - you write things that have no >connection with the discussion and make no sense. > >> I see no 'tronics from you, you almost sound like a sales person for some bloatware that blinds >> people from the inner working of things, > >I am an embedded programmer, not an electronics designer. (I've done a >fair bit of digital electronics design in the past - I have very little >experience of anything analogue beyond ADC's and DAC's.)So what are you doing here?>>>> 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. All about flight control, did testing, collecting data, testing, timing checks.. At some point I was aiming for a 2 second interval, and man was I stunned when the calculation from the acquired data showed 2.000. 'That cannot be right', ran the test again, and then ? now it was 8 % off. relief. In those old day you had to have the 'tronics working with 20 % carbon resistors and 19% tolerance (aging) tubes, yes TVs still worked. As from the eighties, man I started in the fifties with 'tronics, solved problems with RTL, DTL logic before many of your were even diapers dry, and so FPGA is for me just back to logic that is what it is, nothing new, but more of old. Designed my own processor when I could not get a budget for one, but had unlimited budget for logic.. From the bottom up yes? When I retired I did not stop with 'tronics and did not stop coding (yes I did embedded on cannot remember how many different micros), so now I play with things I can select, and have fun with that. All the nonsense by you kiddies about programming; the whole recent discussion with J. Larkin, I just left it for what it is as it has no purpose other than chatting and you can indeed do that in a bar. This subject was writing to flash memory and I think I addressed that, at ;east for SDcards, if it is beyond your grasp so be it. 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. 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? Again, it is not only that you can program in some language, say same as speak some language, you also need to know in depth what you talk about, A life long study of THAT.
Reply by ●January 28, 20192019-01-28
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 >>>> On 27/01/2019 19:34, 698839253X6D445TD@nospam.org wrote:>>> David Brown wrote >> <snip> >> >>>> Perhaps that all made sense to you when you wrote it - it makes no sense >>>> to me. >>> >>> >>> That is possibly where the problem is. >> >> It is where your problem is, yes - you write things that have no >> connection with the discussion and make no sense. >> >>> I see no 'tronics from you, you almost sound like a sales person for some bloatware that blinds >>> people from the inner working of things, >> >> I am an embedded programmer, not an electronics designer. (I've done a >> fair bit of digital electronics design in the past - I have very little >> experience of anything analogue beyond ADC's and DAC's.) > > So what are you doing here? >You might not have noticed, but electronics threads are in the minority in this group. And within the on-topic threads, software is relevant - people ask questions and give advice on 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. >>>>> >>>> >>>> /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. You might do it for fun (and that's a perfectly good reason). But not as a serious choice. I've done professional assembly programming, including on a PIC - it made (some) sense long ago.> All about flight control, did testing, collecting data, testing, timing checks.. > At some point I was aiming for a 2 second interval, and man was I stunned when the calculation > from the acquired data showed 2.000. > 'That cannot be right', ran the test again, and then ? now it was 8 % off. relief.Am I supposed to appreciate some point here? Is your point that sometimes you get values accurate to one part in a thousand even when you have 8% tolerances? Or that you can't write a timing loop in PIC assembly that is accurate to 8% ?> In those old day you had to have the 'tronics working with 20 % carbon resistors and 19% tolerance (aging) tubes, > yes TVs still worked. > > As from the eighties, man I started in the fifties with 'tronics, > solved problems with RTL, DTL logic before many of your were even diapers dry, > and so FPGA is for me just back to logic that is what it is, nothing new, but more of old. > Designed my own processor when I could not get a budget for one, but had unlimited budget for logic.. > > From the bottom up yes? > When I retired I did not stop with 'tronics and did not stop coding (yes I did embedded on cannot remember how many different micros), > so now I play with things I can select, and have fun with that.If you are having fun, great. But don't pretend that your methods make economic sense these days.> All the nonsense by you kiddies about programming; the whole recent discussion with J. Larkin, I just left it > for what it is as it has no purpose other than chatting and you can indeed do that in a bar.I am not a kiddie. True, I am still a good way from retirement age. That means, however, that I live with the times and adapt to get the best choices available /now/, rather than sticking to what I used twenty years ago. (Except, of course, when the choice from twenty years ago is still the best choice today.)> This subject was writing to flash memory and I think I addressed that, at ;east for SDcards, if it is beyond your grasp so be it.The subject of the thread was writing to flash on an MCU, not an SDCard. (And yes, I have written to SDCards too.)> 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? 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.> 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.> > Again, it is not only that you can program in some language, say same as speak some language, > you also need to know in depth what you talk about, > A life long study of THAT. > > > > > > > >
