Hello
is it possible to use digispark Attiny85 in XOD? i read in one of the topic that its possible to just copy and paste the code generated in XOD to IDE and upload to attiny. but when i tried it an error occurs. This error not occurs if i choose UNO or other type arduino.
Can someone help with this?
Note:
attaching error capture and sample code.
Already tried using IDE 1.8,3 as mention in the topic and the latest IDE
ATONEWv3.xodball (1.9 KB)
ups wrong file attached >.< i already correct it
First: add to C: \ Users \ user \ xod \ __ packages__ extra.txt line https://raw.githubusercontent.com/damellis/attiny/ide-1.6.x-boards-manager/package_damellis_attiny_index.json
Second: select ATTiny85 and compile
Third: accept the installation request and recompile
thanks for the help but i counter another problem
Error: exit status 1 Error during upload.
Upload failed Command C:\Users\xxx\AppData\Local\Programs\XOD IDE\resources\arduino-cli.exe --config-file=C:\Users\kamal\AppData\Local\Temp\arduino-cliyIoapo\.cli-config.yml upload --fqbn attiny:avr:ATtinyX5:clock=internal16,cpu=attiny85 --port COM1 --verbose -t C:\Users\xxx\AppData\Local\Temp\xod_temp_sketchbookxdIQ9d\xod_1542251014927_sketch failed with code 1 Make sure the board is connected, the cable is working, the board model set correctly, the upload port belongs to the board, the board drivers are installed, the upload options (if any) match your board specs.
the problem is the port not open for attiny85. using IDE i able to upload to attiny85 without choosing the the port (leave it to com1 even though im using com 6) using example code from IDE
If you choose the correct port, it may be a problem of load compatibility with XOD, try to update.
Now, you uploaded an Arduino IDE error can load into Arduino IDE, a blink example of this?
Unfortunately I do not have the hardware to check the load, but I do not have compilation errors
the developers will surely give a better solution
PD: that error can also happen if another program is using the port
still wont work but thanks anyway 
yes maybe the dev can give solution for this will waiting for them
Alas, ATtiny is too poor to be the XOD target board out of the box. As far as I remember, floating point math is somewhat very restricted or not available on the Tinies, but XOD heavily relies on it.
There appears to be some bugs in the digispark Arduino attiny cores where certain core features do not appear to have been implemented. For me the errors all stem from incorrect handling of the:
namespace xod {
namespace std {
template< class T > struct remove_reference {typedef T type;};
template< class T > struct remove_reference<T&> {typedef T type;};
template< class T > struct remove_reference<T&&> {typedef T type;};
template
typename remove_reference::type&& move(T&& a) {
return static_cast<typename remove_reference::type&&>(a);
}
} // namespace std
} // namespace xod
And the first error reported while attempting to compile using digsparks attiny core is:
sketch_nov16a:49:48: error: template argument 1 is invalid
template< class T > struct remove_reference<T&&> {typedef T type;};
^
the exact same xod generated code compiles without error or incident if I use the non digispark David A. Mellis attiny85 definitions, the downside of that is I would have to program a digispark board using an Arduino UNO as ISP (see programming the Attiny85 using an Arduino youtube videos for tips how) and overwrite the micronucleus boot loader. I do not believe the attinyX5 lack of hardware support for floats is an issue since it is performed in software anyway on most AVRs
There is a strong possibility that XOD may make extensive use of the stack in RAM for function calls and auto variables etc that could lead the XOD program to overflow the limited 512 bytes or RAM on the Attiny85 while it runs but for now I’d take the bugs in the digispark cores to digistumps developers and hope they can complete the AVR core and complete the headers so their boards are programmable using the language defined in the published reference manual… I just manually downloaded the GitHub repository for the digistump avr core and libraries and it is newer than the 1.6.7 last release but still throws the same errors as 1.6.7 I do not know enough about the avr core at the moment to debug the digspark problem… sorry.
Note if you have a genuine digispark board and not a cheaper Chinese clone it will likely have the /RESET pin disabled in the fuses in which case you’d have to build a high voltage programmer to re-enable the /RESET pin functionality to allow standard voltage ISP to function. All the ones I have are the cheap Chinese clones partly because they are so cheap and because Digistump are not currently shipping any Digispark products and they ALL have PB5 set as /RESET functionality.
Query, in arduino IDE have you also installed the Attiny manager? >>> https://raw.githubusercontent.com/damellis/attiny/ide-1.6.x-boards-manager/package_damellis_attiny_index.json
If we try and install ATTiny into XOD it will fail since avrdude cannot talk to an attiny85 chip directly and it has to be done via an ISP programmer so is easiest done by using show code for Arduino and copy and paste that into a new sketch in a current Arduino IDE with damellis attiny package installed and selected atttiny85 internal 16MHz clock and the programmer in my case set as Arduino as ISP but could use any other compatible ISP IF the /RESET line is active on the Attiny85… It is late here… gone 5am so not going to prepare the ISP and connect it all up to try one of my XOD experiments on a digispark board tonight! Because damellis uses the default Arduino core it compiles XOD derived Arduino sketch code without issue.
port numbering just requires a modicum of forethought and can be edited in the sketch source if desired later on. PS I have also added digispark json to XOD too since you gave the basic instructions how to as well as attempted to add the expressive esp32 toolchain but that falls over during installation I guess it’s too alien for XOD in its current form.
Oops to answer your question after rereading it yes I have David A, Mellis Attiny definitions installed in my Arduino IDE as well as https://raw.githubusercontent.com/FemtoCow/ATTinyCore/master/Downloads/package_femtocow_attiny_index.json and http://digistump.com/package_digistump_index.json the latter two cannot compile XOD generated sketches at this time but David A. Mellis definition can without errors or warnings.
Today I did the Arduino as ISP test uploading a XODball to a digispark clone Attiny85 using David A. Mellis Attiny json in the Arduino IDE and exporting the Arduino code from XOD and pasting it into the Arduino IDE and Uploading using Arduino as ISP programmer and as expected it worked. As I am a new user here I cannot upload the .xodball file but will try pasting the text from the xodball file which if the forum software does not filter out its syntax should be copy able and paste able into a local empty .xodball file and loaded into your own xod instance.
EDIT the forum does corrupt the syntax formatting by converting the programmers standard Quotes (SHIFT + 2) on UK keyboard into non parse-able “pretty quote characters” I think I have a workaround using \ prefix to each " we shall see! It did not work 
The reader interested in using the enclosed XODBALL data will have to use find and replace in a programmers editior or decent plain text editor to find the specific wrong each individual “” characters and replacing them with " characters each and saving the resultant file as a .xodball file that should then load into XOD gui… phew that was far tooo much work!
I originally produced this one because I wondered if one could emulate a multi-threaded program by producing 3 isolated square wave generators with different frequencies and duty cycles switching 3 different LEDs off and on at independent rates. Originally it flashed the Arduino UNO R3 built in LED and Tx and Rx LEDs. This version flashes 3 LEDS on 3 pins one is the built in clone digisparks on PB1 and a potential external LED on PB0 and another potential LED on PB3 these pins are also potentially analoguewrite() PWM pins under digisparks core but may not be so equipped under David A, Mellis Attiny definitions.
{
“name”: “”,
“patches”: {
“@/main”: {
“links”: {
“Hk1YUFpum”: {
“id”: “Hk1YUFpum”,
“input”: {
“nodeId”: “BkokSKTd7”,
“pinKey”: “HyYh1a3LZ”
},
“output”: {
“nodeId”: “rJQ_LYauQ”,
“pinKey”: “S1aYu6KJf”
}
},
“HyMYLY6_X”: {
“id”: “HyMYLY6_X”,
“input”: {
“nodeId”: “S1hkrFaOQ”,
“pinKey”: “HyYh1a3LZ”
},
“output”: {
“nodeId”: “BylXu8tpu7”,
“pinKey”: “S1aYu6KJf”
}
},
“HysOIt6dQ”: {
“id”: “HysOIt6dQ”,
“input”: {
“nodeId”: “S1-y4Ya_7”,
“pinKey”: “HyYh1a3LZ”
},
“output”: {
“nodeId”: “Hk_wLtadm”,
“pinKey”: “S1aYu6KJf”
}
}
},
“nodes”: {
“BkokSKTd7”: {
“boundLiterals”: {
“B1oqkTnIb”: “D0”,
“HyYh1a3LZ”: “1”
},
“id”: “BkokSKTd7”,
“label”: “TX LED”,
“position”: {
“x”: 102,
“y”: 204
},
“type”: “xod/common-hardware/led”
},
“BylXu8tpu7”: {
“boundLiterals”: {
“BJ5HJ6t1f”: “0.9”,
“rJS8ypK1z”: “0.2”
},
“id”: “BylXu8tpu7”,
“position”: {
“x”: 271,
“y”: -1
},
“type”: “xod/core/square-wave”
},
“Hk_wLtadm”: {
“boundLiterals”: {
“BJ5HJ6t1f”: “0.60”
},
“id”: “Hk_wLtadm”,
“position”: {
“x”: -1,
“y”: -1
},
“type”: “xod/core/square-wave”
},
“S1-y4Ya_7”: {
“boundLiterals”: {
“B1oqkTnIb”: “D3”,
“HyYh1a3LZ”: “1”
},
“id”: “S1-y4Ya_7”,
“label”: “RX LED”,
“position”: {
“x”: 0,
“y”: 204
},
“type”: “xod/common-hardware/led”
},
“S1hkrFaOQ”: {
“boundLiterals”: {
“B1oqkTnIb”: “D1”,
“HyYh1a3LZ”: “0”
},
“id”: “S1hkrFaOQ”,
“label”: “OnBoard LED”,
“position”: {
“x”: 204,
“y”: 204
},
“type”: “xod/common-hardware/led”
},
“rJQ_LYauQ”: {
“boundLiterals”: {
“BJ5HJ6t1f”: “0.3”,
“rJS8ypK1z”: “0.75”
},
“id”: “rJQ_LYauQ”,
“position”: {
“x”: 135,
“y”: -1
},
“type”: “xod/core/square-wave”
}
},
“path”: “@/main”
}
}
}
Hi it’s not so important that I’d want to keep it forever on my cloud storage so the link always works… If anyone wants to try it, it is not too difficult to repair the formatting and save it as an xodball file. No clue how long I have to be a member here until I am allowed to upload attachments, that is the best way to share .xodball files via this forum I think.
It was the multiple attempts and re-edits to try and work around the forum software corrupting the formatting that was the far too much work… not running a couple of find and replace all on the resultant new ASCII file to make it into a valid .xodball JSON file that’s trivial in the grand scheme of things.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.