Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

T4 avr registers #404

Merged
merged 5 commits into from Dec 6, 2019

Conversation

@KurtE
Copy link
Contributor

KurtE commented Nov 16, 2019

@PaulStoffregen,

As there have been a few complaints recently recently up on forum about not having support for AVR registers, here is a first pass, maybe last pass... I did not test Pull up stuff yet... But at least simple test works:

void setup()
{
  while (!Serial && millis() < 5000) ; // wait up to 5 seconds.
  Serial.begin(115200);
  Serial.println("Quick test to see if AVR emulation works ag all");
  // Quick and dirty test
  // PORTD Pins 0-7
  // PORTB Pins 8-13
  // PORTC Pins 14-19
  DDRD = 0xff;  // All Outputs;
  DDRB = 0;     // All Inputs
  DDRC = 0;     // All Inputs
}

uint8_t counter = 0;
void loop()
{
  PORTD = counter;
  Serial.printf("Count: %x, B:%x C:%x\n", counter, (uint8_t)PINB, (uint8_t)PINC);
  counter++;
  delay(250);
  if (Serial.available()) {
    while (Serial.read() != -1) ;
    Serial.println("Paused:");
    while (Serial1.read() == -1) ;
    while (Serial.read() != -1) ;
  }
}
I have jumpers from pins 0-7 to pins 8-15 and theoutput looks correct where B: gets the lower 6 bits and C gets the upper 2 bits. 

It did find an error in my code where PINC was returning wrong data.  Turned out bug in T3.x code where we were doing digitalReadFast() of the same pin twice and skipping pin... So fixed in both cases. 
KurtE added 2 commits Nov 16, 2019
Reading wrong register for one bit...
Here is a first pass at trying to get the AVR emulation of Ports working like it did for T3.x.

Not 100% confident, but at least simple sketch is working.
@KurtE

This comment has been minimized.

Copy link
Contributor Author

KurtE commented Nov 16, 2019

Quick note: I did try changing the setup code to enable Pull ups like:

...
  DDRC = 0;     // All Inputs
  PORTC = 0xff; // enables PUs? 

And the output for port C, showed the 4 bits that were hooked up to nothing as now HIGH

Count: b9, B:39 C:3e
Count: ba, B:3a C:3e
Count: bb, B:3b C:3e
Count: bc, B:3c C:3e
Count: bd, B:3d C:3e
Count: be, B:3e C:3e
Count: bf, B:3f C:3e
Count: c0, B:0 C:3f
Count: c1, B:1 C:3f

So it looks like on the surface that part is reasonably working

@KurtE KurtE force-pushed the KurtE:t4_avr_registers branch from 4d5f0e1 to 6cd8784 Nov 20, 2019
The TX and RX values were reversed.
That is for example on Serial1 (LPUART6)
Before we had:
```
```
now we have
```
```
So for example trying to get WS2812Serial library to work was failing, to output anything.
@KurtE KurtE force-pushed the KurtE:t4_avr_registers branch from 196df07 to 0d0dda7 Nov 20, 2019
It was not properly clearing the old state for the ADC_CFG_AVGS, but instead it was oring in the new value,

also T4-Analog fix calibration tests
Found by @mjs513 - At init time it was not looking at ADC2 to have completed calibration...

Remove T41b1 pins ifdef
@KurtE KurtE force-pushed the KurtE:t4_avr_registers branch from 80b545c to 3abaeb1 Dec 3, 2019
@PaulStoffregen PaulStoffregen merged commit f9a9f86 into PaulStoffregen:master Dec 6, 2019
@PaulStoffregen

This comment has been minimized.

Copy link
Owner

PaulStoffregen commented Dec 6, 2019

Thanks!

Sorry about the delay on this.... it's been a long week of MacOS for me! Merging stuff now and will work on USB over the next few days, probably leading up to 1.49-beta2 by next week.

@KurtE KurtE deleted the KurtE:t4_avr_registers branch Dec 6, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.