Anyone here interested in the Logic Green AVR's - LGT8F328P?

[jakeisprobably]

DISCLAIMER: if this kind of thing triggers you, please press ALT-F4 before commenting. Negative people really make this forum suck some times. If that's you, please quietly move on and ignore this. Tribalism, racism, or nationalistic bias is not welcome either. I am not a Microchip attorney, don't care if you are, or if you spend Saturday nights with cheerleader pom poms for their attorneys.

    In case anyone has not heard of the LGT8F328 a Chinese company makes AVR clones with silicon hardware mods (12b diff ADC/8b DAC/32MHz/etc.). LGT claims to have 49 instructions that take less clock cycles than the ATmega. It has 3 omitted instructions and 4 new instructions. It also has 88 new registers that the ATmega has listed as Reserved on the datasheet.
   Logic Green are not pursuing a Western market, but there are options available from China Direct sources. You won't be able to get them through traditional, or even Western facing Chinese distribution companies. There are several boards available from various China direct sources though, and some of these places list chips as well.

  The chip really needs some better documentation in English, there is nothing available officially. They have a working Arduino tool chain with a few examples. They also have their own SDK program, programmer, and (IIRC) an IAR example setup. Unfortunately they haven't done the Arduino tool chain with a proper AVRdude implementation. They did everything inside the awkward Arduino (as) ISP interface and inside of the Arduino IDE's makefile system. There are calls to AVRdude in the makefile but there isn't a serperate -C config-file that can be used external to the Arduino environment. This is one of the things I would really like. We are currently limited to using an Arduino optiboot bootloader only.
You can find out more from a guide and collection of info here: https://github.com/dbuezas/lgt8fx.

  I've been playing around with the documentation but I'm getting in a bit over my head. I've posted a few things on github but it isn't complete, just a casual work in progress. I've spent the last day looking for detailed info about the ATmega's AVR core architecture, and trying to compare it to the LGT's, but I'm quickly realizing how little information has actually been disclosed about things like the ALU of the ATmega.
 I probably need to post pages of the PDF so I can get some feedback about corrections and a little help. There are a few English translated datasheets floating around. I have 4 different ones so far. They are all very bad. I'm not saying I can make a good one, I don't even speak Chinese. However, I can format the Chinese text so that a translation program can do a proper job line by line. No translation program appears to be able to retain proper word formatting on a 267 page PDF and they really suck at putting the text back where it belongs. Perhaps someone with the time to create the PDF could do a better job with the help of a community?
My goal is to make this match the Chinese document page for page with text recognition and an index table. The first page is marketing fluff so that can be used for notes. My current 1st page will change. I have pages 2-12 edited and posted along with a couple spreadsheets comparing the instruction sets and registers. I'm doing all of this with free software and saving all the files publicly so anyone could edit and revise my work.
https://github.com/Upcycle-Electronics/LGT8Fx-Datasheet/tree/master/finalpdf

[ebclr]

Here you can buy a very cheap board

https://www.electrodragon.com/product/edmini-dev-board-arduino-compatible/

You may find useful information here

https://github.com/Edragon/LGT/tree/master/Toolchain

English Datasheet ( appear to be a translation )

https://www.avrfreaks.net/sites/default/files/forum_attachments/LGT8F88P%20LGT8F168P%20LGT8F328P%20translated.pdf

[magic]

DISCLAIMER: if this kind of thing triggers you, please press ALT-F4 before commenting. Negative people really make this forum suck some times. If that's you, please quietly move on and ignore this. Tribalism, racism, or nationalistic bias is not welcome either. I am not a Microchip attorney, don't care if you are, or if you spend Saturday nights with cheerleader pom poms for their attorneys.

Heh, I have a small collection of fake opamps, might buy one of these too

Seriously though, the specs seem interesting. Bummer that Atmel hasn't done it itself, 10 years ago. The Xmega gets close, I guess.

I find the declared timings of jump instructions suspicious. Are they really able to compute the destination address already during the fetch stage so that in the next cycle the execute stage is a no-op while the fetch stage is already fetching the target instruction?

If their flash and ALU really is that fast, I would prefer that they stayed with 2 cycle jumps and bumped maximum clock speed to 64MHz

And they screwed up the bit skip instructions. I believe the whole point of those is that they take the same number of cycles regardless if the skip happens or not, perhaps useful for cycle-accurate assembly. If you want to minimize execution time, you would use a conditional branch instead. And now they made bit skip timings equivalent to a conditional branch.

[mikerj]

There's more to a useful part than the silicon itself, something that seems to get frequently overlooked.

What's the Chinese AVR tech support like?  Can I phone an FAE to get help or have them visit?  Which compilers support this device?  Which debuggers?

[magic]

If you are a Chinese customer ordering thousands and millions I presume they would give you some phone number to call.
Other than that it probably is aimed at the Arduino crowd, hobbyist and small ex-hobbyist designers, so not really people who make lots of support calls.

[amyk]

Perhaps someone with the time to create the PDF could do a better job with the help of a community?

I know English and a bit of Chinese, I could probably give it a try... just point me to the original PDF you want to translate. Is it this one? https://github.com/dbuezas/lgt8fx/blob/master/docs/LGT8FX8P_databook_v1.0.4.ch.pdf

That said, the English versions you have on your site are not too bad and look like a lot of the English datasheets from Chinese companies I've seen.

As an aside, an extra 'B' somewhere in their name would make things a lot more amusing...

[ebclr]

"What's the Chinese AVR tech support like?  Can I phone an FAE to get help or have them visit? "
 
You must be kidding

[jakeisprobably]

Thanks for the offers to help.

Most of this is rather silly or insignificant, but I completely broke down page 10's issues as a few things are introduced here in text. That's the page that has been really bothering me to figure out. Again, I'm no expert here, and haven't done a whole lot with assembly. I've been learning entirely on my own since becoming disabled a few years ago. I'll probably ask some rather dumb questions. I can learn pretty quickly though if I'm pointed in the right direction. My main contribution is the fact I have a practically infinite amount of time to brute force this.
 Below is a summary of questions based on the paragraphs of the attachment. The questions are there too. I don't think I'll need anything like this for most of the content. I just really needed to be able to compare the ATMEL text with the translation in depth as there were lots of tricky similarities. I can figure most of this out eventually like #6 is pretty easy to figure out, I just wrote this from a formatting the text perspective. I don't have all the PDF's open with GIMP too as that is too much for my ancient laptop to handle. I'm either formatting or researching but not both at the same time.
(the numbers are related to the paragraphs/you'll need the attachment for this to make sense)
1.)
Can, “all three” 16b registers, or (like the ATMEL DS) can only the one access FLASH?

Is the 16 bit single cycle ALU really a unique feature?

2.)
Is this just semantics? (see detailed ?)

4.)
Is there a difference between just “calling the stack pointer and calling the stack pointer “in the Reset routine?”

5.)
Is there a significant difference between specifying that an interrupt controller is “in the I/O space and not?

6.)
Is the I/O memory in or after 0x20-0x5F?

7.)
Does this look correct? (need translation checked from PDF)
What is the meaning behind the “16-” in “16-Dimensional Operation Acceleration Unit (uDSU)….?” Is this some kind of error that should be “16-bit” or is it some kind of feature?

8.)
This has become more of a personal question for me at this point, but... does this “16 bit ALU” seem significant? (more detailed question is in the PDF)

Does this line look like a correct translation? This is a unique line/feature added that is not in the ATMEL DS. The ALU also includes a single-cycle hardware multiplier that implements direct signed or unsigned operations on two 8-bit registers in a single cycle.
同时ALU部分也包含了一个单周期的硬件乘法器,能够在一个周期内实现两个8位寄存器直接的有符号或者无符号运算。
 
Thanks in advance for any and all help.
-Jake

[jhpadjustable]

I love the effort, but I would think twice about using Atmel's text as such a close guide. Disclaimer: I'm not a Microchip lawyer but I slept on a couch in Arizona once.

2) Properly, those should be singular, since it is a two-operand machine and any instruction that phrase describes will specify one of each. "Kernel" is an approximation of "core".
4) "First" is correct for all intents and purposes. "in the Reset routine" is also correct but possibly overspecified. As long as it's set before you use it, the core doesn't care.
5) The I/O space can be accessed by IN and OUT instructions that are shorter and faster than most other addressing forms. While it would be incredibly odd, the LGT's interrupt controller may have its control registers accessible only in the memory space. Confirm with the memory map.
6) "In" is the closest term. Mind your zero vs. oh!
7/8) Very significant. I pasted p60 into Google Translate and here's what it gave me, almost verbatim:

Digital Operational Accelerator (uDSC)
16-bit memory mode (LD/ST)
32-bit accumulator (DX)
Single cycle 16-bit multiplier (MUL)
32-bit arithmetic logic unit (ALU)
16-bit saturation operation (SD)
8 cycle 32/16 divider
Single cycle multiply/add/subtract (MAC/MSC)

Overview
The Digital Operational Accelerator (uDSC) acts as a computational coprocessing module for the LGT8XM core and implements a 16-bit digital signal processing unit in conjunction with the LGT8XM core 16-bit LD/ST mode. It can handle the processing of most control digital signals.
uDSC components and function:
1. 16-bit operand register DX/DY
2. 32-bit accumulation register DA
3. Single-cycle 17-bit multiplier (16-bit enabled/unsigned multiply)
4. 32-bit ALU (16/32-bit addition, subtraction, and shift operations can be implemented)
5. 16-bit saturation operation (used to store the result of the operation in RAM space)
6. 32/16 divider, completes the operation in 8 cycles

[OM222O]

the only advantage that LGT8F328P offers over atmega 328P that it's trying to replace, is double the clock speed and some improvements to the IPC. how much that matters you might ask? probably not at all! I myself run the atmega 328p with the internal oscillator which is only 8MHz compared to the "standard" 16MHz and I have not encountered an issue yet.micro controllers aren't really meant for number crunching like CPUs, and in any reasonable application spend most of their time being idle or working on some sort of serial communication. not to mention that there is a huge shift towards ARM and that AVR is slowly fading away. prices are very comparable too, so if you need high speed MCU for a particular application, look into the ARM echo system (STM32 is hugely popular these days) and they offer speeds of about 120MHz easily. I don't see how the  LGT8F328P can fill any market segments, but if you just want to have fun with it and buy a few for some testing it should be ok.

[Mr. Scram]

the only advantage that LGT8F328P offers over atmega 328P that it's trying to replace, is double the clock speed and some improvements to the IPC. how much that matters you might ask? probably not at all! I myself run the atmega 328p with the internal oscillator which is only 8MHz compared to the "standard" 16MHz and I have not encountered an issue yet.micro controllers aren't really meant for number crunching like CPUs, and in any reasonable application spend most of their time being idle or working on some sort of serial communication. not to mention that there is a huge shift towards ARM and that AVR is slowly fading away. prices are very comparable too, so if you need high speed MCU for a particular application, look into the ARM echo system (STM32 is hugely popular these days) and they offer speeds of about 120MHz easily. I don't see how the  LGT8F328P can fill any market segments, but if you just want to have fun with it and buy a few for some testing it should be ok.

I don't think they're trying to replace anything but are simply a cheaper alternative with quicker chips. More like an addendum or extension.

[jakeisprobably]

Thanks for the info, answers, and replies.

 This morning I thought it might be smart to simply look up the original AVR patent to see what details it might reveal. While I would normally try to contain my enthusiasm and post a substantive reply with respect to the information and answers from my prior questions, I hope you will forgive me here for this post. I will be re-reading analyzing all of the answers in detail shortly.

  I am obviously not an Attorney, and have no clue about patent law in my country or any others. However I believe the google patents page lists the main AVR architecture patent US5854939A as expiring today 10/02/2019:
https://patents.google.com/patent/US5854939A/en?assignee=Atmel+Corporation&num=50&sort=old&page=4
 Perhaps I misunderstand, but I believe this means the core architecture is in the public domain now. I'm no expert. Perhaps someone else with more experience can explain why this is not the case.

Regardless, the documentation and illustrations in the patent reveal a bit more detail about the core architecture than I've seen anywhere else while researching this. I've searched and read where many people have speculated about, and have stated this information was not public, when in fact, it is clearly posted in the link above (or the attachment below), and in detail.
-Jake

[jhpadjustable]

the only advantage that LGT8F328P offers over atmega 328P

I put it to you that you haven't read the datasheet...
The DSP accelerator and separate 16-wide RAM is novel and not present in the ATmega328P or, as far as I know, any other Microchip AVR. See p60 of the original datasheet. At an actual retail price of 68 cents each in lots of 5, I could see it being quite useful in low-cost sound processing for mid-range toys such as voice changers, dancing dolls, educational toys, radio-control basebands, or music-responsive light shows. 32÷16-bit divide/modulo takes hundreds of cycles of normal AVR code, while this processor does it in 8. The clock cycles saved can be spent in sleep or allow a lower system clock frequency. While pennies and battery life probably don't matter to the average Arduino hobbyist, they do matter in mass production.

Perhaps I misunderstand, but I believe this means the core architecture is in the public domain now. I'm no expert. Perhaps someone else with more experience can explain why this is not the case.

I'm not a patent expert either, nor any sort of attorney, nor am I qualified to dispense legal advice, but I did stay in a Holiday Inn once and I'm occasionally a little paranoid. The claims are the heart of the patent, and they alone determine what practices are covered by it. The rest of the text is informational. Note that not all of these claims are necessarily valid and it is possible they were or could have been struck in a court judgment and/or reexamination proceeding. Claim 1, for example, claims their implementation of effective-address calculation using paired registers, as the first 8 elements of the claim are the state of the prior RISC art and the last three elements, along with the succeeding claims up to #7, were the novel adaptations of that prior art to the narrower machine. #8 et seq. seem to be describing a slightly different 8-bit machine, similarly constructed claim by claim.

The expiration of the patent does eliminate at least one trap for young processor designers. Even though the core patent may have expired, there may or may not be guard patents around other implementation details or patents on newer variations or additions to the architecture which remain in force today, and may or may not withstand any sort of challenge.

(ETA: found a price)

[jakeisprobably]

There are a few files modified on my github page now including the most useful thing I've made yet. I got a working English translation of the bookmark index working with the metadata from the original Chinese datasheet. It doesn't have the partial page portion of the index but it does go to the correct page. I kept the wording exactly like it came out of google translate for now. It will better match the V1.0.4.en datasheet this way. I can modify it later. If anyone sees any errors that need to be corrected let me know. Extraction of the index's text from the Chinese PDF proved to be extremely tedious. I tried several tools but wasn't able to extract it programmatically. This was 8 hours of cut and paste insanity.....got to get better python skills ASAP. I would upload the files here but the English one is a bit too big at 8.5MB. I also created a version of the Chinese datasheet with an English index. That's mostly for me but perhaps others will find it useful.
-Jake

https://github.com/Upcycle-Electronics/LGT8Fx-Datasheet/tree/master/finalpdf

[jakeisprobably]

Hey
  I've been trying to highlight the unique features for the LGT, but page 16 has a lot of differences. I've been using italics to show the lines that have information different from the ATmega. LGT made this fairly easy. They literally copied translated and pasted the ATmega328 datasheet. There are some humorous spots where they retained references from the Atmel DS that they don't have in the LGT document. It's nothing important, just stuff like a reference to an Assembly code example that they don't have. They certainly weren't trying to hide that it's a copy. The nice part is that I can break down the text and find exactly where they added and omitted information. It's tedious to intuitively filter through the translation, compare the ATmega text and pick out line by line. I feel like it would be a shame to lose this layer of insight I can easily add to the final document. However on page 16 it's starting to seem a bit busy to me aesthetically. With the hobbyist reader in mind, what do you think about the extra text highlighting on the attached page? The real differences are fully detailed in the second attachment for reference.

[ebclr]

" I'm not a Microchip lawyer "

A  Microchip lawyer is worth nothing in China market,  and they have many consumers there, and the market still growing, US is no more the center of the world, China influence is ramping, they don't have export forms to be filled even for a simple Bluetooth module, as uncle san did. Game is over

[jakeisprobably]

I'm not a lot of other things too 

  We've all got lots of problems in every country around the world, and especially China. I hope we all do well, including them.

I just got through modifying Andrew's English PDF to add the last few pages and add my index that I modified to match. I also renamed it to LGT8FX8P_databook_v1.0.4.0Andrew_eng+index. It is based on the v1.0.4 text. LGT has not released a v1.0.5...I looked, as have others. I also found a better PDF compression tool so... his modified PDF is attached if anyone is interested.

 I needed a break from figuring out page 17 and exactly how the SRAM magic is happening. It's about as clear to me right now as the PIC uC naming conventions. ..."no dude, I want your 33-bit uC models not that old 32-bit rubbish."....
I really don't understand why LGT listed the uC with 2KB of SRAM when it has 2KB in the lower addresses from 0x100 to 0x900 and another 2KB addressed from 0x2100 to 0x2900. When I first saw the illustration on page 17 I first thought that was "1/2KB." then realised that would be just as odd. Then I thought it had to be 4KB, then realized the 16bit remap. so that's what like 3KB sorta? ...kidding... I need to translate page 60 to 70 in order to do 17 well... oh well. I figured Andrew's version is a bit easier to read but I'm not going fishing without and index again...so now his PDF has one.
-Jake   

[amyk]

It's 2K, the upper range is an alias but it can be accessed by the 16-bit accelerator.

The 1K/2K byte SRAM in the system is mapped to two spaces, respectively.
This space from 0x0100 to 0x0900 is read and written by the core with a width
of 8 bits. Starting from 0x2100 to 0x2900, this area has a 16-bit wide access
space. The system RAM is mapped to the high-order address starting at 0x2100
and is primarily used in conjunction with the uDSU module for efficient 16-bit
data storage. When programming, the normal 8-bit addressing variable address is added to the
0x2000 offset to switch to the 16-bit access mode.

[arduinoshop]

I have been using two different LGT development boards with the Arduino IDE using this package...

https://raw.githubusercontent.com/dbuezas/lgt8fx/master/package_lgt8fx_index.json

Every thing worked well.. and fast... until I tried to use freeRTOS which was what I required...  Both the boards I have appear to have the WOTON fuse not programmed so the watchdog timer cannot used in interrupt mode (only RESET)... a real showstopper for freeRTOS..
I wanted to reload the bootloader with the appropriate fuses but these boards appear to be locked.  SPIEN is not set and fuses cannot be set via UART interface as far as I can tell... "dbuezas" commented that a  SWDICE mkII Pro is the only way....

Just wondering if anyone could comment on this fuse problem on the devel boards..

BTW: cheap plug... these boards are available at https://arduinoshop.ca

[giolicious]

I'm looking to test the chip LGT8F328P-SSOP20 but I cannot find the datasheet with dimensions, anyone?

I have looked at the datasheet ( LGT8FX8P_databook_v1.0.4.pdf ) but it does not seem to contain the specs for the dimensions.

[lastguy]

I know English and Chinese, used to use ATMEG2560 based 3D code base.
But, after five years any update on this topic? The linked site has 2020 update looks ok, but manual is kind of messy in syntax.
I have Uno and nano, Arduino IDE is the best since I used 8x51 and Pic. Its like C code is also the best and online doc is tiny and straight forward. I used to be in a team using 80x51 for large - at least for 80x51 as we use 256KB ROM and ICE cost ~$8K, but I kind of dislike Pic as its s/w is messy and buggy.
These days - at least in US - many things listed 2X price now. 12bit A/D would be a good thing but I think Arduino based new chips would still be more advance?
Can any body confirm me its dev env? if it has no USB based (boot loaded) board and code is not same or similar as Arduino coding, I might not be interested.

[ebclr]

You can use Arduino IDE same way as atmel ones, only with LGT8 library

[strawberry]

Memory retention and durability over wide temperature range?

[Watth]

Hey there,
I'm trying to program a board based on this chip. And that is as a newbie ; so with a bit of cargo cult technique.
There are some resources online, but some are missing important parts (e.g. this one refers to a boards.txt file without a working link...)
So, do you know of a functioning workflow allowing to program a LGT8F328P using an arduino Uno board as ISP?
Thanks!

[jdev99]

Hey there,
I'm trying to program a board based on this chip. And that is as a newbie ; so with a bit of cargo cult technique.
There are some resources online, but some are missing important parts (e.g. this one refers to a boards.txt file without a working link...)
So, do you know of a functioning workflow allowing to program a LGT8F328P using an arduino Uno board as ISP?
Thanks!

Will this help you?