platformio question setting PF6 (RESET) to be used as Reset (and not GPIO) #460
Comments
|
1. You should look at the compile output logs from Arduino and from
platform.io - make sure that build_flags includes all the things that get
used as build flags by the arduino IDE. I do not think all the build flags
that should be there are (this is what I hate about platform IO, as a core
developer - I would have to duplicate a whole bunch of logic to blow up
every compile attempt that missed any #defines that were required.
and -DIS_AVR128DA28 shouldn't be there - there's already a builtin compiler
supplied macro (__AVR_AVR128DB28__ I think), plus I supply a shitload of
macros, see Ref_Defines.md. which can be used to identify parts.
2. The configuration of PF6 however is completely outside of the realm of
what any code running on the AVR can do, the code uploaded has no bearing
on it. The function of the reset pin is configured by the fuses, so you
need to set it, it's in one of the sysconfig fuses (I forget which of the
two or which bits it is) to the correct value) when writing the fuses.
…On Fri, Jul 21, 2023 at 8:26 AM mrWheel ***@***.***> wrote:
@SpenceKonde <https://github.com/SpenceKonde> I know you do not have the
time to dive into platformio questions, but I hope someone else is willing
to help me!
I am trying to get my AVR128DB28 MCU to reset using .. well, the RESET pin
(PF6). I'm using the reset circuit
<https://github.com/SpenceKonde/DxCore/blob/master/megaavr/extras/Ref_Reset.md>
as conform Spence's advice.
Using the Arduino IDE and the option [Reset pin function: "Hardware Reset
(recommended)"] it works like a charm (thanks Spence).
But I'm shifting towards Visual Code and Platformio and I can not get the
same code/hardware to reset if the [reset] button is pressed..
This is my platform.ini file:
[platformio]
workspace_dir = .pio.nosync
default_envs = AVRxDB28
name = testReset
description = test Reset circuit
[env]
framework = arduino
build_unflags =
[env:AVRxDB28]
platform = atmelmegaavr
board = AVR128DB28
build_flags =
-DIS_AVR128DB28
upload_protocol = jtag2updi
upload_flags =
board_hardware.bod = 2.7v
board_hardware.eesave = yes
board_hardware.uart = no_bootloader
board_hardware.rstpin = reset
This is the (test) code I'm using:
/*------------------------------------------------------
* Chip: "AVR128DB28"
* Clock Speed: "24 MHz internal"
* millis()/micros() timer: |TCB2 (recommended)"
* Reset pin function: "Hardware Reset (recommended)"
* Startup Time: "8ms"
* MultiVoltage I/O (MVIO): "Disabled"
* --
* Programmer: "jtag2updi"
*-----------------------------------------------------*/
//==============================================================
void setup()
{
pinMode(PIN_PA7, OUTPUT);
pinMode(PIN_PF6, INPUT_PULLUP);
Serial.begin(115200);
Serial.println("\n\n\nAnd than it begins ....");
for (int i=0; i<10; i++)
{
digitalWrite(PIN_PA7, CHANGE);
delay(500);
}
Serial.println();
} // setup()
//==============================================================
void loop()
{
digitalWrite(PIN_PA7, CHANGE);
delay(100);
if (!digitalRead(PIN_PF6))
Serial.println("RESET is LOW");
} // loop()
I'm so close but still so far away.
I hope someone can and will help me!
—
Reply to this email directly, view it on GitHub
<#460>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTXEW5U3XYPCZ4PL4VST4DXRJYQ3ANCNFSM6AAAAAA2SYXRME>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
____________
Spence Konde
Azzy’S Electronics
New products! Check them out at tindie.com/stores/DrAzzy
GitHub: github.com/SpenceKonde
ATTinyCore <https://github.com/SpenceKonde/ATTinyCore>: Arduino support for
all pre-2016 tinyAVR with >2k flash!
megaTinyCore <https://github.com/SpenceKonde/megaTinyCore>: Arduino support
for all post-2016 tinyAVR parts!
DxCore <https://github.com/SpenceKonde/DxCore>: Arduino support for the AVR
Dx-series parts, the latest and greatest from Microchip!
Contact: ***@***.***
|
|
Thanks Spence, It's a bit of a catch22. This is what the boards.txt file has: So I guess the Now if only I new how to set this in a If anyone could help me with this I would much appreciate it!
I know. Just could not find out how the define was named (now I know and shall change that in my program). |
|
Update The differences are: The only difference is in But the strange thing is: Next going to investigate if I can set |
|
Well.. in platformio open the "Project Task" (click on the 'ant-head') than click on "set Fuses" This is the output: After that the [Reset] function of PF6 works as expected. I have not yet found a way to make PF6 a GPIO-input pin again, but who cares! I'm a happy Camper! No idea what happens behind the service, maybe someone else can elaborate. |
|
SYSCFG0=0xC9 = PF6 RESET, So to turn it back to input, set it to 0xC1
instead
…____________
Spence Konde
Azzy’S Electronics
New products! Check them out at tindie.com/stores/DrAzzy
GitHub: github.com/SpenceKonde
ATTinyCore: Arduino support for almost every ATTiny microcontroller
Contact: ***@***.***
On Sat, Jul 22, 2023, 09:36 mrWheel ***@***.***> wrote:
Well.. in platformio open the "*Project Task*" (click on the 'ant-head')
than click on "*set Fuses*"
This is the output:
Processing AVRxDB28 (platform: atmelmegaavr; board: AVR128DB28; framework: arduino)
-------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/atmelmegaavr/AVR128DB28.html
PLATFORM: Atmel megaAVR (1.8.0) > AVR128DB28
HARDWARE: AVR128DB28 24MHz, 16KB RAM, 128KB Flash
PACKAGES:
- framework-arduino-megaavr-dxcore @ 1.5.6
- tool-avrdude @ 1.70100.0 (7.1.0)
- toolchain-atmelavr @ 3.70300.220127 (7.3.0)
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 19 compatible libraries
Scanning dependencies...
Dependency Graph
|-- RF24 @ 1.4.7
|-- SPI @ 1.1.2
Building in release mode
TARGET CONFIGURATION:
-------------------------
Target = avr128db28
Clock speed = 24000000L
Oscillator = internal
BOD level = 2.6v
Save EEPROM = yes
MVIO enable = no
Reset pin mode = reset
-------------------------
Auto-detected: /dev/cu.wchusbserial14210
Selected fuses:
-------------------------
[fuse0 / wdtcfg = 0x00]
[fuse1 / bodcfg = 0x00]
[fuse2 / osccfg = 0x00]
[fuse4 / tcd0cfg = 0x00]
[fuse5 / syscfg0 = 0xC9]
[fuse6 / syscfg1 = 0x16]
[fuse7 / codesize = 0x00]
[fuse8 / bootsize = 0x00]
[lock / lockbit = 0x5CC5C55C]
-------------------------
Looking for port...
Using manually specified: /dev/cu.wchusbserial14210
Setting fuses...
avrdude: Version 7.1-arduino.1
Copyright the AVRDUDE authors;
see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is /Users/WillemA/.platformio/packages/tool-avrdude/avrdude.conf
User configuration file is /Users/WillemA/.avrduderc
User configuration file does not exist or is not a regular file, skipping
Using Port : /dev/cu.wchusbserial14210
Using Programmer : jtag2updi
avrdude jtagmkII_getsync() warning: attempt 1 of 10: sign-on command: status -1
JTAG ICE mkII sign-on message:
Communications protocol version: 1
M_MCU:
boot-loader FW version: 1
firmware version: 6.00
hardware version: 1
S_MCU:
boot-loader FW version: 1
firmware version: 6.00
hardware version: 1
Serial number: 00:00:00:00:00:00
Device ID: JTAGICE mkII
AVR Part : AVR128DB28
RESET disposition : dedicated
RETRY pulse : SCK
Serial program mode : yes
Parallel program mode : yes
Memory Detail :
Block Poll Page Polled
Memory Type Alias Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- -------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
fuse0 wdtcfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse1 bodcfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse2 osccfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse4 tcd0cfg 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse5 syscfg0 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse6 syscfg1 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse7 codesize 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuse8 bootsize 0 0 0 0 no 1 1 0 0 0 0x00 0x00
fuses 0 0 0 0 no 9 16 0 0 0 0x00 0x00
lock 0 0 0 0 no 4 1 0 0 0 0x00 0x00
tempsense 0 0 0 0 no 2 1 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 1 0 0 0 0x00 0x00
prodsig 0 0 0 0 no 125 125 0 0 0 0x00 0x00
sernum 0 0 0 0 no 16 1 0 0 0 0x00 0x00
userrow usersig 0 0 0 0 no 32 32 0 0 0 0x00 0x00
data 0 0 0 0 no 0 1 0 0 0 0x00 0x00
eeprom 0 0 0 0 no 512 1 0 0 0 0x00 0x00
flash 0 0 0 0 no 131072 512 0 0 0 0x00 0x00
Programmer Type : JTAGMKII_UPDI
Description : JTAGv2 to UPDI bridge
M_MCU HW version: 1
M_MCU FW version: 6.00
S_MCU HW version: 1
S_MCU FW version: 6.00
Serial number : 00:00:00:00:00:00
Vtarget : 5.0 V
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e970e (probably avr128db28)
avrdude: reading input file 0x00 for fuse0/wdtcfg
with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte fuse0/wdtcfg ...
avrdude: 1 byte of fuse0/wdtcfg written
avrdude: verifying fuse0/wdtcfg memory against 0x00
avrdude: 1 byte of fuse0/wdtcfg verified
avrdude: reading input file 0x00 for fuse1/bodcfg
with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte fuse1/bodcfg ...
avrdude: 1 byte of fuse1/bodcfg written
avrdude: verifying fuse1/bodcfg memory against 0x00
avrdude: 1 byte of fuse1/bodcfg verified
avrdude: reading input file 0x00 for fuse2/osccfg
with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte fuse2/osccfg ...
avrdude: 1 byte of fuse2/osccfg written
avrdude: verifying fuse2/osccfg memory against 0x00
avrdude: 1 byte of fuse2/osccfg verified
avrdude: reading input file 0x00 for fuse4/tcd0cfg
with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte fuse4/tcd0cfg ...
avrdude: 1 byte of fuse4/tcd0cfg written
avrdude: verifying fuse4/tcd0cfg memory against 0x00
avrdude: 1 byte of fuse4/tcd0cfg verified
avrdude: reading input file 0xC9 for fuse5/syscfg0
with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte fuse5/syscfg0 ...
avrdude: 1 byte of fuse5/syscfg0 written
avrdude: verifying fuse5/syscfg0 memory against 0xC9
avrdude: 1 byte of fuse5/syscfg0 verified
avrdude: reading input file 0x16 for fuse6/syscfg1
with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte fuse6/syscfg1 ...
avrdude: 1 byte of fuse6/syscfg1 written
avrdude: verifying fuse6/syscfg1 memory against 0x16
avrdude: 1 byte of fuse6/syscfg1 verified
avrdude: reading input file 0x00 for fuse7/codesize
with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte fuse7/codesize ...
avrdude: 1 byte of fuse7/codesize written
avrdude: verifying fuse7/codesize memory against 0x00
avrdude: 1 byte of fuse7/codesize verified
avrdude: reading input file 0x00 for fuse8/bootsize
with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte fuse8/bootsize ...
avrdude: 1 byte of fuse8/bootsize written
avrdude: verifying fuse8/bootsize memory against 0x00
avrdude: 1 byte of fuse8/bootsize verified
avrdude: reading input file 0x5CC5C55C for lock
with 1 byte in 1 section within [0, 0]
avrdude: writing 1 byte lock ...
avrdude: 1 byte of lock written
avrdude: verifying lock memory against 0x5CC5C55C
avrdude: 1 byte of lock verified
avrdude done. Thank you.
======================================== [SUCCESS] Took 7.35 seconds ========================================
Environment Status Duration
------------- -------- ------------
AVRxDB28 SUCCESS 00:00:07.345
======================================== 1 succeeded in 00:00:07.345 ========================================
* Terminal will be reused by tasks, press any key to close it.
After that the [Reset] function of PF6 works as expected.
Uploading other program's to the chip do not interfere with the fuse
settings and PF6 stay's a Reset pin!
I have not yet found a way to make PF6 a GPIO-input pin again, but who
cares! I'm a happy Camper!
No idea what happens behind the service, maybe someone else can elaborate.
—
Reply to this email directly, view it on GitHub
<#460 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTXEW7YX243JAYGDGBVVHLXRPJL7ANCNFSM6AAAAAA2SYXRME>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
The problem is the fuse settings are located in a file deep in the platformio stuff ( I have not yet found a way to simple change these fuse settings in the But for me it is not a problem as I have no need for PF6 to be used other than as a Reset pin. But did you read this:
That is in the ArduinoIDE. |
|
I will see if I can reproduce, that is not correct behavior if so. |
|
|
If you need to have exact fuse values, you can define them like so, and the built-in fuses.py will use these instead of calculating them: board_fuses.wdtcfg = 0x00
board_fuses.bodcfg = 0x00
board_fuses.osccfg = 0x01
board_fuses.tcd0cfg = 0x00
board_fuses.syscfg0 = 0xC9
board_fuses.syscfg1 = 0x06
board_fuses.codesize = 0x00 # append for MegaCoreX and megaTinyCore
board_fuses.bootsize = 0x00 # bootend for MegaCoreX and megaTinyCoreBut I can't reproduce @mrWheel's issue. When I use the platformio.ini file he provided, and changes |
|
@MCUdude And indeed: setting " I did found posts and issue answers about the " PlatformIO has a steep learning curve! Question: Is there a way to set the fuses during uploading? Just like the ArduinoIDE does? But besides that: thanks. |
|
Yes, I don't see why you would want to set the fuses every time you upload. It's only needed once. You can add custom upload flags that Avrdude can utilize, but then you'll have to know the values of the fuses you want to set. upload_flags =
-U wdtcfg:w:0x00:m
-U syscfg0:w:0xC9:m
-U syscfg1:w:0x16:mThis would also work if you have your fuses defined in a separate environment (so you can run the fuses command): upload_flags =
-U wdtcfg:w:${env:custom_fuses.board_fuses.wdtcfg}:m
-U syscfg0:w:${env:custom_fuses.board_fuses.syscfg0}:m
-U syscfg1:w:${env:custom_fuses.board_fuses.syscfg1}:mI do agree that the PlatformIO documentation for AVR/ megaAVR isn't all that good. That's why I've provided a template and a simple readme for MegaCoreX that was later adopted by DxCore. However, since PlatformIO is so powerful and lets the user play around with all the 3rd party tools PlatformIO utilizes, like Avrdude, you can do very complex and neat things straight from platformio.ini. If someone were to document every possible thing you could do with the PlatformIO build system, it would become quite a heavy book! Pro tip: Since PlatformIO uses Avrdude 7.1 (unlike DxCore) you can increase the upload speed of your jtag2updi programmer if you're tired of waiting for slow uploads. Higher speeds than 115200 baud was added to the jtag2updi firmware in January 2022, so if your firmware is newer than this, you should be good to go. Try adding |
|
The reason you want to set fuses everytime you upload, well first almost half my issues were confusion about 16/20 MHz speeds. So then that fuse got autoset on updi uploads. Then I realized that a UPDI upload after bootloader had been in use, uploaded over UPDI would delete the bootloader, but not reset the fuses correctly, so it would think the vectors were in the wrong place and the whole thing would go up in a ball of fire. , resulting in guaranteed not to work state. Okay so bootend and append should be set every time (especially the equivalent on DxCore, because we have adjustable size APPDATA section for writes from the app to flash without doing anything dirty) And at that point someone asked "Why aren't all fuses written?!" and I say "Well you can't do SYSCFG1 because that could brick the chip we should enforce a bit of consideration there" "And what about the rest of them?" "Well BODCFG is also hazardous, because you could be soldered to a board sharing supply rail with parts that can see 3.6v max, but you set the BOD voltage to 4.3V - parts would have to be desoldered. And why should we touch a fuse that we don't have a submenu that controls - either they're at the default where we left them or the user changed them and we probable are not doing what they want if we're resetting those." And since then that's been my standard - If the fuse has options to configure it in the core, it gets set on upload unless it's an "unsafe" fuse that could brick the chip or make the chip hard to reprogram (BODCFG and anything that lets you turn off UPDI. For a while MVIO was classified as unsife, but I eventually tested it, finding that it did not connect VDDIO2 and VDD internally (which would have made it a chip-burner if MVIO wasn't enabled and the lower voltage supply could both source and sink) and did not appear to be short-term destructive to the device) (They did MVIO status wrong IMHO - They should have given a status of 0 (not working) whenever MVIO was disabled, instead of 1, which is what it does. Nobody not using MVIO is going to check MVIO status, so you don't care what those people see. So effectively 100% of the people checking that register think MVIO is enabled, and want to see if the port is powered. If MVIO is disabled and we don't know if the port is powered, dear lord shouldn't we say something other than "all clear!"?) And yeah., that's why the fuses that are written upon upload in almost all cases. The exceptions being BODCFG, and SYSCFG1 if that fuse lets updi be disabled, plus any fuse we have no submenu to configure. Microchip assured me that there would not be a fuse longevity problem doing this, indicating they're more like EEPROM than flash But the root reason the cores do is that it generates too many support inquiries to not set OSCCFG, and to be consistent with our policy of trying not to knowingly leave the chip in state that we can guarantee will not function correctly (as would be the case if we didn't fix BOOTSIZE) and you'd need to burn bootloader if you wanted to change the size of sized SPM, which would be obnoxious so maybe CODESIZE gets in too, and from there, the consistency argument leads to, well, this. And - the original reason NOT to set fuses on all uploads dated to classic AVR times. On classic AVRs, most of the time every single fuse had at least one bit that would brick the chip - a fucked low fuse was easy enough to recover by supplying and external clock. A fucked high fuse required HV programming (in reach if the patient was a t85, 84, or 841, as those use hvsp. HVPP was used by everything else and required around 20 connections to the target and all of which were used. And a fucked efuse had varying effects depending on the part, sometimes these were non-fatal on non-optiboot configurations except if the sketch got up to the last 512b of flash). But on modern AVRs, there are only 1-2 dangerous fuses, and the one present on all parts is only extrinsically hazardous (ie, if the chip were alone on a board it is totally safe). The intentionally dangerous "break the wrong key off in the lock on your way out" fuses will never be written by the core. Yes, in addition to locking there is yet another way to throw barricades into the path of people trying to exfiltrate your firmware. |
SpenceKonde
added
Documentation
|
Hans, "
I have to explicitly set But that means every time I change the port the Is this a bug and will it be dealt with in the near future or is there something I do wrong (and maybe a quick patch)? Regards |
|
Is there by any chance a program_port or a bootload_port? (program because that keyword was sometimes used by arduino to refer to using an external programmer instead of a bootloader mostly in the classic avr days, though it lives on in the platform.txt) All these IDEs seem to do a piss poor job of this sort of thing. I think it comes down to settings, and their management. There are several kinds of settings. There are some settings that should definitely be associated with a user and a machine - the path to his sketchbook, his warning and verbosity choices, that sort of thing. Arduino manages this ok. There are some settings (like all the tools submenu entries, EXCEPT port) that should be associated with the sketch - Wouldn't it be great if Arduino dropped a sketch.ini with the values that were selected on each tools submenu every time they saved it? Or better still, sketch-boardname.ini, so you can have one sketch folder, and if you select a tinyAVR board it would build with one set of menu options and if it was a Dx it would use another set of options). Finally, there are settings like the port number. They are ephemeral, the same board will have one port number one day, another the next... - I'm not even sure quite what the right behavior is bearing in mind what computers can and can't do to serial ports (for example, it doesn't seem like there's a way to see which serial ports are available and which are already in use), that some serial adapters have "names", others just have an "address" (ex, FT232RL will get a COM number, and then that number will follow it around into any USB port. Different FT232RL, different port number - they each have their own name. CH340 will get a COM number that depends on, exactly, where in the tree-like USB topology the CH340 is connected. (Usually the logic seems to be that they're numbered in chronological order, and if you have a USB hub, each of it's ports are different, and each port it can be plugged into is different, and so on). But if you remove the CH340 from USB and plug in a different CH340, it will get the same COM port numbers as the first one did when plugged into the same port. The CH340 only depends on where it's located, so it has an address but no name). serial adapters known by their name might even make sense to save with the sketch! Whereas serial adapters known only by their address should probably only be retained on a per-window basis. But I don't know if there's a way to determine which type of adapter each one is... This may be a case of "It sucks cause the tools we got suck" - it does kind of look like particularly on windows the toolkit that developers get consists of a vacuum cleaner, a black hole, and the front half of an jet engine (so it sucks air in, and the fuel and air combust, and wherever it's back end happens to be will develop thrust and blast out hot jet exhaust).... and it's not clear to me that linux is all that much better. They may just not give you much information about themselves. They date to an era where a computer had maybe 1 or 2 serial ports, and the connectors that were used were generally screwed in, etc, etc. Since they didn't come and go very often, they didn't need to report very much information, because you'd know "okay, I have a port labeled 1 and 2 on the back of my desktop, I guess that's COM1 and COM2". Little bit more confusing now :-P |
|
@SpenceKonde I’m using Visual Code with The other way is to nót define an |
|
@mrWheel I'm able to reproduce the issue. I've selected 
[platformio]
; Default build target
default_envs = Upload_UPDI
; Parameters used for all environments
[env]
platform = atmelmegaavr
framework = arduino
; Chip in use
board = ATmega4809
; Clock frequency in [Hz]
board_build.f_cpu = 16000000L
; Oscillator type (internal or external)
board_hardware.oscillator = internal
; Arduino pinout variant
board_build.variant = 48pin-standard
; Unflag build flags
build_unflags =
; Extra build flags
build_flags =
; Monitor port is auto detected. Override here
;monitor_port = ${env:Upload_UPDI.upload_port}
monitor_speed = 9600
monitor_dtr = 0
; Run the following command to upload with this environment
; pio run -t upload
[env:Upload_UPDI]
; Upload protocol for UPDI upload
upload_protocol = jtag2updi
;upload_port = /dev/cu.usbserial-1410
upload_speed = 115200
upload_flags =
; run the following command to set fuses
; pio run -e fuses_bootloader -t fuses
; run the following command to set fuses + burn bootloader
; pio run -e fuses_bootloader -t bootloader
[env:fuses_bootloader]
; Inherit upload settings from the Upload_UPDI environment
extends = env:Upload_UPDI
; Hardware settings
board_hardware.bod = 2.7v
board_hardware.eesave = yes
board_hardware.uart = no_bootloader
board_hardware.rstpin = reset
|
|
@MCUdude |
|
It is most likely a bug (and hopefully not a "feature"), but I think you should report it in the PlatformIO VSCode plugin repo: |
SpenceKonde
added
Not our bug
|
Thanks guys. Closing this since this appears to be a bug in VSCode/PIO (I thought those were totally different things, shows how qualified I am to be working on this). I'd probably do better as an amateuir rocket scientist than trying to make PIO stuff work. (You know the college I went to, my departments (ChE)'s main building was named after the father or rocketry, Robert H. Goddard. I remember hearing that way back in the old days as a student, that he accidentally blew up a small outbuilding or something as a student. Times sure have changed. Back then, they paid tuition by making things in the workshops and selling them. Pretty sure these days, that would earn you an expulsion, not a building named after you. shrug) |
@SpenceKonde I know you do not have the time to dive into platformio questions, but I hope someone else is willing to help me!
I am trying to get my AVR128DB28 MCU to reset using .. well, the RESET pin (PF6). I'm using the reset circuit as conform Spence's advice.
Using the Arduino IDE and the option [Reset pin function: "Hardware Reset (recommended)"] it works like a charm (thanks Spence).
But I'm shifting towards Visual Code and Platformio and I can not get the same code/hardware to reset if the [reset] button is pressed..
This is my
platform.inifile:This is the (test) code I'm using:
I'm so close but still so far away.
I hope someone can and will help me!
The text was updated successfully, but these errors were encountered: