AVR Freaks

Hello,

  Do you have to load a driver for Windows in order to use this new USB-serial IC?   For the Nano, one must download and install the CH341 driver.  Also, with Windows10, I had to disable the "driver signature verification", a weird, paranoid, poorly documented, cumbersome process that Microsoft forces on its customers.

Did you get the 12-bit ADC working?  Or the DAC?   Are there guides to the 0.1" break-out board pins/vias?  It looks like D13 (SPI clock) is not on the silkscreen, or, it might have a different name.

Does it load Arduino programs using AVRdude like the standard Arduino?

It looks like there is a "pop off" USB micro-B style connector.  Do the side mounting tabs go into plated-thru holes or are they simply soldered onto the PCB top?

Please keep us informed on your explorations on this new board.

Oh!  They have a 32k flash version now?  I noticed when the LGT88 was announced, but and 8k chip wasn't very interesting (particularly with ATmega8 selling for $1.  Though perhaps those are actually the LGTs in counterfeit packaging...)

You said you confirmed 32k was present, right?

(and: another cheap SOIC USB chip!   that's cool, too!)

Huh.  The text might be in Chinese, but those are REALLY NICE diagrams (pretty much throughout the manual!)

Hai

Interesting chip and added features than real 328p.
Did you order from Singapore ?

Regards
Tiro

There is a big difference between stealing a complete silicon design and a pin-compatible or tool-compatible.
No one ever complains about fab-less startup companies. Plenty of ASICs start this way. And many clever CPU cores and peripheral silicon.
.
Yes, I am always a bit suspicious of cheap electronics on Ebay. Some will be QC rejects. Some are just good marketing. e.g. Arduino clones with genuine ATmega328P but cheaper CH340 USB chips.
.
I have ordered some 328P and a 328D boards. I would like to buy a SWDICE too. But I can't make any sense out of the link in #20.
Google translate works on the home page but not on any 'shopping' page. At least with Firefox.
.
David.

when Atmel made 2051 and 4051 they paid royalties to intel, that was why they started with AVR!

(and could only make  small chips that couldn't replace  "real" 8751).

I really think that the LP versions got around that.

I soldered the board into a Protoshield.   So I can swap hardware from Uno, Mega, Zero, NUCLEO, ...

First test is to rotate LEDs on D0 - D13.   Worked first time.

However pinMode() does not seem to work on A0 - A5 pins.  i.e. digital mode does not work.

I2C seems to work ok on A4, A5

There does not seem to be a separate AVCC pin.   Do I need to connect the SWC, SWD pins?

I presume that AREF already has a 100nF and you do not connect it to power.

I am using the Arduino core from https://github.com/wemos/Arduino_XI

David.

Edit.   Solved it.   lgt8fx8x_init() disables digital with DIDR0 register.   Subsequent pinMode() should enable/disable digital as required.   i.e. needs a patch in wiring_digital.c

Ah-ha.  I had never associated your user name with being a Chinese speaker.

The LGT datasheets seem to have a lot of English headings.  But with blocks of explanation in Chinese.

I would guess that LGT could use their original Chinese document to generate an English version with Translation software.

Obviously any machine-generated translation produces a "Chinglish" that is not good for Company Reputation.

But from my point of view,   a Chinglish PDF with the correct format  and layout is a lot easier than manually copy-pasting sequences into Google Translate.

Various Online websites claim to translate Chinese PDFs while maintaining appearance.   

The "free" sites just crash.    I would be happy to pay $15 for a translation.    Do you know of any sites that actually work?

My LGT8F328P boards work pretty well.  

My LGT8F328D board has not arrived yet.

You need to download the Ocrobot Software from http://www.ocrobot.com/doku.php?id=download

Run the ocrobot.exe which is an "Arduino IDE".   Then install the LGT board(s) from the Boards Manager.

The LGT cores from Ocrobot seem to be up to date.

The core that I had been using from https://github.com/wemos/Arduino_XI is not so good.

Bog-standard Arduino sketches work out of the box.    SPI and EEPROM work fine with the supplied classes.

Direct access to AVR SPI or EEPROM registers in a sketch will require editing.

David.

Yes,   I fully understand that a Chinese company would have to employ professional human translators from a reputation point of view.

Yes,   there is a lot of snobbery from the West.     Chinese MCUs and TFT controllers are often more advanced than the Western models.

I would be perfectly happy with a machine-generated translation.    I can live with Chinglish.    I would not expect perfection.

Since I am familiar with the ATmega328P,   it is only minor aspects of the LGT chips that I need to study.

OTOH,  LGT might not want to sell their chips on the world market.   Or perhaps Western Distributors do not want to handle them.

Is my assumption about the PDF correct?   i.e. does it look as if they have prepared the PDF for translation?

The LGT chips look very interesting.    They are more advanced than the ATmega328P.    But I am sure that Atmel or any manufacturer could improve any 20 year old MCU design.    Design tools and Fabrication has made great strides in 20 years.

David.

Sure, I didn't mean to accuse anyone of anything, just to be clear.

I'm not sure about the PDF. They tend not to translate non-words to Chinese, things like register names and acronyms.

It's interesting that they are sticking with Chinese. Japanese engineers tend to prefer English datasheets and having good English skills is essential. But China is much bigger, over a billion people in the home market alone, and they seem happy to stick with Chinese. If anything it gives them a bit of an advantage, since they have all these great parts we can't figure out how to use.

PDF translation is tricky. Chinese, like Japanese, is much more compact than English for technical information so translation buggers up all the formatting.

Thanks, that's actually quite useful. The uDSC looks very interesting.

Atmel Microchip should be working with those guys.

[machine-translated pdfs provided]

Useful, but awfully ugly (page breaks in the wrong place, diagrams destroyed, etc.)  One tends to forget how painful a badly formatted document can be, once you've become used to "pretty" documents.  The sort of thing that you can fix by crowd-sourcing, maybe.

I think it was some of the early ESP8266 documents, translated "mechanically" that looked to be pretty bad datasheets, even though they looked like "complete" translations.   Not that there aren't bad data sheets that originated in english to start with.

Click the middle mouse button (wheel) and it turns into a little circle thing with arrows in it. Move it into the lower half of the browser window and it will auto-scroll down forever without you having to do anything.

My LGT8F328D board uploads small sketches ok.   Anything bigger than 4kB gives errors.

So I solder SWD header onto the board.  Run the LarduinoISP sketch which reads the "Signature" ok.   (I added a 4k7 pullup to the SWD line)

It also managed to erase the chip.   Any subsequent re-install of the bootloader or any firmware fails.

Fortunately my LGT8F328P board(s) work ok.   These LGT chips implement "EEPROM" by reserving a section of the 32kB of Flash Memory.

This means that you have less Flash available for your Application than a Uno.   But at least the P bootloader works for the whole area.
 

Many thanks to Joey for his translation of both P and D datasheets.

One further question.   Is it possible to get the default font to be a Narrow Arial instead of TimesNewRoman?

Times fonts must have been invented by the Devil.   (or someone with exceptional eyesight)

David.

@Joey,

I love you even more.   The Arial fonts make all the difference.   It is quite pleasant to read now.

Is it me?   Or do other people find Times fonts unreadable?

@El Tangas,

I presume that the LarduinoISP.ino sketch would be 100% reliable.   It comes from LogicGreen.

I might even try it with the LGT8F328P chip.

I suspect that my 328D chip or bootloader was/is faulty.     The 328P bootloader reads Flash ok.

Before I ever attempted ISP,   I tried reading with the 328D bootloader.    This gave avrdude errors.    Displaying memory from a small sketch showed that some of the "higher address" Flash pages contain data.

I will probably investigate the problem at a later date.    My 328D board came from Ebay http://www.ebay.co.uk/itm/WEMOS-XI-V1-0-0-LGT8F328D-Module-Board-New/263106271207?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2060353.m2749.l2649

It is identical to your Wemos XI board.

I am always suspicious when boards are sold with unmarked chips.    It implies that LogicGreen does not want them on the market or they were QC rejects in the first place.

My 328P uploads automatically with the Bootloader.   Yet your identical 328P board needs manual Reset.

David.

Brian,
That is exactly the same board that I bought from the same Ebay supplier.
The P version comes wiith USB connector, UART bridge and LDO.
The D version that you are looking at requires an external UART and power.
Yes, I think you can get the P board through Ebay or AliExpress. I bought 3 from Ali. So I could mail one to you.
.
David.

@El Tangas,

I have been playing with the DSU.   Wondered how easy it would be to use in regular GCC projects.

As  you showed in an earlier post,   it is easy to produce external functions.   In fact you produced an inline function with gobbledygook.

I have attached two sketches:

LGT_dsu_test:  creates externally linked functions using an .S file (I can't manage gobbledygook)

fpbench_uno:  my regular timing program.  to run on Uno / LGT.

It illustrates the marginally faster execution due to LGT shorter cycle counts.

If you enable a macro in the "__dsu_funcs.S" it will replace some primitive internal multiply and divide functions from libgcc.a

It makes little difference to multiply but divide is dramatic.

Requires further tests.   e.g. in LGT_dsu_test harness.

I could replace every function from lib1funcs.S but it would not make much difference.

avr-gcc inlines the 16x16 multiply.   So "faster" external libgcc functions would be ignored.

You would need to tell GCC to inline the DSU calls instead of inlining the 16x16 "MUL" sequence.

You would also need to alter the optimised f-p primitives.

David.

In an ideal world the Arduino IDE would detect a LGT8F328P:

1. avr-gcc would be given appropriate switches to use DSU calls instead of inlining 16x16 multiply e.g. an extra "avr5_lgt" memory model

2. avr-gcc crts.o (C runtime startup) would enable the DSU.

3. the libm.a and libgcc.a libraries would be optimised accordingly.

4. the punter simply selects a LGT8F328P Board in the IDE.

5. magic happens.

In practice,   few people outside of China have seen or used LGT chips.   Writing and maintaining another avr-gcc "model" and Arduino Core is prone to "features"

Even the most trivial "feature/problem" would be ridiculed by the West.   And be bad publicity for LGT.

My "replacement libgcc primitives" just involve enabling DSU and adding the "__dsu_funcs.S" file to a project.   Regular "long" math operations use these primitives instead of the standard libgcc.a internal functions.   e.g. any regular math expression that involves longs like A = B * C;

Inline functions written in gobbledygook can be contained in a "dsu_funcs.h".    Your project can use them by #including "dsu_funcs.h" in a compilation unit.    Existing libc.a or other library code will never know about DSU.    You would need to say: A = dsu_multiply(B, C)

David.

@El Tangas,

Your test  was for 16x16 multiplication and 16x16 division.

My test was for 32x32 mult and divide.  e.g.

Hello GCC chip:AVR @16000000Hz C:\Users\David\Documents\Arduino\LGT_sketches\fpbench_uno\fpbench_uno.ino
    ticks    uSecs     flops OPS/10e6 [iter] operation
    49413     3063    326477  1017008 [1000] overhead loops
   115881     7184    139198   433616 [1000] fp adds
   134126     8315    120264   374635 [1000] fp mults
   475334    29470     33932   105704 [1000] fp divs
  2063712   127950      7815    24346 [1000] log
   491505    30473     32815   102224 [1000] sqrt
  4705891   291765      3427    10676 [1000] pow
   625662    38791     25779    80304 [1000] y=x/m+b using longs
    85400     5294    188893   588420 [1000] y=mx+b using longs
   249144    15446     64741   201676 [1000] y=mx+b using floats
total ticks is 8996068 [557  ms]

And when I enabled the replacement "Compiler internals" by editing "__dsu_funcs.S"

#define ENABLE_DSU_INTERNAL_FUNCS 1

The timings changed to:

Hello GCC chip:AVR @16000000Hz C:\Users\David\Documents\Arduino\LGT_sketches\fpbench_uno\fpbench_uno.ino
    ticks    uSecs     flops OPS/10e6 [iter] operation
    49413     3063    326477   385200 [1000] overhead loops
   115881     7184    139198   164235 [1000] fp adds
   134200     8320    120192   141811 [1000] fp mults
   475630    29489     33910    40010 [1000] fp divs
  2064524   128000     16009    18888 [1000] log
   490839    30432     32860    38770 [1000] sqrt
  4705521   291742     33786    39863 [1000] pow
    74390     4612    216825   255825 [1000] y=x/m+b using longs
    77324     4794    208594   246113 [1000] y=mx+b using longs
   248846    15428     64817    76475 [1000] y=mx+b using floats
total ticks is 8436568 [523  ms]

As you can see,  it makes virtually no difference to any of the f-p tests.    Which shows that they must do their own mult and div in ASM.

It improves the y=mx+b calculations from 5.3us to 4.8us per statement.

But the y=x/m+b goes from 38.8us to 4.6us per statement.

To make a fair comparison,  you need to write a dsu_mult32x32() function.   This will make four 16x16 DSU_MUL operations,   add them together and return the 32-bit result.   Likewise for a dsu_div32d32() function.

You also have to cope with signed and unsigned arguments and results.   Which is why I limited myself to only replace the most primitive libgcc.a functions.    The Compiler looks after the signed, unsigned, casting, extension, truncation, ... issues.

The opcode cycle times make a noticeable difference.   e.g. with GPIO and math.

I am surprised that the 16x16 hardware DSU_MUL is not much faster than an AVR doing four 8x8 MUL opcodes.

Of course,   any hardware DIV is better than bit-banged software.   Even if you still need several DSU_DIV ops to achieve 32div32.

David.

@El Tangas,

Have you tried bidirectional SPI?

My MassDuino Uno LC board arrived a couple of days ago.

It contains an LGT8F328D and works nicely at 3.3V

I am trying to get Bidirectional SPI Master to work.   i.e. setting DUAL bit in SPCR.

My Logic Analyser shows the MOSI line becoming an input but reading SPDR returns the wrong values.

I get the same values and behaviour with LGT8F328P

The 328P has other features with its SPI buffers.

Bidirectional SPI on a STM32 is also painful.   This seems crazy.   Bidirectional only involves changing MOSI from output to input and routeing the MISO signal to this pin.    Writing to SPDR sends 8 SCK clocks.

David.

Yes.   As used by ST7735, ILI9163, ... and an option for most TFT controllers.

Oh,  I struggled for ages to read the BandGap.    You have to enable ACBG for the BandGap to be accessible to the ADC input multiplexer.

Mind you,  the LGT has a "better" method of reading AVCC via a potential divider.   Instead of the AVR method of reading BG with AVCC as ref.

If the chips had a usable 32kB of Flash,   both 328D and 328P would be very attractive.

David.