[ATmega 0] The evnt system register names mystery - Page 1
Forum section: electronics / general

author: Simon
author_rank: Unknown
timestamp: August 26, 2018, 09:43:24 pm
content: Yep, new section in the datasheet same old crap!So let's make a start not that I need them: STROBEA and STROBEB. Contrary to the documentation no such registers, variables or fuck knows what exist!the magical iom4809.h file is also clueless only mentioning STROBE which is a valid struct variable. Do I assume another massive mess from the masters of chaos considering there are only 8 event channels so why have provision to strobe 16 or did they forget to clean up someone else's datasheet they copied from when they recreated the Xmega's and pretended they came out with new chips?

author: T3sl4co1l
author_rank: Super Contributor
timestamp: August 27, 2018, 03:04:22 am
content: I noticed several desyncs between datasheet and header on the XMEGA as well. I assume the datasheet is correct and the header is lacking. Easy enough to correct, put the missing lines into your own header.Likewise, I found some lines that are probably from the A series (XMEGA64A1 or such) that aren't present in the D series I was using. These can be removed with #undef.Mind, for portability, you want to put the device-specific defines into a device-specific section, and not use them otherwise. Use the IO header's def to detect this (put an #ifdef _AVR_ATmega4809_H_ ... #endif, or whatever it is, around the section).Example, the D3 version has the register ADCA.CH0.SCAN (0x226) which is missing from the header. Observe the following log:Code:Active Load, by Tim Williams, Jun 21 2018Commands:Any key Start console interface? Display this messageR <sram>  RAM <read>/ addrS <reg>  SPI <read>/ regI Initialize LCD (SPI)C Clear LCD (SPI)G Play Raycaster>r 226RAM at: 226h = 45h>r 226 0Write: (226h) <= 0h>r 226RAM at: 226h = 0h>r 226 ffWrite: (226h) <= ffh>r 226RAM at: 226h = 9fh>r 226RAM at: 226h = 7fh>r 226RAM at: 226h = afh>r 226 45Write: (226h) <= 45h>r 226RAM at: 226h = 45h>r 226RAM at: 226h = 55h>r 226RAM at: 226h = 25hI have a RAM read/write function on the serial console, making it easy to verify things like this.As it happens, the ADC is running, so the high bits are cycling in hardware. That's why the read is inconsistent, it depends on what time I hit enter. The low bits are static.It's certainly not zero, as you might expect from it being unlisted in the header; for example, 0x227 is a reserved port, and is dead on the bus:Code:>r 227RAM at: 227h = 0h>r 227 ffWrite: (227h) <= ffh>r 227RAM at: 227h = 0h>Writing 0xff into the port does nothing, it remains 0.I do wonder how many reserved ports are actually implemented (i.e., undocumented ports), suppose I could make a table and do a scan some time.Tim

author: Simon
author_rank: Unknown
timestamp: August 27, 2018, 07:08:48 am
content: I'm not sure i follow you. Presumably if i try and add my own register definitions I need to know the memory locations of those registers as ultimately this is what it's all about in the end, writing numbers to an address location. I can find no meaningful information in the datasheet. All register address locations are offsets and on every peripheral the offsets start at 0x0... they can't all be starting from the location so there must be a further offset, ah just found that, page 43.So now what, do i need to define the register name as the periphery offset + the register offset?. I don't even know how to do that in these new fangled header files where instead of just use address numbers that are defined with names they have created these weird variables. I think I'll pass for now.

author: Simon
author_rank: Unknown
timestamp: August 27, 2018, 07:29:45 am
content: I was going to try out of desperation the Atmel start bullshit but on trying to setup TCA0 in split mode I discovered no split mode settings...... What a joke.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: August 27, 2018, 07:29:52 am
content: I did it this way:Note that all registers (that weren't forgotten, anyway?) are still named, just not descriptively.Code:/* Missing ADC register definitions */#define TEMPreserved_0x07#define SAMPCTRLreserved_0x08#define ADC_SAMPVAL_bm0x3f#define ADC_SAMPVAL_gp0...The ADC struct contains named registers, and "reserved" registers. I'm not redefining the struct, just using what they've already provided, and using a correct name for it.I haven't seen if there is a case where the struct itself is completely wrong and needs to be redefined (something which cannot be done in C). Possibly you could shuffle the namespace with some defines, but...ehhh...This is later used in my code as absolutely normal syntax:Code://ADC channel 0, interrupt, PA1 first input, PA6 last inputADCA.CH0.CTRL = ADC_CH_INPUTMODE_SINGLEENDED_gc;ADCA.CH0.MUXCTRL = ADC_CH_MUXPOS_PIN1_gc;ADCA.CH0.INTCTRL = ADC_CH_INTLVL_MED_gc;ADCA.CH0.SCAN = (5 << ADC_CH_COUNT_gp);//Scan 5+1 = 6 channels (VO, IO, TMP, POT1, POT2, POT3)Tim

author: Simon
author_rank: Unknown
timestamp: August 27, 2018, 07:53:53 am
content: So something like:Code:#define CLKCTRL_MCLKCTRLA _SFR_MEM8(0x0060)is assigning the name to the memory address. I take it _SFR_MEM8 is their cosy way of saying that that it's a number in their 8 bit memory space?

author: Simon
author_rank: Unknown
timestamp: August 27, 2018, 08:21:50 am
content: #define EVSYS_STROBE _SFR_MEM8(0x0180)This is what the datasheet calls STROBEA... STROBEA has a an offset of 0x00, the event system adress space starts at 0x0180.The next listed address is 0x0190 so in theory the address of 0x0181 is still undefined and would be STROBEB. But I am still confused as to why there are 2 strobe registers. There are 8 event channels, why do I need 16 strobes? i think the datasheet is wrong, likely copied from an xmega datasheet with 16 event channels.

author: andersm
author_rank: Super Contributor
timestamp: August 27, 2018, 09:07:28 am
content: To be fair, the datasheets are still marked as preliminary.

author: Simon
author_rank: Unknown
timestamp: August 27, 2018, 09:25:08 am
content: Well they are selling chips! I can't help their laziness. If you want to use them you need to have a correct datasheet. It is pointless selling chips if there is no accurate information to use them. The datasheet is cryptic at best and often incorrect. They have done the mammoth task of designing the chip (allegedly), is it that more difficult to get some text in the datasheet right? apparently yes.This datasheet has been out a while now, I suspect I am not the first person to find these errors. Apparently for the sake of their own pride many of us have to discover the same thing separately and collectively go through hours of unnecessary work when they could update datasheet every couple of weeks . I mean do they want anyone to use these chips?

author: Simon
author_rank: Unknown
timestamp: August 27, 2018, 09:27:53 am
content: Of course I do not know if the header file is incorrect or the datasheet.

author: andersm
author_rank: Super Contributor
timestamp: August 27, 2018, 11:15:58 am
content: You've been doing this long enough to know that picking a brand-new part is always going to be a gamble. Still, seeing as you've volunteered for the task, I hope you're reporting your findings to Microchip.

author: Simon
author_rank: Unknown
timestamp: August 27, 2018, 12:03:45 pm
content: How do I report anything to microchip? And actually I'm not that experienced.

author: andersm
author_rank: Super Contributor
timestamp: August 27, 2018, 12:25:04 pm
content: Seethis article. It does require you to register with Microchip's support system. I've found their support fairly responsive when reporting issues, at least when provided with a clear and detailed report, but YMMV.

author: Simon
author_rank: Unknown
timestamp: August 27, 2018, 08:00:32 pm
content: Quote from: andersm on August 27, 2018, 12:25:04 pmYour right, and they did respond in an hour or so:Quote

author: Simon
author_rank: Unknown
timestamp: August 27, 2018, 08:13:04 pm
content: It would also appear that it is not necessary to reference the struct variables to control the registers. These people do it all in reverse. The stuff at the start of the chips header file is actually all of their middleware crap for the crappy atmel start that is incomplete bloatware. The actual register name definitions are lower down, I take it the following looks a bit more civilized:Code:/* EVSYS - Event System */#define EVSYS_STROBE _SFR_MEM8(0x0180)#define EVSYS_CHANNEL0 _SFR_MEM8(0x0190)#define EVSYS_CHANNEL1 _SFR_MEM8(0x0191)#define EVSYS_CHANNEL2 _SFR_MEM8(0x0192)#define EVSYS_CHANNEL3 _SFR_MEM8(0x0193)#define EVSYS_CHANNEL4 _SFR_MEM8(0x0194)#define EVSYS_CHANNEL5 _SFR_MEM8(0x0195)#define EVSYS_CHANNEL6 _SFR_MEM8(0x0196)#define EVSYS_CHANNEL7 _SFR_MEM8(0x0197)#define EVSYS_USERCCLLUT0A _SFR_MEM8(0x01A0)#define EVSYS_USERCCLLUT0B _SFR_MEM8(0x01A1)#define EVSYS_USERCCLLUT1A _SFR_MEM8(0x01A2)#define EVSYS_USERCCLLUT1B _SFR_MEM8(0x01A3)#define EVSYS_USERCCLLUT2A _SFR_MEM8(0x01A4)#define EVSYS_USERCCLLUT2B _SFR_MEM8(0x01A5)#define EVSYS_USERCCLLUT3A _SFR_MEM8(0x01A6)#define EVSYS_USERCCLLUT3B _SFR_MEM8(0x01A7)#define EVSYS_USERADC0 _SFR_MEM8(0x01A8)#define EVSYS_USEREVOUTA _SFR_MEM8(0x01A9)#define EVSYS_USEREVOUTB _SFR_MEM8(0x01AA)#define EVSYS_USEREVOUTC _SFR_MEM8(0x01AB)#define EVSYS_USEREVOUTD _SFR_MEM8(0x01AC)#define EVSYS_USEREVOUTE _SFR_MEM8(0x01AD)#define EVSYS_USEREVOUTF _SFR_MEM8(0x01AE)#define EVSYS_USERUSART0 _SFR_MEM8(0x01AF)#define EVSYS_USERUSART1 _SFR_MEM8(0x01B0)#define EVSYS_USERUSART2 _SFR_MEM8(0x01B1)#define EVSYS_USERUSART3 _SFR_MEM8(0x01B2)#define EVSYS_USERTCA0 _SFR_MEM8(0x01B3)#define EVSYS_USERTCB0 _SFR_MEM8(0x01B4)#define EVSYS_USERTCB1 _SFR_MEM8(0x01B5)#define EVSYS_USERTCB2 _SFR_MEM8(0x01B6)#define EVSYS_USERTCB3 _SFR_MEM8(0x01B7)Would be nice if they somewhere explained what they planned and made available.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: August 27, 2018, 08:44:43 pm
content: They provide MEGA-style flat named registers for backwards compatibility, but using them, you lose the portability of being able to remap devices in software without worrying about each device being slightly different (e.g., consider TC0, TC1 and TC2 on the mega32).The point is to have, say, four SPI devices, all laid out in precisely the same way, with identical register offsets, names and bit functions. You only need provide the register base address to the driver code, and it knows the rest.Tim

author: Simon
author_rank: Unknown
timestamp: August 27, 2018, 08:55:39 pm
content: But i thought that was the point of header files. They map the names to the addresses so that the TCB0 names can be used on any device but providing the correct header file is loaded the names will point to the same registers in different numerical addresses on a different addresses.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: August 27, 2018, 09:04:22 pm
content: Well, yeah, you would invoke such a function as:doDeviceOperation(&TCB0, param1, ...);Tim

author: Simon
author_rank: Unknown
timestamp: August 27, 2018, 09:17:01 pm
content: #define EVSYS_STROBE _SFR_MEM8(0x0180)I would expect "EVSYS_STROBE" to be common across the range and that particular peripheral no matter the device, so if I always use it in my code it will work. On the 4809 it corresponds to address 0x0180 and on other devices it may correspond to a different address. But if I always use the standard name in my functions it will always point to the correct address for that peripheral on any device where i use the correct header for the chip.If you create a project with Atmel start you find all of the struct stuff and other crap called by the middle-ware files.